harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Artem Aliev" <artem.al...@gmail.com>
Subject Re: [DRLVM] Thread Manager jvmti related issues fixes (was: Re: [jira] Commented: (HARMONY-1421))
Date Wed, 20 Sep 2006 16:34:02 GMT
Ivan,

We do a lot for this cyclic suspend problem,
I hope we does it right. I think the problem is in typo that was done
in last patch.
Fix attached. Could you please verify it.
I will also attach it to the HARMONY-1421

------------------------------------
we already try to has global lock for suspend_other().
Here is a deadlock scenario:

thread1:                                                                thread2

assert(hythread_is_suspend_enabled());
global_lock();
supend(thread2);
global_unlock();
...

assert(hythread_is_suspend_enabled());
                                                              global_lock();
                                                              supend(thread1);
                                                              global_unlock();
                                                            ....
safe_point() // stop here                        safe_point() // stop
here
------------------------------------------------------------

Thanks
Artem



On 9/20/06, Ivan Volosyuk <ivan.volosyuk@gmail.com> wrote:
> I have found one fundamental design flow in implementation of:
>   hythread_suspend_other()
>   hythread_suspend_all()
>
> The functions should be called only from suspend enabled state,
> because the should be itself a valid point of suspension to prevent
> deadlocks. The other problem is: hythread_suspend_other() should also
> utilize  hythread_global_lock() as the hythread_suspend_all() do via
> hythread_iterator_create(), otherwise this two functions can deadlock
> either.
>
> I have made a patch, but the assertion for suspend_disable_count fails
> almost in every test. I'm continue hunting the bug.
>
> --
> Ivan
>
> On 9/20/06, Ivan Volosyuk <ivan.volosyuk@gmail.com> wrote:
> > 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 <ivan.volosyuk@gmail.com> 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
> Intel Middleware Products Division
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>


Mime
View raw message