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 <ch...@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 > <ma...@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-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
