Artem, it looks like two thread mutually suspended each other.
This is only reproducible when jvmti.patch from the JIRA is applied.
--
Ivan
On 9/20/06, Ivan Volosyuk <[EMAIL PROTECTED]> wrote:
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
>
--
Ivan
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]
