-
Bug
-
Resolution: Won't Fix
-
P2
-
None
-
1.4.1_06
-
sparc
-
solaris_9
Crash of Portal SRA 6.2 (gateway process) in garbage collector (ParallelGC) with a 2GB core on a Sol9 15k domain with 4cpu
jvm 1.4.1_06 is using the following options :
-server
-Xms1024M -Xmx2048M
-XX:NewSize=384M -XX:MaxNewSize=384M -XX:PermSize=64M -XX:MaxPermSize=64M
-XX:+UseParallelGC -XX:-UseAdaptiveSizePolicy -XX:+DisableExplicitGC
-Xss128k -XX:VMThreadStackSize=4096
-XX:+OverrideDefaultLibthread
Native stack from dbx:
---- called from signal handler with signal 10 (SIGBUS) ------
[8] libjvm.so:SymbolTable::unlink(0x3, 0x3, 0xf684da98, 0x80000, 0xff1e6354, 0x138a8), at 0xfee7af54
[9] libjvm.so:PSMarkSweep::mark_sweep_phase1(0x73bffaf4, 0x0, 0x1, 0x5fac, 0x4e50, 0x2b6a8), at 0xff0986c8
[10] libjvm.so:PSMarkSweep::invoke_at_safepoint(0xff1d41fc, 0xff1d3624, 0x6a6bee44, 0xff1d7a74, 0xff1d361c, 0x0), at 0xff097ea8
[11] libjvm.so:PSScavenge::invoke_at_safepoint(0x4c00, 0x4f7c, 0x5400, 0x5498, 0x5400, 0x5754), at 0xff09c758
[12] libjvm.so:ParallelScavengeHeap::collect_at_safepoint(0x294d0, 0x1, 0x0, 0x6a6bee44, 0x4c44, 0xfee464a8), at 0xff08b38c
[13] libjvm.so:VM_Operation::evaluate(0x6a6bee28, 0x0, 0x346184, 0xff1ea150, 0xff1e163c, 0x0), at 0xfee464a8
[14] libjvm.so:VMThread::evaluate_operation(0x4397b0, 0x6a6bee28, 0x0, 0x29700, 0xfef13f68, 0x0), at 0xfee45ef0
[15] libjvm.so:VMThread::loop(0xff1dd900, 0xff1d21b4, 0xff1d21b0, 0x0, 0x0, 0x0), at 0xfef13fd4
[16] libjvm.so:VMThread::run(0x4397b0, 0xff350a24, 0x0, 0x0, 0x0, 0x0), at 0xfef13ba4
[17] libjvm.so:_start(0x4397b0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfee7f220
Java stack of the failing thread t@6 not available in the complete stack extracted with serviceability agent script jstackproc (preloading libraries with interpose.so)
/net/lira.italy/calls/37134595_inps/crash_08_09/core.gateway1.08-09.15-27-29.jstack
http://pluto.italy/Case/INPS/37134595/crash_08_09/core.gateway1.08-09.15-27-29.jstack
There are 4 cpu so ParallelGC is currently running in 3 threads:
t@06 fails in unlink during mark-sweep
t@482 waiting to lock during collection
t@850 waiting on monitor during collection
2GB core+libs available at
/net/lira.italy/calls/37134595_inps/crash_08_09
http://pluto.italy/Case/INPS/37134595/crash_08_09
In source code (from 1.4.1_02)
http://cheesypoof.uk/lxr/source/hotspot/src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp?p=Java_1.4.1_02#L278
230 void PSMarkSweep::mark_sweep_phase1( bool& marked_for_unloading, bool clear_all_softrefs) {
231 // Recursively traverse all live objects and mark them
....
277 // Visit symbol and interned string tables and delete unmarked oops
278 SymbolTable::unlink();
279 StringTable::unlink();
280
281 assert(_marking_stack->is_empty(), "stack should be empty by now");
jvm 1.4.1_06 is using the following options :
-server
-Xms1024M -Xmx2048M
-XX:NewSize=384M -XX:MaxNewSize=384M -XX:PermSize=64M -XX:MaxPermSize=64M
-XX:+UseParallelGC -XX:-UseAdaptiveSizePolicy -XX:+DisableExplicitGC
-Xss128k -XX:VMThreadStackSize=4096
-XX:+OverrideDefaultLibthread
Native stack from dbx:
---- called from signal handler with signal 10 (SIGBUS) ------
[8] libjvm.so:SymbolTable::unlink(0x3, 0x3, 0xf684da98, 0x80000, 0xff1e6354, 0x138a8), at 0xfee7af54
[9] libjvm.so:PSMarkSweep::mark_sweep_phase1(0x73bffaf4, 0x0, 0x1, 0x5fac, 0x4e50, 0x2b6a8), at 0xff0986c8
[10] libjvm.so:PSMarkSweep::invoke_at_safepoint(0xff1d41fc, 0xff1d3624, 0x6a6bee44, 0xff1d7a74, 0xff1d361c, 0x0), at 0xff097ea8
[11] libjvm.so:PSScavenge::invoke_at_safepoint(0x4c00, 0x4f7c, 0x5400, 0x5498, 0x5400, 0x5754), at 0xff09c758
[12] libjvm.so:ParallelScavengeHeap::collect_at_safepoint(0x294d0, 0x1, 0x0, 0x6a6bee44, 0x4c44, 0xfee464a8), at 0xff08b38c
[13] libjvm.so:VM_Operation::evaluate(0x6a6bee28, 0x0, 0x346184, 0xff1ea150, 0xff1e163c, 0x0), at 0xfee464a8
[14] libjvm.so:VMThread::evaluate_operation(0x4397b0, 0x6a6bee28, 0x0, 0x29700, 0xfef13f68, 0x0), at 0xfee45ef0
[15] libjvm.so:VMThread::loop(0xff1dd900, 0xff1d21b4, 0xff1d21b0, 0x0, 0x0, 0x0), at 0xfef13fd4
[16] libjvm.so:VMThread::run(0x4397b0, 0xff350a24, 0x0, 0x0, 0x0, 0x0), at 0xfef13ba4
[17] libjvm.so:_start(0x4397b0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfee7f220
Java stack of the failing thread t@6 not available in the complete stack extracted with serviceability agent script jstackproc (preloading libraries with interpose.so)
/net/lira.italy/calls/37134595_inps/crash_08_09/core.gateway1.08-09.15-27-29.jstack
http://pluto.italy/Case/INPS/37134595/crash_08_09/core.gateway1.08-09.15-27-29.jstack
There are 4 cpu so ParallelGC is currently running in 3 threads:
t@06 fails in unlink during mark-sweep
t@482 waiting to lock during collection
t@850 waiting on monitor during collection
2GB core+libs available at
/net/lira.italy/calls/37134595_inps/crash_08_09
http://pluto.italy/Case/INPS/37134595/crash_08_09
In source code (from 1.4.1_02)
http://cheesypoof.uk/lxr/source/hotspot/src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp?p=Java_1.4.1_02#L278
230 void PSMarkSweep::mark_sweep_phase1( bool& marked_for_unloading, bool clear_all_softrefs) {
231 // Recursively traverse all live objects and mark them
....
277 // Visit symbol and interned string tables and delete unmarked oops
278 SymbolTable::unlink();
279 StringTable::unlink();
280
281 assert(_marking_stack->is_empty(), "stack should be empty by now");
- relates to
-
JDK-4871334 JVM crashes at MarkSweep
- Closed
-
JDK-5094237 JVM Crash in MarkSweep::follow_stack()
- Closed