tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jess Holle <>
Subject Re: Tomcat JVM Crash
Date Fri, 03 Oct 2014 18:46:39 GMT
On 10/3/2014 1:11 PM, Mark Thomas wrote:
> On 03/10/2014 17:07, Chad Maniccia wrote:
>> Hi,
>> I have discovered the source of the JVM crashes. I figured it best to share with
the group because it is quite odd. I have tested this and confirmed with a colleague so as
odd as it sounds it is reproducible.
>>   The crash is caused by a combination of Chrome web browser, HTTPS, and posting
a form with an exact amount of data. If you use HTTP to submit the form=no crash, If you use
IE and HTTPS=no crash. If you add/remove a single character to the form=no crash. I have attached
the latest crash log. Please note that Tomcat crashes before it logs the request to "localhost_access_log"
and before it passes the request to the servlet. This problem is present between multiple
versions of Java and Tomcat.
>> Here is another user reporting a similar issue.
>> I did like they suggested and added the following line. This doesn't fix the problem
but it prevents the server from crashing, you get a blank page instead. Why is this?
>> -XX:CompileCommand=exclude,com/sun/crypto/provider/*.*
>> Whose problem is this: Google, Apache Tomcat, GoDaddy(SSL), or Oracle?
> Oracle.
> Regardless of whether the input is valid or not it should not trigger a
> JVM crash.


That said, one thing that really bothers me about including /any/ native 
additional native libraries (ala JNI) in a Java process (but 
particularly a Java /server/ process) is that when the JVM experiences a 
native crash you cannot categorically blame the JVM vendor in this case.

If you /don't/ have any additional native code, then you /can 
/categorically blame the JVM vendor -- clear and simple.

This is one reason of several reasons that for me using APR in Tomcat is 
a non-starter.

[Yes, you could always reproduce the issue with Java connectors, but 
that's painful and there are, of course, other reason for avoiding 
native libraries, e.g. having to build them across the numerous 
architectures one supports, rather than simple write-once-run-anywhere.]

Jess Holle

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message