Java Solaris Communities Sun Store Join SDN My Profile Why Join?
 
Bug Database
Bug Detail
Quick Lists
Top 25 Bugs
Top 25 RFE's
Recently Closed Bugs
Printable Page Printable Page


Bug Database
Bug ID: 6772368
Votes 0
Synopsis REGRESSION:tomcat crashed twice with JDK 7
Category hotspot:compiler2
Reported Against b01 , b06
Release Fixed hs15(b04), 6u14(b04) (Bug ID:2174536) , hs14(b13) (Bug ID:2174537) , 7(b53) (Bug ID:2175225)
State 10-Fix Delivered, bug
Priority: 2-High
Related Bugs 6621084 , 6687570
Submit Date 17-NOV-2008
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.
Posted Date : 2008-11-17 16:27:18.0

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.
Posted Date : 2008-11-17 16:50:30.0

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.
Posted Date : 2009-03-16 21:17:01.0

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.
Posted Date : 2009-03-17 16:34:08.0
Work Around
N/A
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.
Posted Date : 2009-03-16 22:05:54.0

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.
Posted Date : 2009-03-17 17:03:38.0

http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/039a914095f4
Posted Date : 2009-03-18 23:39:33.0
Comments
  
  Include a link with my name & email   

Submitted On 15-MAR-2009
cowwoc
Please note that this bug also affects Java6 update 14 build 3, 32-bit and 64-bit versions.



PLEASE NOTE: JDK6 is formerly known as Project Mustang