[Mono-list] All threads go into sigsuspend()

[Rodrigo Kumpera]

You might have bumped into a bug in boehm gc, could you post a full thread
dump when it hangs?


On Tue, Mar 19, 2013 at 6:34 PM, Dave Curylo <curylod at asme.org> wrote:

> I'm running mono 2.10.8.1 on CentOS 6.3 and running a mono-service
> application.  It seems to run fine for a while, but then after a few hours
> appears hung.  No CPU is in use, but my application doesn't respond to HTTP
> requests anymore, isn't logging anything, nothing.  I used gdb to get a
> backtrace when it's hung, and it appears that every thread is stuck in
> sigsuspend().  Most seem to be following a _GC_suspend_handler, like here
> is an example:
>
> Thread 13 (Thread 0x7f4c286a7700 (LWP 1395)):
> #0  0x00007f4c2f1abc54 in sigsuspend () from /lib64/libc.so.6
> #1  0x00000000005f2efe in _GC_suspend_handler (sig=30) at
> pthread_stop_world.c:186
> #2  0x00000000005f2f3d in GC_suspend_handler (sig=30) at
> pthread_stop_world.c:211
> #3  <signal handler called>
> #4  0x00007f4c2f5177bb in pthread_cond_timedwait@@GLIBC_2.3.2 () from
> /lib64/libpthread.so.0
> #5  0x00000000005aeeed in _wapi_handle_timedwait_signal_handle
> (handle=0x42b, timeout=0x7f4c286a6810, alertable=1, poll=<value optimized
> out>) at handles.c:1653
> #6  0x00000000005a6a11 in WaitForSingleObjectEx (handle=0x42b,
> timeout=9999, alertable=1) at wait.c:205
> #7  0x00000000005995ab in
> ves_icall_System_Threading_WaitHandle_WaitOne_internal (this=<value
> optimized out>, handle=0x42b, ms=9999, exitContext=<value optimized out>)
> at threads.c:1665
> #8  0x00000000413d31f8 in ?? ()
> #9  0x00007f4c10000c40 in ?? ()
> #10 0x00007fff1d77ba37 in clock_gettime ()
> #11 0x00000000413d2ddb in ?? ()
> #12 0x000000000000270f in ?? ()
> #13 0x000000000000270f in ?? ()
> #14 0x00000000413d1340 in ?? ()
> #15 0x00000000413d137b in ?? ()
> #16 0x0000000000000000 in ?? ()
>
> After I stop and restart the mono-service, the application responds as
> normal, and most of the threads are in pthread_cond_wait, but NONE of them
> are in sigsuspend():
>
> Thread 13 (Thread 0x7fabf2954700 (LWP 7493)):
> #0  0x00007fabf4af643c in pthread_cond_wait@@GLIBC_2.3.2 () from
> /lib64/libpthread.so.0
> #1  0x00000000005e455f in GC_wait_marker () at pthread_support.c:1863
> #2  0x00000000005d55bd in GC_help_marker (my_mark_no=105) at mark.c:1116
> #3  0x00000000005e32e0 in GC_mark_thread (id=0x3) at pthread_support.c:552
> #4  0x00007fabf4af2851 in start_thread () from /lib64/libpthread.so.0
> #5  0x00007fabf484090d in clone () from /lib64/libc.so.6
>
> Any idea why all the threads would go into sigsuspend()?  I'm not using
> sgen, by the way.  I can try if anyone expects that to be of any help.
>
> If you need a full backtrace of all the threads, let me know.
>
> Thanks for your help.
> -Dave
>
> _______________________________________________
> Mono-list maillist  -  Mono-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-list
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ximian.com/pipermail/mono-list/attachments/20130319/73d432d7/attachment.html>