United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6772368 REGRESSION:tomcat crashed twice with JDK 7
JDK-6772368 : REGRESSION:tomcat crashed twice with JDK 7

Details
Type:
Bug
Submit Date:
2008-11-17
Status:
Closed
Updated Date:
2011-03-08
Project Name:
JDK
Resolved Date:
2011-03-08
Component:
hotspot
OS:
windows_vista,linux
Sub-Component:
compiler
CPU:
x86
Priority:
P2
Resolution:
Fixed
Affected Versions:
hs12,6u14,7
Fixed Versions:
hs15 (b04)

Related Reports
Backport:
Backport:
Backport:
Backport:
Duplicate:
Relates:

Sub Tasks

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

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.
                                     
2009-03-16
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.
                                     
2009-03-17
EVALUATION

http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/039a914095f4
                                     
2009-03-18



Hardware and Software, Engineered to Work Together