[Mono-list] Hang on Environment.Exit if there is any socket_io

[David Evans]

I don't believe so but not 100% sure. In each case all threads in the app have been suspended in mono_thread_execute_interruption and are in nonsleep except for one thread, for example this one. This example is with mono 2.6.4 but the case with file IO with mono 2.10.6 was similar, one thread in lock_wait and all the rest already suspended:

Thread 9 (Thread 0x4b957950 (LWP 21759)):
#0  0x00007f615c59b174 in __lll_lock_wait () from /lib/libpthread.so.0
#1  0x00007f615c596b23 in _L_lock_261 () from /lib/libpthread.so.0
#2  0x00007f615c5964e8 in pthread_mutex_lock () from /lib/libpthread.so.0
#3  0x0000000000554d3b in socket_io_init (data=<optimized out>) at threadpool.c:771
#4  socket_io_add (state=<optimized out>, ares=<optimized out>) at threadpool.c:941
#5  mono_thread_pool_add (target=0x7f60fc931680, msg=0x7f610f8ac300, async_callback=<optimized out>, state=0x7f611a447840) at threadpool.c:1144
#6  0x00000000004fd4db in mono_delegate_begin_invoke (delegate=0x7f60fc931680, params=0x4b9564b0) at marshal.c:2072
#7  0x0000000040543b90 in ?? ()
#8  0x0000000003dedd71 in ?? ()

Meanwhile the thread that started the Exit is waiting like this:

Thread 126 (Thread 0x4e89b950 (LWP 15742)):
#0  0x00007f615c598e1d in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
#1  0x000000000059202f in _wapi_handle_timedwait_signal_handle (handle=0x352f, timeout=0x4e89a920, alertable=0, poll=0) at handles.c:1609
#2  0x000000000059905c in WaitForSingleObjectEx (handle=0x352f, timeout=100, alertable=0) at wait.c:207
#3  0x000000000059983e in WaitForMultipleObjectsEx (numobjects=1, handles=0x7f6131bab8e0, waitall=1, timeout=100, alertable=0) at wait.c:581
#4  0x000000000051881c in mono_thread_suspend_all_other_threads () at threads.c:3229
#5  0x0000000000550347 in ves_icall_System_Environment_Exit (result=0) at icall.c:6443
#6  0x000000004027ceca in ?? ()
#7  0x00000000009f2350 in ?? ()
#8  0x0000000000000000 in ?? ()

From: Gregory Junker [mailto:gjunker at dayark.com]
Sent: Friday, February 03, 2012 12:49 PM
To: David Evans; mono-list at lists.ximian.com
Subject: RE: [Mono-list] Hang on Environment.Exit if there is any socket_io

Is it a hang (with 100% HW thread usage) in pthread_kill()?

I get this on app exit only (so far) with a particular version of glibc (which provides pthreads), specifically the version that comes with RHEL6/CentOS6. My call stack however is through the GC, not through sockets, but it would be interesting to know if the execution environments are similar. I get this with 2.10.2 and 2.10.5, and plan to look deeper into the causes here shortly.

Greg

From: mono-list-bounces at lists.ximian.com [mailto:mono-list-bounces at lists.ximian.com] On Behalf Of David Evans
Sent: Friday, February 03, 2012 12:40 PM
To: mono-list at lists.ximian.com
Subject: [Mono-list] Hang on Environment.Exit if there is any socket_io

Hi All,

We're seeing a rare problem but frequent enough to be an issue for us, where during an Environment.Exit() call to quit our application we hang and generally there is one thread locked waiting for socket IO and we're hung waiting for all threads to stop. In one case it was our logger thread trying to write out logs so as a workaround we made sure to flush and close that file before we exit. But sometimes it is from some remoting services that the app provides that has open TCP connections, so next we'll start shutting those down explicitly before we Exit(). So there is some kind of deadlock that can occur it looks like when we Exit() with any pending IO.

Our app runs on linux. This occurs with both 2.6.4 and 2.10.6 (and we'll start testing with 2.10.8 soon)

Anyone seen this before and have an easier workaround? Bug already filed that you know of? I searched bugzilla on xamarin and didn't see anything, if no one responds as a known issue I'll file a bug.

Thanks much,
David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ximian.com/pipermail/mono-list/attachments/20120203/0f7708d4/attachment-0001.html>