|Summary:||Oracle JDK 1.6.0_26 build 20.1-b02 (installed from the Oracle tarball) crashes with Segmentation Fault on 64-bit RHEL6.1|
|Product:||Red Hat Enterprise Linux 6||Reporter:||David Tonhofer <bughunt>|
|Component:||java-1.6.0-sun||Assignee:||jiri vanek <jvanek>|
|Status:||CLOSED NOTABUG||QA Contact:||BaseOS QE - Apps <qe-baseos-apps>|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2012-01-11 09:54:08 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description David Tonhofer 2011-09-15 14:06:29 UTC
Description of problem: (Super vague problem. I'm using this bug just as a hook; if more info, will add.) Currently we only have: "Oracle JDK 1.6.0_26 build 20.1-b02 (installed from the Oracle tarball) crashes with Segmentation Fault on 64-bit RHEL6.1" How reproducible: Under load after an hour or so.
Comment 2 RHEL Product and Program Management 2011-09-15 14:28:31 UTC
This request was evaluated by Red Hat Product Management for inclusion in the current release of Red Hat Enterprise Linux. Because the affected component is not scheduled to be updated in the current release, Red Hat is unfortunately unable to address this request at this time. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux. If you would like it considered as an exception in the current release, please ask your support representative.
Comment 3 jiri vanek 2011-09-16 06:35:26 UTC
Why are you using tarballed jdk except of RPMd one? Also you can try latest released oracle tarball - u27 - there are many "segmentation faults" fixes. Can you provide some kind of reproducer? Then maybe we can fix it in openjdk or find jdk7 backport.
Comment 4 David Tonhofer 2011-09-20 09:47:29 UTC
Thank you for the response. > Why are you using tarballed jdk except of RPMd one? I like to have the stuff all under /usr/local/java, actually. The /opt hierarchy was a great idea IMHO. Anyway - Cannot reproduce with confidence. It seems to occur during a stack overflow - indeed deeply nested calls were being at the three crash times observed (which still had a size of -Xss=500k). One would expect a java.lang.StackOverflowError though. I tried to get a dump file from the process but no joy - didn't get one even with "ulimit -c unlimited"; nor did I get one of the good old "hs_err" files. Are these switched on only with -XX:ErrorFile nowadays? Added "-XX:ErrorFile=./hs_err_pid$$.log" (current directory writeable and all), so we will see. Unfortunately this system needs to be stable, so upgraded to build 1.6.0_27-b07. Currently rebuilding our test system, maybe I can get the crash back there.
Comment 5 David Tonhofer 2011-10-24 16:00:28 UTC
No problem with build 1.6.0_27-b07. Closing NOTABUG.