Customer has a primary process that is crashing on a load test bed while generating a heap dump.
They are registering a listener with MemoryMXBean for Collection Usage Threshold notification, and upon receiving an event they are generating heap dump using HotspotDiagnosticMXBean and setting the threshold to a higher level for later notification. It was running fine in their earlier load test runs where the JRE was 1.6.0_10 (it is now JRE1.6.0_13). Following is the stack trace obtained from the core dump.
#0 0x006b97a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1 0x00138825 in raise () from /lib/tls/libc.so.6
#2 0x0013a289 in abort () from /lib/tls/libc.so.6
#3 0x06502afb in os::abort () from /usr/local/thirdparty/java/j2sdk/jre/lib/i386/server/libjvm.so
#4 0x066067d1 in VMError::report_and_die () from /usr/local/thirdparty/java/j2sdk/jre/lib/i386/server/libjvm.so
#5 0x06507d99 in JVM_handle_linux_signal () from /usr/local/thirdparty/java/j2sdk/jre/lib/i386/server/libjvm.so
#6 0x065048c8 in signalHandler () from /usr/local/thirdparty/java/j2sdk/jre/lib/i386/server/libjvm.so
#7 <signal handler called>
#8 0x0634b2d0 in HeapObjectDumper::do_object () from /usr/local/thirdparty/java/j2sdk/jre/lib/i386/server/libjvm.so
#9 0x064ecf0b in MutableSpace::object_iterate () from /usr/local/thirdparty/java/j2sdk/jre/lib/i386/server/libjvm.so
#10 0x0654b227 in PSYoungGen::object_iterate () from /usr/local/thirdparty/java/j2sdk/jre/lib/i386/server/libjvm.so
#11 0x06515ac6 in ParallelScavengeHeap::object_iterate () from /usr/local/thirdparty/java/j2sdk/jre/lib/i386/server/libjvm.so
#12 0x0634bdc9 in VM_HeapDumper::doit () from /usr/local/thirdparty/java/j2sdk/jre/lib/i386/server/libjvm.so
#13 0x06614907 in VM_Operation::evaluate () from /usr/local/thirdparty/java/j2sdk/jre/lib/i386/server/libjvm.so
#14 0x06613f1c in VMThread::evaluate_operation () from /usr/local/thirdparty/java/j2sdk/jre/lib/i386/server/libjvm.so
#15 0x066140f1 in VMThread::loop () from /usr/local/thirdparty/java/j2sdk/jre/lib/i386/server/libjvm.so
#16 0x06613ccf in VMThread::run () from /usr/local/thirdparty/java/j2sdk/jre/lib/i386/server/libjvm.so
#17 0x06506929 in java_start () from /usr/local/thirdparty/java/j2sdk/jre/lib/i386/server/libjvm.so
#18 0x00e113cc in start_thread () from /lib/tls/libpthread.so.0
#19 0x001dc96e in clone () from /lib/tls/libc.so.6
Just a clarification. The process is not crashing during every instance of heap dump generation. A few dumps were successfully generated by the listener that I mentioned and we were also able to generate dumps through JConsole.
They are registering a listener with MemoryMXBean for Collection Usage Threshold notification, and upon receiving an event they are generating heap dump using HotspotDiagnosticMXBean and setting the threshold to a higher level for later notification. It was running fine in their earlier load test runs where the JRE was 1.6.0_10 (it is now JRE1.6.0_13). Following is the stack trace obtained from the core dump.
#0 0x006b97a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1 0x00138825 in raise () from /lib/tls/libc.so.6
#2 0x0013a289 in abort () from /lib/tls/libc.so.6
#3 0x06502afb in os::abort () from /usr/local/thirdparty/java/j2sdk/jre/lib/i386/server/libjvm.so
#4 0x066067d1 in VMError::report_and_die () from /usr/local/thirdparty/java/j2sdk/jre/lib/i386/server/libjvm.so
#5 0x06507d99 in JVM_handle_linux_signal () from /usr/local/thirdparty/java/j2sdk/jre/lib/i386/server/libjvm.so
#6 0x065048c8 in signalHandler () from /usr/local/thirdparty/java/j2sdk/jre/lib/i386/server/libjvm.so
#7 <signal handler called>
#8 0x0634b2d0 in HeapObjectDumper::do_object () from /usr/local/thirdparty/java/j2sdk/jre/lib/i386/server/libjvm.so
#9 0x064ecf0b in MutableSpace::object_iterate () from /usr/local/thirdparty/java/j2sdk/jre/lib/i386/server/libjvm.so
#10 0x0654b227 in PSYoungGen::object_iterate () from /usr/local/thirdparty/java/j2sdk/jre/lib/i386/server/libjvm.so
#11 0x06515ac6 in ParallelScavengeHeap::object_iterate () from /usr/local/thirdparty/java/j2sdk/jre/lib/i386/server/libjvm.so
#12 0x0634bdc9 in VM_HeapDumper::doit () from /usr/local/thirdparty/java/j2sdk/jre/lib/i386/server/libjvm.so
#13 0x06614907 in VM_Operation::evaluate () from /usr/local/thirdparty/java/j2sdk/jre/lib/i386/server/libjvm.so
#14 0x06613f1c in VMThread::evaluate_operation () from /usr/local/thirdparty/java/j2sdk/jre/lib/i386/server/libjvm.so
#15 0x066140f1 in VMThread::loop () from /usr/local/thirdparty/java/j2sdk/jre/lib/i386/server/libjvm.so
#16 0x06613ccf in VMThread::run () from /usr/local/thirdparty/java/j2sdk/jre/lib/i386/server/libjvm.so
#17 0x06506929 in java_start () from /usr/local/thirdparty/java/j2sdk/jre/lib/i386/server/libjvm.so
#18 0x00e113cc in start_thread () from /lib/tls/libpthread.so.0
#19 0x001dc96e in clone () from /lib/tls/libc.so.6
Just a clarification. The process is not crashing during every instance of heap dump generation. A few dumps were successfully generated by the listener that I mentioned and we were also able to generate dumps through JConsole.
- duplicates
-
JDK-6897143 Stress test crashes during HeapInspection using ParallelGC.
-
- Resolved
-