Bug 46536 - [coop] mono_os_mutex_destroy: pthread_mutex_destroy failed with "Device or resource busy" (16)
Summary: [coop] mono_os_mutex_destroy: pthread_mutex_destroy failed with "Device or re...
Status: RESOLVED FIXED
Alias: None
Product: Runtime
Classification: Mono
Component: io-layer ()
Version: unspecified
Hardware: PC Linux
: --- normal
Target Milestone: ---
Assignee: Ludovic Henry
URL:
Depends on:
Blocks:
 
Reported: 2016-11-07 13:59 UTC by Łukasz Domeradzki
Modified: 2016-11-15 16:38 UTC (History)
3 users (show)

Tags:
Is this bug a regression?: Yes
Last known good build: d1555df2445f036f891daf12e4aa9f9fddf1c6d5


Attachments
Reproducable case (556 bytes, text/plain)
2016-11-07 13:59 UTC, Łukasz Domeradzki
Details


Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.


Please create a new report on GitHub or Developer Community with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:
Status:
RESOLVED FIXED

Description Łukasz Domeradzki 2016-11-07 13:59:16 UTC
Created attachment 18353 [details]
Reproducable case

I'm running self-compiled build on Linux --with-cooperative-gc=yes. Probably after https://github.com/mono/mono/pull/3881 it's no longer possible to exit process in a clean way via Environment.Exit() if another thread is currently waiting e.g. in ManualResetEvent. I attached reproducable case, as well as debug output from my own Mono. Thank you in advance for looking into this!




root@archi:/tmp/mono# mcs Program.cs
root@archi:/tmp/mono# mono Program.exe
mono_os_mutex_destroy: pthread_mutex_destroy failed with "Device or resource busy" (16)
Stacktrace:

  at <unknown> <0xffffffff>
  at (wrapper managed-to-native) System.Threading.InternalThread.Thread_free_internal (System.Threading.InternalThread) <0x00078>
  at System.Threading.InternalThread.Finalize () <0x00028>
  at (wrapper runtime-invoke) object.runtime_invoke_virtual_void__this__ (object,intptr,intptr,intptr) <0x0007c>

Native stacktrace:

        mono(+0xc32bf) [0x55c0e6a362bf]
        /lib/x86_64-linux-gnu/libpthread.so.0(+0x11100) [0x7fd0ef38e100]
        /lib/x86_64-linux-gnu/libc.so.6(gsignal+0xcf) [0x7fd0eedfafdf]
        /lib/x86_64-linux-gnu/libc.so.6(abort+0x16a) [0x7fd0eedfc40a]
        mono(+0x280ed4) [0x55c0e6bf3ed4]
        mono(+0x298ae3) [0x55c0e6c0bae3]
        mono(+0x278061) [0x55c0e6beb061]
        mono(+0x1c2e42) [0x55c0e6b35e42]
        [0x407510e9]

Debug info from gdb:

[New LWP 22982]
[New LWP 22983]
[New LWP 22984]
[New LWP 23044]
warning: File "/opt/mono/bin/mono-sgen-gdb.py" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load".
To enable execution of this file add
        add-auto-load-safe-path /opt/mono/bin/mono-sgen-gdb.py
line to your configuration file "/root/.gdbinit".
To completely disable this security protection add
        set auto-load safe-path /
line to your configuration file "/root/.gdbinit".
For more information about this security protection see the
"Auto-loading safe path" section in the GDB manual.  E.g., run from the shell:
        info "(gdb)Auto-loading safe path"
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
185     ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S: No such file or directory.
  Id   Target Id         Frame
* 1    Thread 0x7fd0efeb2740 (LWP 22981) "mono" pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
  2    Thread 0x7fd0ee3ff700 (LWP 22982) "SGen worker" pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
  3    Thread 0x7fd0eeb9d700 (LWP 22983) "Finalizer" 0x00007fd0ef38db7b in __waitpid (pid=23046, stat_loc=0x7fd0eeb9babc, options=0) at ../sysdeps/unix/sysv/linux/waitpid.c:29
  4    Thread 0x7fd0ebbff700 (LWP 22984) "Timer-Scheduler" pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
  5    Thread 0x7fd0eb7fd700 (LWP 23044) "Threadpool work" 0x00007fd0ef38c743 in futex_abstimed_wait_cancelable (private=0, abstime=0x7fd0eb7fc280, expected=0, futex_word=0x7fd0d4007410) at ../sysdeps/unix/sysv/linux/futex-internal.h:205

Thread 5 (Thread 0x7fd0eb7fd700 (LWP 23044)):
#0  0x00007fd0ef38c743 in futex_abstimed_wait_cancelable (private=0, abstime=0x7fd0eb7fc280, expected=0, futex_word=0x7fd0d4007410) at ../sysdeps/unix/sysv/linux/futex-internal.h:205
#1  do_futex_wait (sem=sem@entry=0x7fd0d4007410, abstime=abstime@entry=0x7fd0eb7fc280) at sem_waitcommon.c:111
#2  0x00007fd0ef38c80f in __new_sem_wait_slow (sem=0x7fd0d4007410, abstime=0x7fd0eb7fc280) at sem_waitcommon.c:181
#3  0x00007fd0ef38c8c2 in sem_timedwait (sem=<optimized out>, abstime=<optimized out>) at sem_timedwait.c:36
#4  0x000055c0e6b5aa1b in mono_domain_finalize ()
#5  0x000055c0e699d272 in ?? ()
#6  0x000055c0e6add68b in ?? ()
#7  0x0000000040750da0 in ?? ()
#8  0x00007fd0efe60220 in ?? ()
#9  0x00007fd0ee4033b8 in ?? ()
#10 0x00007fd0ee4034e8 in ?? ()
#11 0x00007fd0ee406070 in ?? ()
#12 0x0000000000000001 in ?? ()
#13 0x00007fd0d4001b60 in ?? ()
#14 0x0000000000000001 in ?? ()
#15 0x00007fd0eb7fc400 in ?? ()
#16 0x00007fd0eb7fc310 in ?? ()
#17 0x000000004074ced1 in ?? ()
#18 0x00007fd0efe64798 in ?? ()
#19 0x00007fd0d40024b8 in ?? ()
#20 0x00007fd0ee406080 in ?? ()
#21 0x0000000000000000 in ?? ()

Thread 4 (Thread 0x7fd0ebbff700 (LWP 22984)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x000055c0e6beb573 in ?? ()
#2  0x000055c0e6b34b27 in ?? ()
#3  0x000055c0e6b3a3a7 in ?? ()
#4  0x000055c0e6b3da35 in ?? ()
#5  0x000000004074eb87 in ?? ()
#6  0x00007fd0ee403558 in ?? ()
#7  0xffffffffffffffff in ?? ()
#8  0x7fffffffffffffff in ?? ()
#9  0x00007fd0ee404038 in ?? ()
#10 0x0000000000000000 in ?? ()

Thread 3 (Thread 0x7fd0eeb9d700 (LWP 22983)):
#0  0x00007fd0ef38db7b in __waitpid (pid=23046, stat_loc=0x7fd0eeb9babc, options=0) at ../sysdeps/unix/sysv/linux/waitpid.c:29
#1  0x000055c0e6a36398 in ?? ()
#2  <signal handler called>
#3  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:58
#4  0x00007fd0eedfc40a in __GI_abort () at abort.c:89
#5  0x000055c0e6bf3ed4 in ?? ()
#6  0x000055c0e6c0bae3 in ?? ()
#7  0x000055c0e6beb061 in ?? ()
#8  0x000055c0e6b35e42 in ?? ()
#9  0x00000000407510e9 in ?? ()
#10 0x00007fd0efe64130 in ?? ()
#11 0x000055c0e6d2f750 in ?? ()
#12 0x0000000040750e20 in ?? ()
#13 0x0000000000000000 in ?? ()

Thread 2 (Thread 0x7fd0ee3ff700 (LWP 22982)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x000055c0e6bda17b in ?? ()
#2  0x00007fd0ef384464 in start_thread (arg=0x7fd0ee3ff700) at pthread_create.c:333
#3  0x00007fd0eeeb09df in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105

Thread 1 (Thread 0x7fd0efeb2740 (LWP 22981)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x000055c0e6beb573 in ?? ()
#2  0x000055c0e6b34b27 in ?? ()
#3  0x000055c0e6b3a3a7 in ?? ()
#4  0x0000000041f09dc6 in ?? ()
#5  0x0000000000000000 in ?? ()

=================================================================
Got a SIGABRT while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries
used by your application.
=================================================================

Aborted
Comment 1 Łukasz Domeradzki 2016-11-15 16:20:33 UTC
This has been fixed in one of the follow-up commits after reporting the bug, so I consider the bug as resolved (although feel free to correct my report if needed). Thank you Henry for looking into this!
Comment 2 Ludovic Henry 2016-11-15 16:38:07 UTC
This has been fixed by https://github.com/mono/mono/commit/723e5a1b07db0f4d83c01bf41e8e6120ea86b3b5