tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: Tomcat JVM Crash
Date Fri, 03 Oct 2014 18:59:24 GMT
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:

View raw message