tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chad Maniccia <>
Subject Re: Tomcat JVM Crash
Date Fri, 03 Oct 2014 19:28:47 GMT

I'll try turning off the APR next time I get a crashing form.


From: Christopher Schultz <>
Sent: Friday, October 03, 2014 2:01 PM
To: Tomcat Users List
Subject: Re: Tomcat JVM Crash

Hash: SHA256


On 10/3/14 2:46 PM, Jess Holle wrote:
> 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.
> Agreed.
> 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.]

The thread that evidently crashed the JVM was a NIO thread, but it's a
good catch that there were APR threads running as well.

Chad, can you disable the APR connector and still reproduce the
problem? Can you create a set of step-by-step instructions for
reproducing this problem so someone outside of your environment can
make it happen?

- -chris
Version: GnuPG v1
Comment: GPGTools -


To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message