Bug 5798 - Thread abort can lead to locks not being released
Summary: Thread abort can lead to locks not being released
Status: ASSIGNED
Alias: None
Product: Runtime
Classification: Mono
Component: General (show other bugs)
Version: 5.0
Hardware: PC Mac OS
: Normal normal
Target Milestone: Future Cycle (TBD)
Assignee: Vlad Brezae
URL:
Depends on:
Blocks:
 
Reported: 2012-06-21 06:57 UTC by Mark Probst
Modified: 2017-07-12 23:26 UTC (History)
5 users (show)

See Also:
Tags:
Is this bug a regression?: ---
Last known good build:


Attachments
Test case. (706 bytes, application/octet-stream)
2012-06-21 06:57 UTC, Mark Probst
Details

Description Mark Probst 2012-06-21 06:57:00 UTC
Created attachment 2095 [details]
Test case.

This bug is what causes the thread6 test to lock up now and then.  The test case here manages to trigger the bug very reliably.

Kumpera had this to say:

"The thread abort issue is probably the same issue I was seeing in finally_guard.
We can't async unwind code that is running a trampoline."

"Say we abort a thread when it is running exactly the fast monitor enter/exit trampoline. We can't
unwind it to the caller so we skip straight to the next LMF and ignore the try/finally altogether."

"Handling this is just a matter of exposing those tramps and associated unwinding information to
our unwinder."
Comment 1 Mark Probst 2015-09-23 12:49:18 UTC
Vlad, this should be fixed now, right?
Comment 2 Vlad Brezae 2015-09-24 16:04:49 UTC
On amd64, x86 and arm, most of these type of problems are fixed, including the one above. I'm not sure what's the state on arm64 but I would assume it is not a priority since we will switch to co-op abort in the near future (?).

This bug in particular wouldn't be reproducible anyway since the monitor asm fastpaths have been killed a month ago.
Comment 3 Ludovic Henry 2017-07-07 18:56:38 UTC
I can reproduce reliably with following version of mono:

> Mono JIT compiler version 5.0.1.1 (2017-02/5077205 Thu May 18 16:11:37 EDT 2017)
> Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com
> 	TLS:           normal
> 	SIGSEGV:       altstack
> 	Notification:  kqueue
> 	Architecture:  x86
> 	Disabled:      none
> 	Misc:          softdebug
> 	LLVM:          yes(3.6.0svn-mono-master/8b1520c)
> 	GC:            sgen (concurrent by default)

To reproduce, download and run attachment with following command:

> mcs lockabort.cs && mono lockabort.exe

When stuck, the stack trace is the following:

> (lldb) bt all
> * thread #1, name = 'tid_403', queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
>   * frame #0: 0xa165195a libsystem_kernel.dylib`semaphore_wait_trap + 10
>     frame #1: 0x002262ab mono`mono_monitor_try_enter_inflated [inlined] mono_os_sem_wait(flags=MONO_SEM_FLAGS_ALERTABLE) at mono-os-semaphore.h:90 [opt]
>     frame #2: 0x002262a1 mono`mono_monitor_try_enter_inflated [inlined] mono_os_sem_timedwait(flags=MONO_SEM_FLAGS_ALERTABLE) at mono-os-semaphore.h:109 [opt]
>     frame #3: 0x0022629f mono`mono_monitor_try_enter_inflated [inlined] mono_coop_sem_timedwait(flags=MONO_SEM_FLAGS_ALERTABLE) at mono-coop-semaphore.h:54 [opt]
>     frame #4: 0x00226290 mono`mono_monitor_try_enter_inflated(obj=<unavailable>, ms=<unavailable>, allow_interruption=<unavailable>, id=<unavailable>) at monitor.c:906 [opt]
>     frame #5: 0x0022561d mono`mono_monitor_try_enter_internal(obj=<unavailable>, ms=<unavailable>, allow_interruption=<unavailable>) at monitor.c:987 [opt]
>     frame #6: 0x00225b0f mono`mono_monitor_enter_v4_internal [inlined] ves_icall_System_Threading_Monitor_Monitor_try_enter_with_atomic_var(obj=<unavailable>, ms=4294967295, lockTaken=<unavailable>) at monitor.c:1146 [opt]
>     frame #7: 0x00225af3 mono`mono_monitor_enter_v4_internal(obj=0x00225563, lock_taken="") at monitor.c:1186 [opt]
>     frame #8: 0x023b5e80
>     frame #9: 0x023b32c4
>     frame #10: 0x023b3044
>     frame #11: 0x023b30ff
>     frame #12: 0x00014dc5 mono`mono_jit_runtime_invoke(method=<unavailable>, obj=<unavailable>, params=<unavailable>, error=<unavailable>) at mini-runtime.c:2533 [opt]
>     frame #13: 0x0022c410 mono`do_runtime_invoke(method=<unavailable>, obj=<unavailable>, params=<unavailable>, exc=<unavailable>, error=<unavailable>) at object.c:2860 [opt]
>     frame #14: 0x0022fcc7 mono`do_exec_main_checked [inlined] mono_runtime_invoke_checked(method=0x018162b8, params=0x024002a0, error=0x0022c3c2) at object.c:3018 [opt]
>     frame #15: 0x0022fc6e mono`do_exec_main_checked(method=<unavailable>, args=<unavailable>, error=0x0022c3c2) at object.c:4680 [opt]
>     frame #16: 0x0022e999 mono`mono_runtime_run_main_checked [inlined] mono_runtime_exec_main_checked(method=0x018162b8, args=0x024002a0, error=0xbffff518) at object.c:4781 [opt]
>     frame #17: 0x0022e979 mono`mono_runtime_run_main_checked(method=0x018162b8, argc=1, argv=0xbffff934, error=0xbffff518) at object.c:4230 [opt]
>     frame #18: 0x000900e7 mono`mono_jit_exec(domain=0x00706040, assembly=0x0060fc60, argc=<unavailable>, argv=<unavailable>) at driver.g.c:1037 [opt]
>     frame #19: 0x00092a52 mono`mono_main [inlined] main_thread_handler at driver.g.c:1106 [opt]
>     frame #20: 0x00092a14 mono`mono_main(argc=<unavailable>, argv=<unavailable>) at driver.g.c:2215 [opt]
>     frame #21: 0x0000416b mono`main [inlined] mono_main_with_options(argc=2, argc=2, argc=2, argv=0xbffff930, argv=0xbffff930, argv=0xbffff930) at main.c:45 [opt]
>     frame #22: 0x0000414a mono`main(argc=2, argv=0xbffff930) at main.c:338 [opt]
>     frame #23: 0x00003985 mono`start + 53
> 
>   thread #2, name = 'SGen worker'
>     frame #0: 0xa165930e libsystem_kernel.dylib`__psynch_cvwait + 10
>     frame #1: 0xa173deb0 libsystem_pthread.dylib`_pthread_cond_wait + 647
>     frame #2: 0xa173f844 libsystem_pthread.dylib`pthread_cond_wait$UNIX2003 + 51
>     frame #3: 0x002a4fb1 mono`thread_func [inlined] mono_os_cond_wait(mutex=0x0039ac8c) at mono-os-mutex.h:146 [opt]
>     frame #4: 0x002a4f9f mono`thread_func(thread_data=0x00000000) at sgen-thread-pool.c:129 [opt]
>     frame #5: 0xa173d047 libsystem_pthread.dylib`_pthread_body + 184
>     frame #6: 0xa173cf8f libsystem_pthread.dylib`_pthread_start + 243
>     frame #7: 0xa173c84a libsystem_pthread.dylib`thread_start + 34
> 
>   thread #3, name = 'Finalizer'
>     frame #0: 0xa165195a libsystem_kernel.dylib`semaphore_wait_trap + 10
>     frame #1: 0x00224976 mono`finalizer_thread [inlined] mono_os_sem_wait(flags=MONO_SEM_FLAGS_ALERTABLE) at mono-os-semaphore.h:90 [opt]
>     frame #2: 0x00224968 mono`finalizer_thread [inlined] mono_coop_sem_wait(flags=MONO_SEM_FLAGS_ALERTABLE) at mono-coop-semaphore.h:40 [opt]
>     frame #3: 0x0022495e mono`finalizer_thread(unused=0x00000000) at gc.c:907 [opt]
>     frame #4: 0x001f4ce4 mono`start_wrapper [inlined] start_wrapper_internal at threads.c:837 [opt]
>     frame #5: 0x001f4ba2 mono`start_wrapper(data=<unavailable>) at threads.c:889 [opt]
>     frame #6: 0x002bbbf0 mono`inner_start_thread(data=<unavailable>) at mono-threads.c:1170 [opt]
>     frame #7: 0xa173d047 libsystem_pthread.dylib`_pthread_body + 184
>     frame #8: 0xa173cf8f libsystem_pthread.dylib`_pthread_start + 243
>     frame #9: 0xa173c84a libsystem_pthread.dylib`thread_start + 34
> 
>   thread #4
>     frame #0: 0xa1659cba libsystem_kernel.dylib`__workq_kernreturn + 10
>     frame #1: 0xa173cd06 libsystem_pthread.dylib`_pthread_wqthread + 1210
>     frame #2: 0xa173c826 libsystem_pthread.dylib`start_wqthread + 34
> 
>   thread #5
>     frame #0: 0xa1659cba libsystem_kernel.dylib`__workq_kernreturn + 10
>     frame #1: 0xa173cb95 libsystem_pthread.dylib`_pthread_wqthread + 841
>     frame #2: 0xa173c826 libsystem_pthread.dylib`start_wqthread + 34
> 
>   thread #6
>     frame #0: 0xa1659cba libsystem_kernel.dylib`__workq_kernreturn + 10
>     frame #1: 0xa173cd06 libsystem_pthread.dylib`_pthread_wqthread + 1210
>     frame #2: 0xa173c826 libsystem_pthread.dylib`start_wqthread + 34
> 
>   thread #7
>     frame #0: 0xa1659cba libsystem_kernel.dylib`__workq_kernreturn + 10
>     frame #1: 0xa173cd06 libsystem_pthread.dylib`_pthread_wqthread + 1210
>     frame #2: 0xa173c826 libsystem_pthread.dylib`start_wqthread + 34

It is stuck in the monitor code, so assigning to Vlad, since he is been the latest person to look at it.

Note You need to log in before you can comment on or make changes to this bug.