Gregory Shimansky wrote:
Evgueni Brevnov wrote:
hmmm.... strange. The patch was tested on multi-processor system
running SUSE9. I will check if the patch misses something. Anyway, we
need to wait with the patch submission until we 100% sure how
hythread_monitor_init should behave.
Thanks
Evgueni
On 11/11/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
On Friday 10 November 2006 17:45 Evgueni Brevnov wrote:
> Hi,
>
> While investigating deadlock scenario which is described in
> HARMONY-2006 I found out one interesting thing. It turned out that DRL
> implementation of hythread_monitor_init /
> hythread_monitor_init_with_name initializes and acquires a monitor.
> Original spec reads: "Acquire and initialize a new monitor from the
> threading library...." AFAIU that doesn't mean to lock the monitor but
> get it from the threading library. So the hythread_monitor_init should
> not lock the monitor.
>
> Could somebody comment on that?
It might be that semantic is different on different platforms which is
probably even worse. Your patch in HARMONY-2149 breaks nearly all of
acceptance tests on Linux while everything on Windows works (ok I
tested on
laptop with 1 processor while Linux was a HT server, sometimes it is
important for threading).
I've tried to investigate the problem but didn't find the end of it yet.
The bug seems to be ubuntu specific (<joke>shall we maybe call this
distribution buggy and move on?</joke>).
There is something odd about it, I'll admit... Remember the EOMEM bugs
I found in forking?
I didn't reproduce it on
gentoo, all tests work just fine.
The bug look likes this, on tests gc.Force, gc.LOS, gc.List, gc.NPE,
gc.PhantomReferenceTest, gc.WeakReferenceTest, stress.WeakHashMapTest VM
segfaults. The stack looks like an infinite recursion of 4 stack frames:
#0 0xb6dcb814 in null_java_reference_handler (signum=11,
info=0xb71a503c, context=0xb71a50bc) at
/nfs/ims/proj/drl/mrt1/users/gregory/Harmony/enhanced/drlvm/trunk/vm/vmco
re/src/util/linux/signals_ia32.cpp:443
#1 <signal handler called>
#2 0xb6dcc20a in get_stack_addr () at
/nfs/ims/proj/drl/mrt1/users/gregory/Harmony/enhanced/drlvm/trunk/vm/vmco
re/src/util/linux/signals_ia32.cpp:293
#3 0xb6dcb6cd in check_stack_overflow (info=0xb71a546c, uc=0xb71a54ec)
at
/nfs/ims/proj/drl/mrt1/users/gregory/Harmony/enhanced/drlvm/trunk/vm/vmco
re/src/util/linux/signals_ia32.cpp:399
#4 0xb6dcb900 in null_java_reference_handler (signum=11,
info=0xb71a546c, context=0xb71a54ec) at
/nfs/ims/proj/drl/mrt1/users/gregory/Harmony/enhanced/drlvm/trunk/vm/vmco
re/src/util/linux/signals_ia32.cpp:451
and so on. The stack is very long. When I run VM with -Xtrace:signals I
get a very long log of messages that "NPE or SOE detected at ...". The
first time address always varies, but it appears to be memcpy. The next
addresses are always the same, they point to get_stack_addr function.
So I tried to find out why memcpy crashes in the first place. It appears
to be a struct copy called from jsig_handler hysig. The stack looks like
this (if I can trust gdb on ubuntu):
#0 0xb7a9b9dc in memcpy () from /lib/tls/i686/cmov/libc.so.6
#1 0xb7ba0fa0 in jsig_handler (sig=-1215196204, siginfo=0x0, uc=0x0)
at hysigunix.c:169
#2 0xb7f9ec8b in asynchSignalReporter (userData=0x0) at hysignal.c:971
#3 0xb7baa8ef in thread_start_proc (thd=0x807a8e8, p_args=0x807a8d8)
at
/nfs/ims/proj/drl/mrt1/users/gregory/Harmony/enhanced/drlvm/trunk/vm/thread/src/thread_native_basic.c:712
#4 0xb7bb0ed4 in dummy_worker (opaque=0x0) at threadproc/unix/thread.c:138
#5 0xb7b65341 in start_thread () from lib/tls/i686/cmov/libpthread.so.0
#6 0xb7af94ee in clone () from /lib/tls/i686/cmov/libc.so.6
In jsig_handler a struct of type sigaction is copied
act = saved_sigaction[sig];
and gcc replaces this statement with a call to memcpy it seems. But the
parameter sig is quite weird if you look at it. It is sig=-1215196204...
Now if I could only find where and this sig happened there... I cannot
find it in the depth of classlib native code this late at night.
