JDK-6772368 : REGRESSION:tomcat crashed twice with JDK 7
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: hs12,6u14,7
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: linux,windows_vista
  • CPU: x86
  • Submitted: 2008-11-17
  • Updated: 2011-03-08
  • Resolved: 2011-03-08
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6 JDK 7 Other
6u14Fixed 7Fixed hs14Fixed
Related Reports
Duplicate :  
JDK-6687570 - 64-bit server compiler crashed in Parse::merge_exception
Relates :  
JDK-6621084 - ciMethodBlocks::split_block_at is broken for methods with exception handler
Description
J2SE Version (please include all output from java -version flag):
JRE (1.7.0-ea-b39)
Java HotSpot(TM) 64-Bit Server VM (14.0-b06)

Does this problem occur on J2SE 1.4.x or 5.0.x or 6.0?  Yes / No (pick one)
No, works fine with 6u10 FCS release.


Operating System Configuration Information (be specific):
Windows Vista Build 6001 Service Pack 1


Hardware Configuration Information (be specific):
windows-amd64


Bug Description:
    Tomcat crashed twice when using Atlassian Confluence under JDK7. 
Java6 update 10 works fine so the bug must have been introduced later on. 
Please see the attached error log files.
A portion of one of the hs_err_pid files:

#  Internal Error (parse1.cpp:1489), pid=1328, tid=1728
#  Error: ShouldNotReachHere()
#
# Java VM: Java HotSpot(TM) 64-Bit Server VM (14.0-b06 mixed mode windows-amd64

The second hs_err_pid file appears to be the same failure mode.
Same issue reported by 6u14 release and hope it can be fixed by 6u14 GA. check the error file(hs_err_pid2316.log) from 6u14.
the CAP has run the fastdebug build and get the same crash on 6u14 build 3 and JDK 7. Attached the error(hs_error_pid4612.log) and hotspot.log file.
Comments
EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/039a914095f4
18-03-2009
EVALUATION I grabbed an old copy of the ognl jar at http://mirrors.ibiblio.org/pub/mirrors/maven2/ognl/ognl/2.6.5 and was able to reproduce this bug with CompileTheWorld when compiling ognl.OgnlException.printStackStace. I extracted a testcase from the failing bytecodes which is below. super public class jp { public Method "<init>":"()V" stack 1 locals 1 { aload_0; invokespecial Method java/lang/Object."<init>":"()V" ; return; } public static Method main:"([Ljava/lang/String;)V" stack 2 locals 1 { new class jp; dup; invokespecial Method "<init>":"()V"; getstatic Field java/lang/System.out:"Ljava/io/PrintStream;"; invokevirtual Method bug:"(Ljava/io/PrintStream;)V"; return; } public Method bug:"(Ljava/io/PrintStream;)V" stack 2 locals 4 { goto L6; catch t0 #0; catch t1 #0; try t0; aload_2; monitorexit; endtry t0; athrow; L6: aload_1; dup; astore_2; monitorenter; try t1; aload_1; ldc String "error"; invokevirtual Method java/io/PrintStream.println:"(Ljava/lang/String;)V"; L42: aload_2; monitorexit; endtry t1; return; } } // end Class jp Running this class with -Xcomp -XX:CompileOnly=jp.bug jp results in the original failure. The problem seems to be that the fix for 6621084 changed where we break block boundaries. This change: int ex_start = handler->start(); int ex_end = handler->limit(); + if (eb->is_handler()) { + // Extend old handler exception range to cover additional range. + int old_ex_start = eb->ex_start_bci(); + int old_ex_end = eb->ex_limit_bci(); + if (ex_start > old_ex_start) + ex_start = old_ex_start; + if (ex_end < old_ex_end) + ex_end = old_ex_end; + eb->clear_exception_handler(); // Reset exception information + } eb->set_exception_range(ex_start, ex_end); // ensure a block at the start of exception range and start of following code (void) make_block_at(ex_start); will cause the make_block_at calls that use ex_start and ex_end to break at the limits of the combined range instead of the limits of the handler itself and this is what causes the failure with the test case above. I belive the proper fix is to call make_block_at with the original handler limits.
17-03-2009
EVALUATION Could you try running with a fastdebug build to see if it fails with another assertion? It's vaguely possible this the same as 6805522 and can put together a fix for you to try with this cange but I'd really like to see the results of a fastdebug run first. If we work quickly we might get this fixed for 6u14.
16-03-2009