So it looks like something is causing the iteration over the oops in an interpreter frame on a Java thread stack to fail, and this happens prior to a GC (so GC is likely not screwing up here, but rather perhaps the interpreter).
With those very general remarks, it's over to the MLVM cognoscenti :-) -- ramki Charles Oliver Nutter wrote: ... > (gdb) thread 3 > [Switching to thread 3 (process 43094 thread 0x2103)] > 0x96efc796 in __wait4 () > (gdb) bt > #0 0x96efc796 in __wait4 () > #1 0x96efc787 in waitpid$UNIX2003 () > #2 0x0136a856 in os::fork_and_exec () > #3 0x0145eae4 in VMError::show_message_box () > #4 0x0145e87d in VMError::report_and_die () > #5 0x01370b5e in JVM_handle_bsd_signal () > #6 0x0136a031 in signalHandler () > #7 <signal handler called> > #8 0x011a43aa in frame::oops_interpreted_do () > #9 0x011a4aa6 in frame::oops_do_internal () > #10 0x0141f175 in JavaThread::oops_do () > #11 0x0141f5ff in Threads::verify () > #12 0x0142db1c in Universe::verify () > #13 0x011d1506 in GenCollectedHeap::do_collection () > #14 0x0113e5e3 in GenCollectorPolicy::satisfy_failed_allocation () > #15 0x011cecc5 in GenCollectedHeap::satisfy_failed_allocation () > #16 0x0145f23b in VM_GenCollectForAllocation::doit () > #17 0x01464125 in VM_Operation::evaluate () > #18 0x014627fd in VMThread::evaluate_operation () > #19 0x0146346c in VMThread::loop () > #20 0x0146375c in VMThread::run () > #21 0x0136dab5 in java_start () > #22 0x96ee9095 in _pthread_start () > #23 0x96ee8f52 in thread_start () > _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
