JDK-6518092 : 1.5.0_05 crash in method::handler_for_exception_and_pc
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 5.0u9,5.0u4,5.0u5,5.0u8
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: solaris_8,solaris_9,solaris_10
  • CPU: sparc
  • Submitted: 2007-01-26
  • Updated: 2014-02-27
  • Resolved: 2007-03-27
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.
Other
5.0u12 b02Fixed
Related Reports
Duplicate :  
JDK-6492085 - jvm crash with InterpreterRuntime::exception_handler_for_exception
Description
Crash of 1.5.0_05-b05 handling exception in compiled code 

/net/balabiot.italy/calls/37765877_vodafone/CORE_DATA/core.315.dbx.whereall

current thread: t@98
=>[1] __lwp_kill(0x0, 0x6, 0x0, 0x7fb3c000, 0x7f6591dc, 0x142e7c), at 0x7fb1fb84
 [2] raise(0x6, 0x0, 0x17a7e2b0, 0x722c, 0x8154, 0x8000), at 0x7fad0b9c
 [3] abort(0x6800, 0x7f79c000, 0x7f659178, 0x7f7f07ec, 0x0, 0x34128), at 0x7fab6d10
 [4] os::abort(0x1, 0x0, 0x7f7cff3c, 0x7f79c000, 0x7134, 0x7000), at 0x7f653234
 [5] VMError::report_and_die(0x0, 0x7f7f6b78, 0x7f7f07c4, 0x1, 0x7f6572ac, 0x7f7f07c4), at 0x7f6d2dc0
 [6] JVM_handle_solaris_signal(0xb, 0x17a7e9b0, 0x17a7e6f8, 0x7400, 0x7f7ef7f4,  0x1dbcd88), at 0x7f273d44
 [7] __sighndlr(0xb, 0x17a7e9b0, 0x17a7e6f8, 0x7f273260, 0x0, 0x0), at 0x7fb85b ac
 ---- called from signal handler with signal 11 (SIGSEGV) ------
 [8] nmethod::handler_for_exception_and_pc(0x0, 0x17a7edb4, 0x7a119de4, 0x7f79c000, 0x7f7e9c4c, 0x2), at 0x7f647f3c
 [9] OptoRuntime::handle_exception_C_helper(0x1dbcd88, 0x17a7f58c, 0x7f7e4624, 0x0, 0x7f79c000, 0x82c4), at 0x7f67c634
 [10] OptoRuntime::handle_exception_C(0x1dbcd88, 0x79d4947c, 0x1fb904a8, 0x79814130, 0x108, 0x0), at 0x7f67c91c
 [11] 0x79830b58(0x0, 0x7a119de4, 0x1d88b750, 0x1, 0x1, 0x1), at 0x79830b58
.... 

/net/balabiot.italy/calls/37765877_vodafone/CORE_DATA/core.315.pstack

---- t@98 -----------------
0x7fb1fb84    _lwp_kill + 0x8
0x7fab6d10    abort + 0x100
0x7f653234    void os::abort(int) + 0x58
0x7f6d2dc0    void VMError::report_and_die() + 0xc84
0x7f273d44    JVM_handle_solaris_signal + 0xaac
0x7fb85bac    __sighndlr + 0xc
0x7fb7f804    call_user_handler + 0x234
0x7fb7f9b4    sigacthandler + 0x64
0x7f647f3c    unsigned char*nmethod::handler_for_exception_and_pc(Handle,unsigned char*) + 0x18
0x7f67c91c    unsigned char*OptoRuntime::handle_exception_C(JavaThread*) + 0x28
0x79830b58    <ExceptionStub>
0x7a119ddc    0x7a119ddc    * org.apache.coyote.http11.InternalInputBuffer.endRequest() bci:24 line:368 methodOop:0x1e4510b0 (Compiled frame; information may be imprecise)
0x7a09dce4    0x7a09dce4    * org.apache.coyote.http11.Http11Processor.process(java.io.InputStream, java.io.OutputStream) bci:635 line:881 methodOop:0x1e43a888 (Compiled frame)
0x7aa64194    0x7aa64194    * org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(org.apache.tomcat.util.net.TcpConnection, java.lang.Object[]) bci:113 line:744 methodOop:0x1dc84940 (Compiled frame)
0x7a91382c    0x7a91382c    * org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket (java.net.Socket, org.apache.tomcat.util.net.TcpConnection, java.lang.Object[]) bci:45 line:527 methodOop:0x1dc81098 (Compiled frame)
0x7abe41a0    0x7abe41a0    * org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(java.lang.Object[]) bci:102 line:80 methodOop:0x1e4340e8 (Compiled frame)
0x7a8485fc    0x7a8485fc    * org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run() bci:167 line:684 methodOop:0x1e42f8f0 (Compiled frame)
0x79a0f8b8    <OSRAdapter>
0x79805c2c    * java.lang.Thread.run() bci:11 line:595 methodOop:0x1d82cec0 (Interpreted frame)
0x79800218    <StubRoutines>
0x7f197ad8    void JavaCalls::call_helper(JavaValue*,methodHandle*,JavaCallArguments*,Thread*) + 0x5a0
0x7f2bfc54    void JavaCalls::call_virtual(JavaValue*,Handle,KlassHandle,symbolHandle,symbolHandle,Thread*) + 0x188
0x7f2dec98    void thread_entry(JavaThread*,Thread*) + 0x134
0x7f2da834    void JavaThread::run() + 0x1d8
0x7f652d50    void*_start(void*) + 0x208
0x7fb85854    _lwp_start

They have started jvm with the following arguments:

0xffbff890:     "/opt/criticalpath/java/bin/java"
0xffbff8b0: "-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager"
0xffbff8f2:     "-server"
0xffbff8fa:     "-Xms512m"
0xffbff903:     "-Xmx1400m"
0xffbff90d:     "-XX:+UsePerfData"
0xffbff91e:     "-Xnoclassgc"
0xffbff92a:     "-verbose:gc"
0xffbff936:     "-Dsun.rmi.dgc.server.gcInterval=Long.MAX_VALUE"
0xffbff965:     "-Dsun.rmi.dgc.client.gcInterval=Long.MAX_VALUE"
0xffbff994:     "-XX:NewSize=133m"
0xffbff9a5:     "-XX:MaxNewSize=133m"
0xffbff9b9:     "-XX:SurvivorRatio=8"
0xffbff9cd:     "-XX:+MaxFDLimit"
0xffbff9dd:     "-XX:SoftRefLRUPolicyMSPerMB=500"
0xffbff9fd:     "-Djava.endorsed.dirs=/opt/criticalpath/ps/common/endorsed"
0xffbffa37:     "-classpath"
0xffbffa42: ":/opt/criticalpath/ps/bin/bootstrap.jar:/opt/criticalpath/ps/bin/commons-logging-api.jar"
0xffbffa9b:     "-Dcatalina.base=/opt/criticalpath/ps"
0xffbffac0:     "-Dcatalina.home=/opt/criticalpath/ps"
0xffbffae5:     "-Djava.io.tmpdir=/opt/criticalpath/ps/temp"
0xffbffb10:     "org.apache.catalina.startup.Bootstrap"
0xffbffb36:     "start"

Running on
SunOS UMLight-FE2 5.9 Generic_118558-22 sun4u sparc SUNW,Sun-Fire-280R
Comments
WORK AROUND The only workaround in production mode would be to disable the compilation of the problematic method. It will always be an OSR compiled method that returns a long so -XX:+PrintCompilation output may be useful in diagnosing this. LogCompilation output could also be used. In this case it is org.apache.coyote.http11.filters.IdentityInputFilter.end, so put this in the .hotspot_compiler file: exclude org/apache/coyote.http11/filters/IdentityInputFilter.end or put this on the command line -XX:CompileCommand=exclude,org/apache/coyote.http11/filters/IdentityInputFilter.end
21-02-2007
SUGGESTED FIX *** /tmp/geta24191 Tue Feb 20 14:55:50 2007 --- sparc.ad Tue Feb 20 14:55:48 2007 *************** *** 1231,1238 **** // If we are returning a long value back to the interpreter, we need to copy it from // G1 to I0:I1 so the register allocator will not have to deal with the misaligned register // pair. We do a copy in the other direction in for calls to native methods and runtime functions. ! if( (C->start()->Opcode() == Op_StartI2C || ! C->start()->Opcode() == Op_StartOSR) && C->tf()->returns_long() ) { __ srlx ( G1, 32, I0 ); __ srl ( G1, 0, I1 ); } --- 1231,1239 ---- // If we are returning a long value back to the interpreter, we need to copy it from // G1 to I0:I1 so the register allocator will not have to deal with the misaligned register // pair. We do a copy in the other direction in for calls to native methods and runtime functions. ! // This is only done for real Returns. Other method exit points should be left alone. ! if( do_polling() && (C->start()->Opcode() == Op_StartI2C || ! C->start()->Opcode() == Op_StartOSR) && C->tf()->returns_long() ) { __ srlx ( G1, 32, I0 ); __ srl ( G1, 0, I1 ); }
20-02-2007
EVALUATION If we have an OSR nmethod that returns a long and we have an exit from the compile with a rethrow_Java call we'll overwrite the returned exception with the contents of G1 because of this code in the MachEpilogNode: // G1 to I0:I1 so the register allocator will not have to deal with the misaligned register // pair. We do a copy in the other direction in for calls to native methods and runtime functions. if( (C->start()->Opcode() == Op_StartI2C || C->start()->Opcode() == Op_StartOSR) && C->tf()->returns_long() ) { __ srlx ( G1, 32, I0 ); __ srl ( G1, 0, I1 ); } This code should only be emitted if it's for an exit for a return. Here's a test case. public class osrlong { public static void main(String[] args) { while (true) { try { loop(30000); } catch (InternalError e) { } } } static volatile int one = 1; static int read(int n) throws InternalError { if (n == one) throw new InternalError(); return one; } static long loop(int n) { long bytes = 0; while (n > 0) { int b = read(n); bytes += b; n -= b; } return bytes; } } 1.6 doesn't have this problem because we no longer have adapter frames so this issue is dealt with by the compiled_return_entry_points in the interpeter. 1.4 doens't have this code at all, so it's a 1.5 issue. In the original core you can see this by looking at the nmethod 0x7b02d908. The exception_cache is filled in an look like this: printas ExceptionCache 0x00e3c010 pointer to ExceptionCache @ 0x00e3c010 (size = 140) int ExceptionCache::_count: 1 <opaque> ExceptionCache::_handler: <opaque> @ 0x00e3c054 <opaque> ExceptionCache::_pc: <opaque> @ 0x00e3c014 klassOop ExceptionCache::_exception_type: InstanceKlass for java/net/SocketException @ 0x1dc81c20 Oop @ 0x1dc81c20 ExceptionCache* ExceptionCache::_next: ExceptionCache @ null The first entry of _pc table is 0x7b02db98 and the _handler is 0x7b02ddac. 0x7b02ddac: mov %o0, %i0 0x7b02ddb0: ba,pt %icc, 0x7b02dc0c 0x7b02ddb4: nop This is a normal exception catch point which then dispatches to here. 0x7b02dc0c: srlx %g1, 32, %i0 0x7b02dc10: srl %g1, 0, %i1 0x7b02dc14: restore 0x7b02dc18: sethi %hi(0x79833400), %g3 0x7b02dc1c: jmp %g3 + 0x2c0 0x7b02dc20: nop 0x798336c0 is rethrow_Java. Here's 1.5.0_05 dying on the test case. smite ~ /java/re/jdk/1.5.0_05/latest/binaries/solaris-sparc/bin/java -server -XX:+PrintCompilation -Xbatch osrlong 1 b osrlong::loop (25 bytes) 1% b osrlong::loop @ 2 (25 bytes) 2% b osrlong::loop @ 2 (25 bytes) # # An unexpected error has been detected by HotSpot Virtual Machine: # # SIGSEGV (0xb) at pc=0xfe9c7b34, pid=24413, tid=1 # # Java VM: Java HotSpot(TM) Server VM (1.5.0_05-b05 mixed mode) # Problematic frame: # V [libjvm.so+0x1c7b34] # # An error report file with more information is saved as hs_err_pid24413.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # Abort (core dumped) This particular version shows this call stack: Stack: [0xffb7e000,0xffc00000), sp=0xffbfd7b8, free space=509k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x1c7b34];; __1cSInterpreterRuntimebFexception_handler_for_exception6FpnKJavaThread_pnHoopDesc__pC_+0x3c4 j osrlong.main([Ljava/lang/String;)V+3 v ~StubRoutines::call_stub V [libjvm.so+0x197ae0];; __1cJJavaCallsLcall_helper6FpnJJavaValue_pnMmethodHandle_pnRJavaCallArguments_pnGThread__v_+0x5a8 V [libjvm.so+0x2dafb4];; jni_CallStaticVoidMethod+0x508 C [java+0x23bc] main+0x131c but if the caller were compiled we'd see the same call stack as this core file. Here's a patched version of 1.5.0_05 working just fine. smite ~ % /export/ws/esi1.5.0_05/sparc/jdk1.5.0/bin/java -server -XX:+PrintCompilation -Xbatch osrlong 1 b osrlong::loop (25 bytes) 1% b osrlong::loop @ 2 (25 bytes) 2% b osrlong::loop @ 2 (25 bytes) 2 b osrlong::loop (25 bytes) 3*s b java.lang.Throwable::fillInStackTrace (0 bytes) 4 b java.lang.InternalError::<init> (5 bytes) 3% !b osrlong::main @ 0 (14 bytes)
20-02-2007
WORK AROUND exclude compilation of the last compiled method using file .hotspot_compiler in the current working directory for the jvm, with the following line: exclude org/apache/coyote/http11/InternalInputBuffer endRequest
26-01-2007