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:13:39 GMT
Hi Christopher,

Appreciate the help. I figured the same on the slow down after reading a little bit about
what turning off the JIT compiler would mean. But we are not experiencing a perceivable slow
down. So for now its a good patch to prevent Tomcat crashing.

I don't have a working example of the crash, yesterday I could get it to crash reliably by
opening a Lease in our Lease management system and trying to unlock it. Today it is no longer
crashing. I'm creating a JavaScript page which will add more data to a form and submit it
rinse and repeat to try and automate discovery of a crash.

It appears to just ignore the request. Chrome returns a blank page, I wish I would have hit
F12 to see what was happening on the network.


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

Hash: SHA256


On 10/3/14 2:38 PM, Chad Maniccia wrote:
> Thanks for replying. I actually reported this bug to Oracle before
> contacting this group. They contacted me once but then never
> replied again.  I'd appreciate it if you could bring it to their
> attention again.
> This bug is kind of elusive as a form that is crashing today might
> not crash tomorrow, I suspect it is because headers, cookies,
> session keys etc  have changed. I'll see if I can reproduce it by
> creating a testing form.
> Can anyone tell me why this line causes the site to not crash?
> -XX:CompileCommand=exclude,com/sun/crypto/provider/*.*

Whatever is going on inside of the crypto provider is causing
something (probably the JIT compiler) to crash. Or, the JIT compiler
is producing code that crashes... I don't know enough about how the
JVM works to know where compiled-in-memory code gets assigned a
"source library" in a stack dump.

Anyhow, using CompileCommand=exclude turns off the compiler for the
methods in the classes in the package indicated. That should mean that
everything in that package gets *interpreted*, which would probably
mean very slow performance since crypto work is usually pretty
processor-intensive and a JIT can really help a lot over interpreted

I wouldn't expect requests to be ignored in the cases where you have
disabled compilation to avoid the bug and then you try to trigger them.

What response does the client get in these cases? No response (waits
forever)? Empty response? What does a thread dump show for the thread
that is handling the request?

- -chris

> ________________________________________ From: Mark Thomas
> <> Sent: Friday, October 03, 2014 1:14 PM To:
> Tomcat Users List Subject: Re: Tomcat JVM Crash
> On 03/10/2014 17:11, Igal @ wrote:
>>> Whose problem is this: Google, Apache Tomcat, GoDaddy(SSL), or
>>> Oracle? regardless of whose fault this is, Tomcat should be
>>> patched so that it doesn't crash.
> The general position of the Tomcat developers is that we do *not*
> patch Tomcat to work around bugs in third party code.
> There have been exceptions in the past but - since this JVM bug as
> a workaround available - I very much doubt that Tomcat will be
> patched to avoid this (even if such a patch was possible which
> looks unlikely).
>> can you produce a reduced test case so that the good people at
>> Tomcat can reproduce it on their end and patch it?
> A reproducible test case is definitely a good thing but it needs to
> go to Oracle, not to the Tomcat devs.
> Note we do have some contacts with Oracle we can use to ensure a
> bug report gets in front of the right people.
> Mark
> ---------------------------------------------------------------------
To unsubscribe, e-mail:
> For additional commands, e-mail:
> ---------------------------------------------------------------------
To unsubscribe, e-mail:
> For additional commands, e-mail:
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