2012/2/10 Allen Reese <are...@yahoo-inc.com>: > Try again now that I'm subscribed. > > >> -----Original Message----- >> From: Allen Reese >> Sent: Thursday, February 09, 2012 12:03 PM >> To: 'users@tomcat.apache.org' >> Cc: Lars Anderson >> Subject: Cores with FlushableGzipOutputStream >> >> We've just upgraded from tomcat 6.0.33 to 6.0.35 and started having the >> JVM core on our production boxes. >> >> I'm trying to determine what the next course of action should be here. >> I have an Oracle Support contract, but they don't seem to see this as a >> JVM issue, and blame it on a native lib. >> >> >> Thanks. >> >> Allen Reese >> Core Platforms >> Yahoo!, Inc. >> >> Running on linux x86-64, jdk 6u27, 6u29, 6u30, 7u2 >> >> We run several tests and the output is: >> >> Jdk | Version | flags >> | >> 6u30 | 6.0.33 | compression enabled >> | works >> 6u30 | 6.0.35 | compression enabled >> | cores >> 6u30 | 6.0.35 | compression disabled >> | works >> 6u30 | 6.0.35 | Remove changes to FlushableGzipOutputStream [1] >> | works >> 6u30 | 6.0.35 | -Dsun.zip.disableMemoryMapping=true >> | cores >> >> 7u2 | 6.0.35 | compression enabled >> | cores >> 7u2 | 6.0.35 | compression disabled >> | >> 7u2 | 6.0.35 | Remove changes to FlushableGzipOutputStream [1] >> | >> 7u2 | 6.0.35 | -Dsun.zip.disableMemoryMapping=true >> | cores >> >> https://issues.apache.org/bugzilla/show_bug.cgi?id=52121 >> >> I filed an SR with Oracle, as this looks like a JVM bug and got the >> following response: >> >> Generic Note >> ------------------------ >> Hi Allen, >> >> Thank you for sending the hotspot error logs (hs_err_pid<pid>). Each >> one of them has verbiage that indicates the problem is not with Java, >> but with native code: >> >> # Problematic frame: >> # C [libzip.so+0x77e3] char+0xa3 >> # >> # If you would like to submit a bug report, please visit: >> # http://java.sun.com/webapps/bugreport/crash.jsp >> # The crash happened outside the Java Virtual Machine in native code. >> # See problematic frame for where to report the bug. >> # >> >> The case description also noted: >> >> Rolling back this patch to tomcat increases stability: >> http://svn.apache.org/viewvc?view=revision&revision=1197382 >> >> Again, this points to software other than Java. The Java defect >> mentioned, 4813885, was fixed in June of 2009. >> ===================== >> >> Allen Reese >> Core Platforms >> Yahoo!, Inc. >> >> [1]: Patch to remove changes to FlushableGZIPOutputStream from 6.0.35. >> >>(...) >>
Hi! If you revert r1197382 you will be facing BZ 52121 [1]. Overall, BZ 52121 itself was about a bug in Deflater implementation in JRE. The difference is that I tried to make the new implementation as safe as possible, making sure that Deflater.setLevel() calls do not occur in a row, but there is some data between them. Either way Deflater API does not have such limitation on the use of setLevel(), so the root cause of BZ 52121 is a JRE bug. I think that the current code is safe and you hitting a different issue. Your "better stability" is likely a luck caused by a different state of Deflater thanks to different implementation at Tomcat side. Maybe you have some web resource that consistently produces a response that triggers this issue. >From experience of BZ 52121 we were lucky that someone was able to provide sample data that reproduced the issue. It looks that originally it was some product listing generated by JSP page. Maybe you can find something similar. That data is now part of Tomcat testsuite (see TestFlushableGZIPOutputStream class). Note that the reproducer is rather simple and does not use Tomcat, but just the streams I/O. Anyway, a JRE should not fail fatally with a core dump regardless of what public API the program uses. [1] https://issues.apache.org/bugzilla/show_bug.cgi?id=52121 Best regards, Konstantin Kolinko --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
