[Mono-dev] Help w/ deadlock on shutdown

Fri Dec 13 21:14:33 UTC 2013

Jonathan, thanks for the info.

The native thread (#4) does not know about mono nor is it linked with the mono libraries, it would be hard to call mono_thread_detach from it. Is there a different solution to this?

Out of curiosity why does mono not detach a thread once a managed call is complete from a native thread.

On Dec 13, 2013, at 12:55 PM, Jonathan Chambers <joncham at gmail.com<mailto:joncham at gmail.com>> wrote:

If the native thread calls into managed code it is automatically 'attached' to the mono runtime and the gc for tracking. It does not automatically unattached upon return of the call into managed code. Then at shutdown the native thread is part of the list of threads that are expected to exit before the runtime can shut down properly.

Try to call mono_thread_detach() in thread #4 before entering the wait for shutdown.

- Jonathan

On Fri, Dec 13, 2013 at 1:09 PM, Bassam Tabbara <bassam at symform.com<mailto:bassam at symform.com>> wrote:
Hello,

I’m seeing a deadlock on shutdown of latest mono form master when using our own native background thread. Here are backtraces:

* thread #1: tid = 0xd83c3, 0x00007fff91412716 libsystem_kernel.dylib`__psynch_cvwait + 10, queue = 'com.apple.main-thread, stop reason = signal SIGSTOP
    frame #0: 0x00007fff91412716 libsystem_kernel.dylib`__psynch_cvwait + 10
    frame #1: 0x00007fff86b20c3b libsystem_pthread.dylib`_pthread_cond_wait + 727
    frame #2: 0x000000010919a892 mono`_wapi_handle_timedwait_signal_handle(handle=<unavailable>, timeout=<unavailable>, alertable=1, poll=<unavailable>) + 514 at handles.c:1588
    frame #3: 0x00000001091ab95b mono`WaitForMultipleObjectsEx(numobjects=7, handles=0x00007fff56c6f2f0, waitall=1, timeout=4294967295, alertable=1) + 1419 at wait.c:668
    frame #4: 0x0000000109112a2f mono`wait_for_tids(wait=0x00007fff56c6f2f0, timeout=<unavailable>) + 47 at threads.c:2809
    frame #5: 0x0000000109112626 mono`mono_thread_manage + 694 at threads.c:3095
    frame #6: 0x0000000108ffc9fd mono`mono_main(argc=11, argv=<unavailable>) + 6301 at driver.c:2015
    frame #7: 0x0000000108f92a0c mono`main [inlined] mono_main_with_options(argv=<unavailable>, argc=<unavailable>) + 549 at main.c:98
    frame #8: 0x0000000108f927e7 mono`main(argc=<unavailable>, argv=<unavailable>) + 39 at main.c:133
    frame #9: 0x00007fff8d7875fd libdyld.dylib`start + 1

  thread #2: tid = 0xd83c5, 0x00007fff9140ea56 libsystem_kernel.dylib`semaphore_wait_trap + 10
    frame #0: 0x00007fff9140ea56 libsystem_kernel.dylib`semaphore_wait_trap + 10
    frame #1: 0x00000001091b8d38 mono`mono_sem_wait(sem=0x000000010930ad78, alertable=<unavailable>) + 24 at mono-semaphore.c:121
    frame #2: 0x0000000109136017 mono`finalizer_thread(unused=<unavailable>) + 103 at gc.c:1073
    frame #3: 0x000000010910d743 mono`start_wrapper [inlined] start_wrapper_internal + 456 at threads.c:609
    frame #4: 0x000000010910d57b mono`start_wrapper(data=<unavailable>) + 43 at threads.c:654
    frame #5: 0x00000001091acd50 mono`thread_start_routine(args=0x00007f930981cbf8) + 144 at wthreads.c:294
    frame #6: 0x00000001091bdffa mono`inner_start_thread(arg=<unavailable>) + 58 at mono-threads-posix.c:49
    frame #7: 0x00007fff86b1e899 libsystem_pthread.dylib`_pthread_body + 138
    frame #8: 0x00007fff86b1e72a libsystem_pthread.dylib`_pthread_start + 137
    frame #9: 0x00007fff86b22fc9 libsystem_pthread.dylib`thread_start + 13

  thread #3: tid = 0xd83c9, 0x00007fff91413662 libsystem_kernel.dylib`kevent64 + 10, queue = 'com.apple.libdispatch-manager
    frame #0: 0x00007fff91413662 libsystem_kernel.dylib`kevent64 + 10
    frame #1: 0x00007fff8e0ac43d libdispatch.dylib`_dispatch_mgr_invoke + 239
    frame #2: 0x00007fff8e0ac152 libdispatch.dylib`_dispatch_mgr_thread + 52

  thread #4: tid = 0xda1fc, 0x00007fff9141364a libsystem_kernel.dylib`kevent + 10
    frame #0: 0x00007fff9141364a libsystem_kernel.dylib`kevent + 10
    frame #1: 0x000000010fa22712 libsymformutp.dylib`kq_dispatch(base=0x00007f930b564890, tv=<unavailable>) + 706 at kqueue.c:301
    frame #2: 0x000000010fa17429 libsymformutp.dylib`event_base_loop(base=0x00007f930b564890, flags=<unavailable>) + 873 at event.c:1826
    frame #3: 0x000000010f9fe657 libsymformutp.dylib`UTPEvents::Run(e=0x00007f930b566180) + 23 at utp_event.cpp:81
    frame #4: 0x00007fff86b1e899 libsystem_pthread.dylib`_pthread_body + 138
    frame #5: 0x00007fff86b1e72a libsystem_pthread.dylib`_pthread_start + 137
    frame #6: 0x00007fff86b22fc9 libsystem_pthread.dylib`thread_start + 13

thread #4 is out native thread that will be shutdown when a managed SafeHandle is released. This thread is likely to have called managed code at some point. thread #1 seems to be waiting on all threads to exit including thread #4, but until finalization is complete on thread #2 this is not going to happen, and hence the deadlock.

Does this seem likely? Why does mono runtime wait for threads to exit that it did not create? Should finalization happen before waiting for all threads to exit?

Thanks in advance for the help.
Bassam
_______________________________________________
Mono-devel-list mailing list
Mono-devel-list at lists.ximian.com<mailto:Mono-devel-list at lists.ximian.com>
http://lists.ximian.com/mailman/listinfo/mono-devel-list

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ximian.com/pipermail/mono-devel-list/attachments/20131213/9fbc0a6c/attachment-0001.html>