tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chad Maniccia <CManic...@mbgaustin.com>
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.

Thanks,
Chad


________________________________________
From: Christopher Schultz <chris@christopherschultz.net>
Sent: Friday, October 03, 2014 1:59 PM
To: Tomcat Users List
Subject: Re: Tomcat JVM Crash

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Chad,

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.
>
> https://bugs.openjdk.java.net/browse/JDK-8058284
>
> 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
bytecode.

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
> <markt@apache.org> Sent: Friday, October 03, 2014 1:14 PM To:
> Tomcat Users List Subject: Re: Tomcat JVM Crash
>
> On 03/10/2014 17:11, Igal @ getRailo.org 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: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
> ---------------------------------------------------------------------
>
>
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJULvIMAAoJEBzwKT+lPKRYGoEP/3xwimBkdsMXCiQ9WrKHL655
JU6zNsCKuAd9AGeWsteSzZkamDbcPBsVnjdiNgUMxwkEbCNONAlA6lOOGlB+LBDr
cZnDdLxkI2WrGkwclZ8fZ/IQFYI46EZ1CQOQ5xe5C5MYa6Ef1OwcQtvZtw6HFKGe
DnOD8+UFlK6gnXF/nqX/AqTxRJ4vusRBd3Jpqaqy7AecojL00lAQP0ORlQAvZ6Hj
KDhpJPIhV95qSLQTnOkkUF0JP+hafGC9iyBKmDfrDEI+zRYlaA/ARUe6sokBHKnO
Eashaih277N4sXq0YVjbAXZZrKJwK3uSyfkymwZjJFXY6dAa9w9PsfpQ2ck/doaK
BXsI9TOq7WwWOSLGkWm1OMeKBrtld26Doo8ukAhiQUANmTh3WNhgO1zK/KROFjOE
fqWJbubpiM6Rf+tl4nf4RcAV2pqfOO4atFk+YvtMxxLmQwPZ06OWwkypQzUxMOZb
yBSC5vEhZ6ODgT+jYMnghkzLD/FEm6UZLCU+xfGcb1iFOH6lNvXaw5/bxBfUnuuO
9+7wvw2TmZit6PAESj2msy3gS77JgaLOdrwk9GH3b4EZExLlqBTsY8n+HvfNL+qP
pkYlGl0SaWVnNlWYT3Y4pvLjs1MTrTZPUGD8sKz/6+YUdpyefIkuWVSjujEInOGx
EU9q8G4Zeg9GF4k7YaF3
=TdAU
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message