You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Mark Hindess <ma...@googlemail.com> on 2007/10/30 15:20:04 UTC
Re: [porting] FreeBSD
On 29 October 2007 at 4:43, "Ilya Berezhniuk" <il...@gmail.com>
wrote:
>
> I think this infinite loop appears because the crash handler needs
> some adjustment to work on FreeBSD. It occasionally goes into infinite
> loop even on Linux.
>
> To avoid this and simply crash with a core dump, you can comment out
> the call to st_print_stack in null_java_reference_handler
> (signals_ia32.cpp).
It doesn't actually get that far. If I comment out the contents of
the initialize_signals function then I can get a core dump for the
first SEGV - details appended below.
> But probably the best way is using '-XX:vm.crash_handler=true' option.
> VM will start GDB automatically for unprocessed signals. I see you
> have corrected related code in crash_handler.cpp, so this option
> should work.
That would be great but it's received another SIGSEGV before it gets to GDB.
I've a couple of ideas to explore - one is removing the -lrt from the
linking since I don't think this is valid on FreeBSD. The more drastic
thing would be to try running with libc_r instead of libpthread.
Regards,
-Mark.
#0 0x28108537 in pthread_testcancel () from /lib/libpthread.so.2
[New Thread 0x8057600 (runnable)]
[New Thread 0x8057400 (LWP 100079)]
[New Thread 0x8057000 (runnable)]
[New LWP 100109]
(gdb) info threads
* 4 LWP 100109 0x28108537 in pthread_testcancel () from /lib/libpthread.so.2
3 Thread 0x8057000 (runnable) 0x2858e2a8 in ?? ()
2 Thread 0x8057400 (LWP 100079) 0x281084f7 in pthread_testcancel ()
from /lib/libpthread.so.2
1 Thread 0x8057600 (runnable) 0x28100f9b in pthread_mutexattr_init ()
from /lib/libpthread.so.2
(gdb) where
#0 0x281084f7 in pthread_testcancel () from /lib/libpthread.so.2
#1 0x28100ec8 in pthread_mutexattr_init () from /lib/libpthread.so.2
#2 0x2807d450 in ?? ()
(gdb) thread 3
[Switching to thread 3 (Thread 0x8057000 (runnable))]#0 0x2858e2a8 in ?? ()
(gdb) where
#0 0x2858e2a8 in ?? ()
#1 0x281e22f2 in __cxa_finalize () from /lib/libc.so.6
#2 0x281e1f66 in exit () from /lib/libc.so.6
#3 0x080488bf in _start ()
#4 0x00000005 in ?? ()
(gdb) thread 2
[Switching to thread 2 (Thread 0x8057400 (LWP 100079))]#0 0x281084f7 in pthread_testcancel () from /lib/libpthread.so.2
(gdb) iwhere
Undefined command: "iwhere". Try "help".
(gdb) where
#0 0x281084f7 in pthread_testcancel () from /lib/libpthread.so.2
#1 0x28100ec8 in pthread_mutexattr_init () from /lib/libpthread.so.2
#2 0x2807d450 in ?? ()
(gdb) thread 1
[Switching to thread 1 (Thread 0x8057600 (runnable))]#0 0x28100f9b in pthread_mutexattr_init () from /lib/libpthread.so.2
(gdb) where
#0 0x28100f9b in pthread_mutexattr_init () from /lib/libpthread.so.2
#1 0x2810112f in pthread_mutexattr_init () from /lib/libpthread.so.2
#2 0x280ff0a4 in pthread_mutex_lock () from /lib/libpthread.so.2
#3 0x280857dd in hymutex_unlock (mutex=0x8074300)
at working_vm/vm/thread/src/linux/os_mutex.c:94
#4 0x28087ea3 in hythread_monitor_exit (mon_ptr=0x8074300)
at working_vm/vm/thread/src/thread_native_fat_monitor.c:152
#5 0x280876f7 in hythread_exit (monitor=0x8074300)
at working_vm/vm/thread/src/thread_native_basic.c:755
#6 0x280e4630 in asynchSignalReporter (userData=0x0) at hysignal.c:539
#7 0x280875f7 in hythread_wrapper_start_proc (arg=0x8050530)
at working_vm/vm/thread/src/thread_native_basic.c:725
#8 0x280f93a5 in pthread_create () from /lib/libpthread.so.2
#9 0x281cc137 in _ctx_start () from /lib/libc.so.6
> 2007/10/29, Mark Hindess <ma...@googlemail.com>:
> >
> > There are quite a few hacks the last of which is in r589418, but on
> > FreeBSD 6.2 I can now compile a minimal amount of drlvm with:
> >
> > sh build.sh \
> > -DCOMPONENTS="vm.interpreter vm.vmcore vm.em vm.gc_gen vm.vmi vm.hythr vm
> .kernel_classes" \
> > -Dhy.local.zlib=true -Dhy.no.sig=true -Dhy.no.thr=false
> >
> > and then run with:
> >
> > LD_LIBRARY_PATH=freebsd_ia32_gcc_debug/deploy/jdk/jre/bin/default:freebsd_i
> a32_gcc_debug/deploy/jdk/jre/bin ./freebsd_ia32_gcc_debug/deploy/jdk/jre/bin/
> java \
> > -Xint HelloWorld
> >
> > The good news is that it does get far enough to print "Hello World".
> > The bad news is that it then goes in to an infinite loop segfaulting in
> > the signal handler. (The initial SIGSEGV seems to be a problem with
> > recursive mutexes.)
> >
> > Regards,
> > Mark
> >
> >
> >
>
>
> --
>
> Ilya
>
Re: [porting] FreeBSD
Posted by Gregory Shimansky <gs...@apache.org>.
Mark Hindess wrote:
> On 29 October 2007 at 4:43, "Ilya Berezhniuk" <il...@gmail.com>
> wrote:
>> I think this infinite loop appears because the crash handler needs
>> some adjustment to work on FreeBSD. It occasionally goes into infinite
>> loop even on Linux.
>>
>> To avoid this and simply crash with a core dump, you can comment out
>> the call to st_print_stack in null_java_reference_handler
>> (signals_ia32.cpp).
>
> It doesn't actually get that far. If I comment out the contents of
> the initialize_signals function then I can get a core dump for the
> first SEGV - details appended below.
>
>> But probably the best way is using '-XX:vm.crash_handler=true' option.
>> VM will start GDB automatically for unprocessed signals. I see you
>> have corrected related code in crash_handler.cpp, so this option
>> should work.
>
> That would be great but it's received another SIGSEGV before it gets to GDB.
>
> I've a couple of ideas to explore - one is removing the -lrt from the
> linking since I don't think this is valid on FreeBSD. The more drastic
> thing would be to try running with libc_r instead of libpthread.
I've seen something similar on shutdown while investigating bug
HARMONY-5015. The crash happened when one thread (1) killed another (2)
with pthread_cancel. The thread (2) would receive SIGCANCEL (it goes
between SIG63 and SIG32 in gdb's "info handle" table on Linux). The
handler for SIGCANCEL in pthread tried to unwind the stack, probably to
pthread_cond_timedwait or another pthread function that gets canceled,
but stack unwinding code on x86_64 use C++ stack unwinding algorithm. It
tried to find handlers for C++ exceptions in TLS, and there actually
were some because the thread (2) was one of the JPDA agent's threads
(agent uses C++ exceptions). The bad thing is that by that time agent's
library was unloaded from address space of the process, so stack
unwinding code crashed accessing unmapped memory for JPDA agent library.
GDB by default doesn't let you intercept SIGCANCEL signal and you need
to type "handle SIGCANCEL stop print" to see that program has received it.
All the above is very specific to Linux, and pthreads on BSD may not use
signals at all. In any case I think it is necessary to run program under
GDB initially to catch SIGSEGV and try to understand why does pthread
code crash.
> #0 0x28108537 in pthread_testcancel () from /lib/libpthread.so.2
> [New Thread 0x8057600 (runnable)]
> [New Thread 0x8057400 (LWP 100079)]
> [New Thread 0x8057000 (runnable)]
> [New LWP 100109]
> (gdb) info threads
> * 4 LWP 100109 0x28108537 in pthread_testcancel () from /lib/libpthread.so.2
> 3 Thread 0x8057000 (runnable) 0x2858e2a8 in ?? ()
> 2 Thread 0x8057400 (LWP 100079) 0x281084f7 in pthread_testcancel ()
> from /lib/libpthread.so.2
> 1 Thread 0x8057600 (runnable) 0x28100f9b in pthread_mutexattr_init ()
> from /lib/libpthread.so.2
> (gdb) where
> #0 0x281084f7 in pthread_testcancel () from /lib/libpthread.so.2
> #1 0x28100ec8 in pthread_mutexattr_init () from /lib/libpthread.so.2
> #2 0x2807d450 in ?? ()
> (gdb) thread 3
> [Switching to thread 3 (Thread 0x8057000 (runnable))]#0 0x2858e2a8 in ?? ()
> (gdb) where
> #0 0x2858e2a8 in ?? ()
> #1 0x281e22f2 in __cxa_finalize () from /lib/libc.so.6
> #2 0x281e1f66 in exit () from /lib/libc.so.6
> #3 0x080488bf in _start ()
> #4 0x00000005 in ?? ()
> (gdb) thread 2
> [Switching to thread 2 (Thread 0x8057400 (LWP 100079))]#0 0x281084f7 in pthread_testcancel () from /lib/libpthread.so.2
> (gdb) iwhere
> Undefined command: "iwhere". Try "help".
> (gdb) where
> #0 0x281084f7 in pthread_testcancel () from /lib/libpthread.so.2
> #1 0x28100ec8 in pthread_mutexattr_init () from /lib/libpthread.so.2
> #2 0x2807d450 in ?? ()
> (gdb) thread 1
> [Switching to thread 1 (Thread 0x8057600 (runnable))]#0 0x28100f9b in pthread_mutexattr_init () from /lib/libpthread.so.2
> (gdb) where
> #0 0x28100f9b in pthread_mutexattr_init () from /lib/libpthread.so.2
> #1 0x2810112f in pthread_mutexattr_init () from /lib/libpthread.so.2
> #2 0x280ff0a4 in pthread_mutex_lock () from /lib/libpthread.so.2
> #3 0x280857dd in hymutex_unlock (mutex=0x8074300)
> at working_vm/vm/thread/src/linux/os_mutex.c:94
> #4 0x28087ea3 in hythread_monitor_exit (mon_ptr=0x8074300)
> at working_vm/vm/thread/src/thread_native_fat_monitor.c:152
> #5 0x280876f7 in hythread_exit (monitor=0x8074300)
> at working_vm/vm/thread/src/thread_native_basic.c:755
> #6 0x280e4630 in asynchSignalReporter (userData=0x0) at hysignal.c:539
> #7 0x280875f7 in hythread_wrapper_start_proc (arg=0x8050530)
> at working_vm/vm/thread/src/thread_native_basic.c:725
> #8 0x280f93a5 in pthread_create () from /lib/libpthread.so.2
> #9 0x281cc137 in _ctx_start () from /lib/libc.so.6
>
>> 2007/10/29, Mark Hindess <ma...@googlemail.com>:
>>> There are quite a few hacks the last of which is in r589418, but on
>>> FreeBSD 6.2 I can now compile a minimal amount of drlvm with:
>>>
>>> sh build.sh \
>>> -DCOMPONENTS="vm.interpreter vm.vmcore vm.em vm.gc_gen vm.vmi vm.hythr vm
>> .kernel_classes" \
>>> -Dhy.local.zlib=true -Dhy.no.sig=true -Dhy.no.thr=false
>>>
>>> and then run with:
>>>
>>> LD_LIBRARY_PATH=freebsd_ia32_gcc_debug/deploy/jdk/jre/bin/default:freebsd_i
>> a32_gcc_debug/deploy/jdk/jre/bin ./freebsd_ia32_gcc_debug/deploy/jdk/jre/bin/
>> java \
>>> -Xint HelloWorld
>>>
>>> The good news is that it does get far enough to print "Hello World".
>>> The bad news is that it then goes in to an infinite loop segfaulting in
>>> the signal handler. (The initial SIGSEGV seems to be a problem with
>>> recursive mutexes.)
>>>
>>> Regards,
>>> Mark
>>>
>>>
>>>
>>
>> --
>>
>> Ilya
>>
>
>
>
--
Gregory