I have reproduced the problem with the stack trace same as reported by Gregory. Here is the stack trace of thread starting GC:
#4 0xb7af84bc in sched_yield () from /lib/libc.so.6 #5 0xb7bd5efd in hythread_yield () at /home/ivan/svn/drlvm/trunk/vm/thread/src/thread_native_basic.c:296 #6 0xb7bd8360 in wait_safe_region_event (thread=0x863e470) at /home/ivan/svn/drlvm/trunk/vm/thread/src/thread_native_suspend.c:226 #7 0xb7bd8580 in hythread_suspend_all (t=0xbfce15d4, group=0x0) at /home/ivan/svn/drlvm/trunk/vm/thread/src/thread_native_suspend.c:401 #8 0xb6eb2872 in stop_the_world_root_set_enumeration () at /home/ivan/svn/drlvm/trunk/vm/vmcore/src/gc/stop_the_world_root_set_enum.cpp:89 #9 0xb6eb2b89 in vm_enumerate_root_set_all_threads () at /home/ivan/svn/drlvm/trunk/vm/vmcore/src/gc/stop_the_world_root_set_enum.cpp:141 #10 0xb6c845aa in enumerate_universe () at /home/ivan/svn/drlvm/trunk/vm/gc/src/collect.cpp:127 #11 0xb6c8584a in force_gc () at /home/ivan/svn/drlvm/trunk/vm/gc/src/collect.cpp:363 #12 0xb6c9503b in select_force_gc () at /home/ivan/svn/drlvm/trunk/vm/gc/src/selector.cpp:287 #13 0xb6c9007e in gc_force_gc () at /home/ivan/svn/drlvm/trunk/vm/gc/src/gc_for_vm.cpp:336 #14 0xb6e289e1 in Java_java_lang_VMMemoryManager_runGC () Two other threads: #3 0xb7be9704 in tm_tls_size () from /home/ivan/svn/drlvm/trunk/build/lnx_ia32_gcc_debug/deploy/jre/bin/default/libhythr.so #4 0xb7af84bc in sched_yield () from /lib/libc.so.6 #5 0xb7bd5efd in hythread_yield () at /home/ivan/svn/drlvm/trunk/vm/thread/src/thread_native_basic.c:296 #6 0xb7bd8360 in wait_safe_region_event (thread=0x805ce50) at /home/ivan/svn/drlvm/trunk/vm/thread/src/thread_native_suspend.c:226 #7 0xb7bd83e0 in hythread_suspend_other (thread=0x805ce50) at /home/ivan/svn/drlvm/trunk/vm/thread/src/thread_native_suspend.c:286 #8 0xb7bd8b22 in unreserve_lock (lockword_ptr=0xa65da07c) at /home/ivan/svn/drlvm/trunk/vm/thread/src/thread_native_thin_monitor.c:168 #9 0xb7bd8ece in hythread_thin_monitor_try_enter (lockword_ptr=0xa65da07c) at /home/ivan/svn/drlvm/trunk/vm/thread/src/thread_native_thin_monitor.c:313 #4 0xb7b792be in __lll_mutex_lock_wait () from /lib/libpthread.so.0 #5 0xb7b76074 in _L_mutex_lock_150 () from /lib/libpthread.so.0 #6 0xb7fdb290 in fixup () from /lib/ld-linux.so.2 #7 0xb7bd79e4 in hymutex_lock (mutex=0x805d150) at /home/ivan/svn/drlvm/trunk/vm/thread/src/thread_native_mutex.c:71 #8 0xb7bd6d29 in hythread_monitor_enter (mon_ptr=0x805d118) at /home/ivan/svn/drlvm/trunk/vm/thread/src/thread_native_fat_monitor.c:95 #9 0xb7fc2fef in asynchSignalReporter () from /home/ivan/svn/drlvm/trunk/build/lnx_ia32_gcc_debug/deploy/jre/bin/libhyprt.so #10 0xb7bd67ca in thread_start_proc (thd=0x805f380, p_args=0x805f2e8) at /home/ivan/svn/drlvm/trunk/vm/thread/src/thread_native_basic.c:704 #11 0xb7bdd386 in dummy_worker (opaque=0xfffffffc) at thread.c:138 #12 0xb7b74420 in start_thread () from /lib/libpthread.so.0 #13 0xb7b0e39e in clone () from /lib/libc.so.6 -- Ivan On 9/19/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
On Monday 18 September 2006 08:27 Geir Magnusson Jr (JIRA) wrote: > [ > http://issues.apache.org/jira/browse/HARMONY-1421?page=comments#action_1243 >5388 ] > > Geir Magnusson Jr commented on HARMONY-1421: > -------------------------------------------- > > tested again after all the other JIRAs in place, still - just hangs on the > finalizer test on Ubuntu 6. Will try on other platform, but please > investigate and comment. I have a hanging smoke test too. But it is not gc.Finalizer, this test is the last which passes. It is gc.Force which hangs. I am using Gentoo x86 which is mostly up to date with the current (see [1] for exact package versions if you care, package column x86, ~ means unstable, so I don't have it installed). It is pretty strange bug. I can attach to the hanging process and look up the stack trace in gdb [2]. The process keeps on using CPU. But when I try to run it from the command line I get a crash which looks like [3] (useless I know). Probably someone knows what this is about. When trying to debug this crash with gdb I get gdb generic-error and the only thing I can do is kill it with -9... weird. Also I had to define LD_LIBRARY_PATH as usual to make java to run. Where is the magical Harmony launcher which sets LD_LIBRARY_PATH and reexecs the process inside of it? I've probably missed the thread on the mail list on how to build drlvm these days. [1] http://packages.gentoo.org [2] (gdb) bt #0 0xffffe410 in ?? () #1 0xbf862f48 in ?? () #2 0xfffffffc in ?? () #3 0xbf862f7c in ?? () #4 0xb7a3b1dc in sched_yield () from /lib/libc.so.6 #5 0xb7b0ef1d in hythread_yield () at /home/gregory/work/Harmony/harmony/enhanced/drlvm/trunk/vm/thread/src/thread_native_basic.c:296 #6 0xb7b113a8 in wait_safe_region_event (thread=0x863ee68) at /home/gregory/work/Harmony/harmony/enhanced/drlvm/trunk/vm/thread/src/thread_native_suspend.c:226 #7 0xb7b115c8 in hythread_suspend_all (t=0xbf862fbc, group=0x0) at /home/gregory/work/Harmony/harmony/enhanced/drlvm/trunk/vm/thread/src/thread_native_suspend.c:401 #8 0xb6dc985a in stop_the_world_root_set_enumeration () at /home/gregory/work/Harmony/harmony/enhanced/drlvm/trunk/vm/vmcore/src/gc/stop_the_world_root_set_enum.cpp:89 #9 0xb6dc9b71 in vm_enumerate_root_set_all_threads () at /home/gregory/work/Harmony/harmony/enhanced/drlvm/trunk/vm/vmcore/src/gc/stop_the_world_root_set_enum.cpp:141 #10 0xb63335aa in enumerate_universe () at /home/gregory/work/Harmony/harmony/enhanced/drlvm/trunk/vm/gc/src/collect.cpp:127 #11 0xb633484a in force_gc () at /home/gregory/work/Harmony/harmony/enhanced/drlvm/trunk/vm/gc/src/collect.cpp:363 #12 0xb6344025 in select_force_gc () at /home/gregory/work/Harmony/harmony/enhanced/drlvm/trunk/vm/gc/src/selector.cpp:287 #13 0xb633f07e in gc_force_gc () at /home/gregory/work/Harmony/harmony/enhanced/drlvm/trunk/vm/gc/src/gc_for_vm.cpp:336 #14 0xb6d3f9e1 in Java_java_lang_VMMemoryManager_runGC () at /home/gregory/work/Harmony/harmony/enhanced/drlvm/trunk/vm/vmcore/src/kernel_classes/native/java_lang_VMMemoryManager.cpp:137 #15 0xb680eec0 in ?? () #16 0xb6faee48 in java_vm () from /home/gregory/work/Harmony/harmony/enhanced/drlvm/trunk/build/lnx_ia32_gcc_debug/deploy/jre/bin/default/libharmonyvm.so #17 0xbf8630f0 in ?? () #18 0x00010009 in ?? () #19 0x00000000 in ?? () [3] Stack trace: 1: free (??:-1) 2: ?? (??:-1) addr2line: '[stack]': No such file 3: ?? (ree:-1) 4: ?? (??:-1) addr2line: '[stack]': No such file 5: ?? (ree:-1) addr2line: '[stack]': No such file 6: ?? (ree:-1) addr2line: '[stack]': No such file 7: ?? (ree:-1) 8: hymem_free_memory (utf8decode.c:-1) addr2line: '[stack]': No such file 9: ?? (ymem_free_memory:-1) addr2line: '[stack]': No such file 10: ?? (ymem_free_memory:-1) 11: properties_free (s_copysign.c:-1) addr2line: '[stack]': No such file 12: ?? (roperties_free:-1) addr2line: '[stack]': No such file 13: ?? (roperties_free:-1) addr2line: '[stack]': No such file 14: ?? (roperties_free:-1) 15: ?? (??:-1) addr2line: '[stack]': No such file 16: ?? (roperties_free:-1) 17: ?? (??:-1) addr2line: '[stack]': No such file 18: ?? (roperties_free:-1) <end of stack trace> Segmentation fault -- Gregory Shimansky, Intel Middleware Products Division
--------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
