JDK-7103468 : JSR 292: JRuby test_respond_to.rb crashes with SIGBUS on SPARC
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: hs23,7
  • Priority: P3
  • Status: Resolved
  • Resolution: Cannot Reproduce
  • OS: generic,solaris,solaris_9
  • CPU: generic,sparc
  • Submitted: 2011-10-21
  • Updated: 2013-01-08
  • Resolved: 2013-01-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 8
8-poolResolved
Related Reports
Duplicate :  
JDK-7153482 - jruby tests start fail in hs23 b07 on sparcv9
Duplicate :  
JDK-7118850 - JSR292: SIGSEGV in java.lang.invoke.MethodHandle.invokeExact
Relates :  
JDK-8005873 - JRuby test_respond_to.rb asserts with: MT-unsafe modification of inline cache
Description
terminus:~/mlvm/jruby$ jruby -J-showversion -J-d64 --server -J-XX:+UseCompressedOops -J-Xcomp -J-XX:+DeoptimizeRandom test/test_respond_to.rb  
VM option '+UseCompressedOops'
VM option '+DeoptimizeRandom'
java version "1.8.0-ea"
Java(TM) SE Runtime Environment (build 1.8.0-ea-b10)
Java HotSpot(TM) 64-Bit Server VM (build 23.0-b03-internal-fastdebug, compiled mode)

Warning: Handler @13 takes mixed loaded/unloaded exceptions in static jboolean java.lang.Boolean.getBoolean(jobject)
Warning: Handler @13 takes mixed loaded/unloaded exceptions in static jboolean java.lang.Boolean.getBoolean(jobject)
Loaded suite test/test_respond_to
Started
..#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGBUS (0xa) at pc=0xffffffff7604bbb4, pid=15254, tid=2
#
# JRE version: 8.0-b10
# Java VM: Java HotSpot(TM) 64-Bit Server VM (23.0-b03-internal-fastdebug compiled mode solaris-sparc compressed oops)
# Problematic frame:
# j  java.lang.invoke.MethodHandle.invokeExact(Lorg/jruby/runtime/ThreadContext;Lorg/jruby/runtime/builtin/IRubyObject;Lorg/jruby/runtime/builtin/IRubyObject;Ljava/lang/String;Lorg/jruby/runtime/Block;)Lorg/jruby/runtime/builtin/IRubyObject;+25
#
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /home/ct232829/mlvm/jruby/hs_err_pid15254.log
                 -------------
  0  (0xffffffff51c02c20)  [b6|b7|    8]
                 [   0xffffffff51c027e8]
                 [   0xffffffff51c027e8]
                 [   0x000000000c800006]
                 -------------
  1  (0xffffffff51c02c40)  [b6|b7|   14]
                 [   0xffffffff51c02940]
                 [   0xffffffff51c02940]
                 [   0x000000007c800002]
                 -------------
  2  (0xffffffff51c02c60)  [b6|b7|   20]
                 [   0xffffffff51944f88]
                 [   0xffffffff51944f88]
                 [   0x000000007c800006]
                 -------------
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.sun.com/bugreport/crash.jsp
#
Current thread is 2
Dumping core ...
Abort
Comments
I'm closing this as "Cannot Reproduce" because it was very likely an issue with the old JSR 292 implementation. And I cannot reproduce it with the new implementation.
08-01-2013
EVALUATION A test run with 7u4-ea on linux-x64 triggered this assert: sc14ia06:~/mlvm/jruby$ jruby -J-showversion -J-d64 --server -J-XX:+UseCompressedOops -J-Xcomp -J-XX:+DeoptimizeRandom test/test_respond_to.rb java version "1.7.0_04-ea-fastdebug" Java(TM) SE Runtime Environment (build 1.7.0_04-ea-fastdebug-b13) Java HotSpot(TM) 64-Bit Server VM (build 23.0-b16-fastdebug, compiled mode) Loaded suite test/test_respond_to Started .# To suppress the following error report, specify this argument # after -XX: or in .hotspotrc: SuppressErrorAt=/compiledIC.cpp:530 # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/HUDSON/workspace/jdk7u4-2-build-linux-amd64-product/jdk7u4/hotspot/src/share/vm/code/compiledIC.cpp:530), pid=7225, tid=140017361913616 # assert(method_holder->data() == 0 || method_holder->data() == (intptr_t)callee()) failed: a) MT-unsafe modification of inline cache # # JRE version: 7.0_04-b13 # Java VM: Java HotSpot(TM) 64-Bit Server VM (23.0-b16-fastdebug compiled mode linux-amd64 compressed oops) # Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again # # An error report file with more information is saved as: # /home/cthaling/mlvm/jruby/hs_err_pid7225.log
29-02-2012
EVALUATION The problem is related to method handle adapter frames. It seems the unpacking such frames results in invalid stack pointers and/or stack content.
14-02-2012
EVALUATION (dbx) where current thread: t@2 [1] __waitid(0x0, 0x2bd7, 0xffffffff7dff4150, 0x3, 0x0, 0x0), at 0xffffffff7eee7674 [2] waitid(0x0, 0xffffffff7da00240, 0xffffffff7dff4150, 0x3, 0xffffffff7da00240, 0x2bd7), at 0xffffffff7eed4c68 [3] waitpid(0x2bd7, 0xffffffff7dff430c, 0x0, 0xffffffff7da00240, 0xffffffff7f084d00, 0x2bd7), at 0xffffffff7ee9bbb4 =>[4] os::fork_and_exec(cmd = ???) (optimized), at 0xfffffffd31d73ed4 (line ~6382) in "os_solaris.cpp" [5] VMError::report_and_die(this = ???) (optimized), at 0xfffffffd320c6510 (line ~819) in "vmError.cpp" [6] JVM_handle_solaris_signal(sig = ???, info = ???, ucVoid = ???, abort_if_unrecognized = ???) (optimized), at 0xfffffffd31d78860 (line ~596) in "os_solaris_sparc.cpp" [7] __sighndlr(0xb, 0xffffffff7dff4d40, 0xffffffff7dff4a60, 0xfffffffd31d6e690, 0x0, 0xffffffff7f07e000), at 0xffffffff7eee2554 ---- called from signal handler with signal 11 (SIGSEGV) ------ [8] 0xffffffff6ac528c8(0xdead0000, 0xdead0002, 0x7dd7022d8, 0xffffffff6ac5254c, 0xdead0008, 0xffffffff7dff47c1), at 0xffffffff6ac528c8 [9] 0xffffffff6ac07640(0xdead0000, 0xdead0002, 0x7dd700fb0, 0xdead0006, 0xdead0008, 0xffffffff7dff4941), at 0xffffffff6ac07640 [10] 0xffffffff6ac08330(0xdead0000, 0xdead0002, 0x7dd4ccf40, 0xdead0006, 0xdead0008, 0xffffffff7dff4a91), at 0xffffffff6ac08330 [11] 0xffffffff6c175e98(0x7e0c8e428, 0x7e0c00b90, 0x7e0dfba98, 0x7f623fe60, 0x7f623fda8, 0x7e0d7dcc8), at 0xffffffff6c175e98 [12] 0xffffffff6c2b7760(0x7e0c8e428, 0x7e0c00b90, 0x7e0dfba98, 0x7f623fde0, 0x7f623fda8, 0x7f623fda8), at 0xffffffff6c2b7760 <snip> (dbx) p ps() "Executing ps" for thread: "main" prio=3 tid=0x000000010020c800 nid=0x2 runnable [0x0000000000000000] java.lang.Thread.State: RUNNABLE JavaThread state: _thread_in_Java Thread: 0x000000010020c800 [0x 2] State: _running _has_called_back 0 _at_poll_safepoint 0 JavaThread state: _thread_in_Java (guessing starting frame id=ffffffff7dff40a0 based on current fp) C frame (sp=0xffffffff7dff40a0 unextended sp=0xffffffff7dff40a0, fp=0xffffffff7dff4250, pc=0xffffffff7ee9bbbc) C frame (sp=0xffffffff7dff4250 unextended sp=0xffffffff7dff4250, fp=0xffffffff7dff4330, pc=0xfffffffd31d73edc) C frame (sp=0xffffffff7dff4330 unextended sp=0xffffffff7dff4330, fp=0xffffffff7dff4580, pc=0xfffffffd320c6518) C frame (sp=0xffffffff7dff4580 unextended sp=0xffffffff7dff4580, fp=0xffffffff7dff4750, pc=0xfffffffd31d78868) C frame (sp=0xffffffff7dff4750 unextended sp=0xffffffff7dff4750, fp=0xffffffff7dff4800, pc=0xffffffff7eee255c) C frame (sp=0xffffffff7dff4800 unextended sp=0xffffffff7dff4800, fp=0xffffffff7dff48f0, pc=0xffffffff7eed5b90) C frame (sp=0xffffffff7dff48f0 unextended sp=0xffffffff7dff48f0, fp=0xffffffff7dff49a0, pc=0xffffffff7eed5dc0) 1 - frame( sp=0xffffffff7dff49a0, unextended_sp=0xffffffff7dff49a0, fp=0xffffffff7dff4fa0, pc=0xffffffff6ac07420) java.lang.invoke.MethodHandle.invokeExact 2 - frame( sp=0xffffffff7dff4fa0, unextended_sp=0xffffffff7dff4fc0, fp=0xffffffff7dff5120, pc=0xffffffff6ac07648) java.lang.invoke.MethodHandle.invokeExact 3 - frame( sp=0xffffffff7dff5120, unextended_sp=0xffffffff7dff5140, fp=0xffffffff7dff5260, pc=0xffffffff6ac08338) rubyjit.\=Test\!\!Unit\!\!Assertions#assert_block_FE26BFB334F1AA527DC447C57F3C530A836A8CC5.__file__(/home/ct232829/mlvm/jruby/lib/ruby/1.8/test/unit/assertions.rb:46) 4 - frame( sp=0xffffffff7dff5260, unextended_sp=0xffffffff7dff5290, fp=0xffffffff7dff5320, pc=0xffffffff6c175ea0) rubyjit.\=Test\!\!Unit\!\!Assertions#assert_block_FE26BFB334F1AA527DC447C57F3C530A836A8CC5.__file__ 5 - frame( sp=0xffffffff7dff5320, unextended_sp=0xffffffff7dff5320, fp=0xffffffff7dff53b0, pc=0xffffffff6c2b7768) org.jruby.ast.executable.AbstractScript.__file__(AbstractScript.java:42) <snip> (dbx) p findpc((long) 0xffffffff6ac528c8) "Executing findpc" 0xffffffff6ac528c8 is an Interpreter codelet invokevirtual 182 invokevirtual [0xffffffff6ac522e0, 0xffffffff6ac52b40] 2144 bytes findpc((long ) 18446744071205890248U) = (void) (dbx) fr 8 0xffffffff6ac528c8: ldx [%o0], %g0 (dbx) x $o0 0x0000000700000000: dbx: read of 4 bytes at address 700000000 failed It fails at this code snippet: 0xffffffff6ac528bc: lduh [%g5 + 58], %g4 0xffffffff6ac528c0: sll %g4, 3, %g4 0xffffffff6ac528c4: ldx [%l0 + %g4], %o0 0xffffffff6ac528c8: ldx [%o0], %g0 which is this code in TemplateTable::invokevfinal_helper: // Load receiver from stack slot __ lduh(G5_method, in_bytes(methodOopDesc::size_of_parameters_offset()), G4_scratch); __ load_receiver(G4_scratch, O0); // receiver NULL check __ null_check(O0); G5 is valid: (dbx) x $g5 0x00000007dd701ec8: 0x00000000 (dbx) p findpc((long) $g5) "Executing findpc" 0x00000007dd701ec8 is an oop {method} - klass: {other class} - this oop: 0x00000007dd701ec8 - method holder: 'java/lang/invoke/MethodHandle' - constants: 0x00000007dd701e08 constant pool [4]/pseudo_string/preresolution for 'java/lang/invoke/MethodHandle' (extra) - access: 0x90001111 public final native synthetic - name: 'invokeExact' - signature: '(Z)Ljava/lang/invoke/MethodHandle;' - max stack: 0 - max locals: 0 - size of params: 2 - method size: 19 - intrinsic id: 146 _invokeExact - vtable index: -2 - i2i entry: 0xffffffff6ac21c60 - adapter: 0x0000000100305ce8 - compiled entry 0xffffffff6acd7c68 - code size: 0 - checked ex length: 0 - localvar length: 0 - invoke method type: 0x00000007e0c041a8 findpc((long ) $g5) = (void) (dbx) p $g4 $g4 = 16ULL $l0 seems to be pointing into the stack of the thread: (dbx) p findpc((long) $l0) "Executing findpc" 0xffffffff7dff4f58 is pointing into the stack for thread: 0x000000010020c800 "main" prio=3 tid=0x000000010020c800 nid=0x2 runnable [0x0000000000000000] java.lang.Thread.State: RUNNABLE JavaThread state: _thread_in_Java Thread: 0x000000010020c800 [0x 2] State: _running _has_called_back 0 _at_poll_safepoint 0 JavaThread state: _thread_in_Java but the stack values around that area look suspicious: (dbx) x $l0 / 12 0xffffffff7dff4f58: 0x00000000 0x00000000 0x00000000 0x00000000 0xffffffff7dff4f68: 0x00000007 0x00000000 0x00000000 0x00000000 0xffffffff7dff4f78: 0x00000000 0x00000000 0x00000000 0x00000000 Printing more of the stack shows valid oops: (dbx) x $l0 / 32 0xffffffff7dff4f58: 0x00000000 0x00000000 0x00000000 0x00000000 0xffffffff7dff4f68: 0x00000007 0x00000000 0x00000000 0x00000000 0xffffffff7dff4f78: 0x00000000 0x00000000 0x00000000 0x00000000 0xffffffff7dff4f88: 0x00000000 0x00000000 0x00000000 0x00000000 0xffffffff7dff4f98: 0x00000000 0x00000000 0xffffffff 0x7dff50b8 0xffffffff7dff4fa8: 0x00000007 0xdd700c35 0x00000007 0xdd700c40 0xffffffff7dff4fb8: 0xffffffff 0x7dff5228 0xffffffff 0x7dff50f0 0xffffffff7dff4fc8: 0xffffffff 0x7dff47a1 0x00000007 0xdd700e08
10-02-2012
EVALUATION I can still reproduce it with HS23-b15. $ jruby -J-showversion -J-d64 --server -J-XX:+UseCompressedOops -J-Xcomp -J-XX:+DeoptimizeRandom test/test_respond_to.rb java version "1.8.0-ea" Java(TM) SE Runtime Environment (build 1.8.0-ea-b25) Java HotSpot(TM) 64-Bit Server VM (build 23.0-b15-internal-fastdebug, compiled mode) Warning: Handler @847569456 takes mixed loaded/unloaded exceptions in virtual jobject java.lang.Class.getEnumConstantsShared() # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0xffffffff6ac528c8, pid=25057, tid=2 # # JRE version: 8.0-b25 # Java VM: Java HotSpot(TM) 64-Bit Server VM (23.0-b15-internal-fastdebug compiled mode solaris-sparc compressed oops) # Problematic frame: # j java.lang.invoke.MethodHandle.invokeExact(Lorg/jruby/runtime/ThreadContext;Lorg/jruby/runtime/builtin/IRubyObject;Lorg/jruby/runtime/builtin/IRubyObject;Ljava/lang/String;)Lorg/jruby/runtime/builtin/IRubyObject;+16 # # Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again # # An error report file with more information is saved as: # /home/ct232829/mlvm/jruby/hs_err_pid25057.log ------------- 0 (0x00000007dd3bfce0) [b6|b7| 8] [ 0x00000007dd3bf8a0] [ 0x00000007dd3bf8a0] [ 0x000000000c800005] ------------- 1 (0x00000007dd3bfd00) [b6|b7| 14] [ 0x00000007dd3bf9f8] [ 0x00000007dd3bf9f8] [ 0x000000007c800002] ------------- 2 (0x00000007dd3bfd20) [b6|b7| 20] [ 0x00000007dd38bd40] [ 0x00000007dd38bd40] [ 0x000000007c800005] ------------- # # If you would like to submit a bug report, please visit: # http://bugreport.sun.com/bugreport/crash.jsp # Current thread is 2 Dumping core ... Abort
10-02-2012
EVALUATION (dbx) fr 8 0xffffffff7604bbb4: ld [%o0 + 8], %o5 (dbx) p -f "%p" $o0 $o0 = ffffffffdeaddeaf (dbx) p findpc((long)0xffffffff7604bbb4) "Executing findpc" 0xffffffff7604bbb4 is an Interpreter codelet checkcast 192 checkcast [0xffffffff7604baa0, 0xffffffff7604bfe0] 1344 bytes findpc((long ) 18446744071394606004U) = (void)
21-10-2011
EVALUATION With -UseCompressedOops it just segfaults: Loaded suite test/test_respond_to Started .Segmentation Fault A product build also fails with the same SIGBUS. Omitting DeoptimizeRandom also triggers the bug. It also happens with a debug build but takes a very long time to trigger. 32-bit seems to run fine.
21-10-2011