Bug ID: JDK-6483773 hotspot SIGSEGV in CE_Eliminator::block

Versions (Unresolved/Resolved/Fixed)

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
1.4.2_14 b01Fixed

hotspot appears to be looping in optimization code:
Core file at:
/net/cores.central/cores/dir4/65148856/101706/pkgcoredir

The stack trace of the thread that caused SIGSEGV:
--------------------------------------------------
fed146d8 void CE_Eliminator::block_do(BlockBegin*) (f1af44, fc56f868, fc56f8d0, f1b4d4, ff010000, 5f5f)
 fed146b8 void BlockBegin::iterate_preorder(boolArray&,BlockClosure*) (f18c2c, fc56f868, fc56f8d0, 0, ff010000, ff017444) + ac
... 
<truncated for clarity>
....

 fed145fc void BlockBegin::iterate_preorder(BlockClosure*) (13f874c, fc56f8d0, ff010000, 0, ff021600, ff0175f4) + c8
 fed14500 void Optimizer::eliminate_conditional_expressions() (fc56f93c, c9c580, 0, ffffffff, 7084a0, ffffffff) + 2c
 fed1448c void IR::optimize() (c9c580, fc56fc34, 7084a0, ffffffff, ff010000, 0) + 10
 fed01488 void Compilation::build_hir() (fc56fc34, ff010000, 2800, bc, ff010000, fefd8875) + d0
 fed00170 int Compilation::compile_java_method(CodeOffsets*) (fc56fc34, fc56fbbc, 10000, 0, ff010000, 0) + 70
 fecfff74 Compilation::Compilation(ciEnv*,ciMethod*,int,C1_MacroAssembler*) (fc56fc34, fc56fd54, 7084a0, ffffffff, cfdcc, 3b549c) + 248
 fecffc1c void Compiler::compile_method(ciEnv*,ciScope*,ciMethod*,int,int) (35938, fc56fd54, 0, 7084a0, ffffffff, 0) + 5c
 fecfa3d0 void CompileBroker::invoke_compiler_on_method(CompileTask*) (0, ffffffff, 0, ff021788, ff029650, cfb98) + 5a8
 fecf4fc8 void CompileBroker::compiler_thread_loop() (fefd8722, ff021b6c, 0, 4000, 41b8, fecd9294) + 464
 fecd92bc void JavaThread::run() (cfb98, ffffffe2, ff030d00, ffff8000, 0, 0) + 288
 fef56640 java_start (cfb98, ff310c00, 0, 0, 0, 0) + 134
 ff364c3c _lwp_start (0, 0, 0, 0, 0, 0)

WORK AROUND -server should also be a good workaround, should be better in the long term also as this is a server-type app. 2MB compiler thread stack size is what I see with -server, but CompilerThreadStackSize is then also respected.

20-10-2006

EVALUATION I think the problem is that they are running with -Xss128k and in 1.4.2 that setting is picked up by the compiler thread for C1. C1 uses recursion in a few places and for large methods it can recurse fairly deep during compilation. So that's likely why it's running out of stack during compilation. If you run with -Xss512k it should be able to complete the compilation. There's a flag CompilerThreadStackSize that's supposed to be the stack size for the compiler threads but in 1.4.2 that is only checked for C2. In 1.5 this was all fixed under the bug id 5030087. It was changed so that all internal threads use VMThreadStackSize as their initial size instead of picking up the value passed by -Xss and compiler threads will use CompilerThreadStackSize if it is set.

19-10-2006

WORK AROUND exclude the method we were compiling that resulted in the crash. fecfff74 Compilation::Compilation(ciEnv*,ciMethod*,int,C1_MacroAssembler*) (fc56fc34, fc56fd54, 7084a0, ffffffff, cfdcc, 3b549c) + 248 (dbx) x 0x7084a0 + 0x14 0x007084b4: 0x007084ec (dbx) x 0x007084ec+0x4 0x007084f0: 0x000ca328 (dbx) x 0x000ca328 0x000ca328: 0xf795dd98 (dbx) print (char *)0xf795dd98 + 14 ((char *) 0xf795dd98U)+14 = 0xf795dda6 "_jspService" (dbx) x 0x7084a0+0x18 0x007084b8: 0x007084fc (dbx) x 0x0070854c+0x4 0x00708550: 0x000ca330 (dbx) x 0x000ca330 0x000ca330: 0xf7aaba58 (dbx) print (char *)0xf7aaba58 +14 ((char *) 0xf7aaba58U)+14 = 0xf7aaba66 "jsp_servlet/_main/__home"

19-10-2006