JDK-6384760 : 1.4.2_04 SIGBUS in PhaseIdealLoop::split_thru_region
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 1.4.2_04
  • Priority: P2
  • Status: Closed
  • Resolution: Duplicate
  • OS: solaris_9
  • CPU: sparc
  • Submitted: 2006-02-13
  • Updated: 2010-07-29
  • Resolved: 2006-03-28
Related Reports
Duplicate :  
Description
Crash of 1.4.2_04 on Solaris 9 4/04 running with -server -Xmx1000m -Xms1000m
It failed with SIGBUS while running in PhaseIdealLoop::split_thru_region

(dbx) where -h -l  current thread: t@8
=>[1] libc.so.1:__lwp_kill(0x0, 0x6, 0x0, 0xff33c000, 0x0, 0x0), at 0xff31f82c
 [2] libc.so.1:raise(0x6, 0x0, 0xb70fd360, 0x0, 0x23, 0xff00), at 0xff2d0a1c
 [3] libc.so.1:abort(0x0, 0xb70fd3f0, 0x0, 0xfffffff8, 0x0, 0xb70fd419), at 0xff2b6cd8
 [4] libjvm.so:os::abort(0x1, 0xff153722, 0xb70fd4a0, 0xff170000, 0xff1b78bc, 0x3db2e4), at 0xff098498
 [5] libjvm.so:os::handle_unexpected_exception(0xea4e0, 0xa, 0xfede7558, 0xb70fe208, 0xfedd87d8, 0x0), at 0xff0967ac
 [6] libjvm.so:JVM_handle_solaris_signal(0xfede7558, 0xb70fe208, 0xb70fdf50, 0x3400, 0x35ec, 0x0), at 0xfedd90ac
 [7] libthread.so.1:__sighndlr(0xa, 0xb70fe208, 0xb70fdf50, 0xfedd875c, 0x0, 0x0), at 0xff385bac
 [8] libthread.so.1:call_user_handler(0xa, 0xb70fe208, 0xb70fdf50, 0x0, 0x0, 0x0), at 0xff37f804
 [9] libthread.so.1:sigacthandler(0xa, 0xb70fe208, 0xb70fdf50, 0x20, 0x0, 0x0), at 0xff37f9b4
 ---- called from signal handler with signal 10 (SIGBUS) ------
 [10] libjvm.so:PhaseIdealLoop::split_thru_region(0x1ea86c, 0x3522f0, 0x4f1b10, 0xb70feef0, 0x4, 0xc), at 0xfede7558
 [11] libjvm.so:PhaseIdealLoop::do_split_if(0xb70feee0, 0x23ff84, 0xb70feb30, 0x1, 0x345848, 0x339411), at 0xfee20040
 [12] libjvm.so:PhaseIdealLoop::split_if_with_blocks(0xb70feee0, 0x4f1b10, 0xb70feb30, 0x0, 0x20e948, 0xffcb1b54), at 0xfeccf590
 [13] libjvm.so:PhaseIdealLoop::split_if_with_blocks(0xb70feee0, 0x3e034c, 0xb70feb30, 0xaea48, 0x2, 0x4580c8), at 0xfeccf568
 [14] libjvm.so:PhaseIdealLoop::split_if_with_blocks(0xb70feee0, 0x4f3a78, 0xb70feb30, 0xc, 0x4, 0x0), at 0xfeccf568
 [15] libjvm.so:PhaseIdealLoop::split_if_with_blocks(0xb70feee0, 0x4f3368, 0xb70feb30, 0x14, 0x4, 0x4), at 0xfeccf568
...
 [30] libjvm.so:PhaseIdealLoop::split_if_with_blocks(0xb70feee0, 0x185480, 0xb70feb30, 0x1, 0x0, 0x339409), at 0xfeccf568
 [31] libjvm.so:PhaseIdealLoop::PhaseIdealLoop(0xff1bbbe4, 0x0, 0xb70fef24, 0x1, 0x3f68, 0x1), at 0xfedc080c
 [32] libjvm.so:Compile::Optimize(0xb70ff500, 0xff1335c4, 0xb70ff414, 0xff170000, 0x0, 0x0), at 0xfee0211c
 [33] libjvm.so:Compile::Compile(0xff1333f9, 0x1854bc, 0x25245c, 0x3b601c, 0xffffffff, 0x1), at 0xfee008b4
 [34] libjvm.so:C2Compiler::compile_method(0x2b858, 0xb70ffd1c, 0x0, 0x37d448, 0xffffffff, 0x0), at 0xfedfd08c
 [35] libjvm.so:CompileBroker::invoke_compiler_on_method(0xaf, 0x0, 0xffffffff, 0xff1aee50, 0xff1bbbe4, 0xea4e0), at 0xfedfc850
 [36] libjvm.so:CompileBroker::compiler_thread_loop(0xff133c01, 0xff1af218, 0xea4e0, 0xeb298, 0x306d10, 0xfee69254), at 0xfeeac1f8
 [37] libjvm.so:JavaThread::run(0xea4e0, 0x8, 0x40, 0x0, 0x40, 0x0), at 0xfee6927c
 [38] libjvm.so:_start(0xea4e0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfee6575c


dbx) j142GetC2methNClass          (see also doc 76457)
0xfedfd08c: compile_method+0x0064:      call     Compile        ! 0xfedffd08
Class: com/jclark/xsl/expr/ExprTokenizer
Method: next

It is quite interesting also this thread

t@9 (l@9) stopped in PhaseChaitin::fixup_spills at 0xfedd9e70
0xfedd9e70: fixup_spills+0x00a0:        ba       fixup_spills+0xb0     ! 0xfedd9e80
current thread: t@9
=>[1] libjvm.so:PhaseChaitin::fixup_spills(0xb6e7eeb4, 0x5, 0x2edd18, 0x4316a8, 0x2ee178, 0x120), at 0xfedd9e70
[2] libjvm.so:PhaseChaitin::Register_Allocate(0xff1b8ae8, 0xff1bbbe4, 0xff1b0bf4, 0xb6e7ed2c, 0x4800, 0x4ac8), at  0xfedca3cc
[3] libjvm.so:Compile::Code_Gen(0xb6e7f500, 0xff1335c4, 0xb6e7f414, 0xff170000, 0x0, 0x0), at 0xfedd2d0c
[4] libjvm.so:Compile::Compile(0xff1333f9, 0x14164c, 0x3a017c, 0x98814, 0xffffffff, 0x1), at 0xfee008e8
[5] libjvm.so:C2Compiler::compile_method(0x2b858, 0xb6e7fd1c, 0x0, 0x3e48c8, 0xffffffff, 0x0), at 0xfedfd08c
[6] libjvm.so:CompileBroker::invoke_compiler_on_method(0xac, 0x0, 0xffffffff, 0xff1aee50, 0xff1bbbe4, 0xebc88), at 0xfedfc850
[7] libjvm.so:CompileBroker::compiler_thread_loop(0xff133c01, 0xff1af218, 0xebc88, 0xec238, 0x306d10, 0xfee69254), at 0xfeeac1f8
[8] libjvm.so:JavaThread::run(0xebc88, 0x9, 0x40, 0x0, 0x40, 0x0), at 0xfee6927c
[9] libjvm.so:_start(0xebc88, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfee6575c

running compilation

(dbx) j142GetC2methNClass      (see also doc 76457)
0xfedfd08c: compile_method+0x0064:      call     Compile        ! 0xfedffd08
Class: com/jclark/xsl/expr/ExprTokenizer
Method: scanName

extracting the class from the core (with SA tool) and decompiling you could notice the relationship b/w the 2 methods: in method next(), there is a call to scanName().

Comments
EVALUATION This is probably a duplicate of 5030922. The customer used a work around and is no longer responding so I am closing it as a dup. If new info appears re-open or open a new bug.
28-03-2006

WORK AROUND According to the info extracted from core (t@8 and t@9) use .hotspot_compiler in `cwd` for java: exclude com/jclark/xsl/expr/ExprTokenizer next exclude com/jclark/xsl/expr/ExprTokenizer scanName
13-02-2006