This is Xamarin's bug tracking system. For product support, please use the support links listed in your Xamarin Account.
Bug 35655 - Crash on simple try-catch with Mono.Posix
Summary: Crash on simple try-catch with Mono.Posix
Alias: None
Product: Runtime
Classification: Mono
Component: GC (show other bugs)
Version: 4.2.0 (C6)
Hardware: PC Windows
: --- normal
Target Milestone: ---
Assignee: Andi McClure
Depends on:
Reported: 2015-11-07 16:38 UTC by matthi.d
Modified: 2015-12-03 20:15 UTC (History)
4 users (show)

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


Description matthi.d 2015-11-07 16:38:01 UTC
Steps to reproduce:

1. Download Mono.Posix.dll from Nuget
  1.1 wget
  1.2 unzip 4.0.0
  1.3 cp lib/net40/Mono.Posix.dll Mono.Posix.dll

2. Create a file "crash.cs" with:

namespace MonoCrash {
  using Mono.Unix;
  using System;
  public class Program {
    public static void Main () {
      try {
        var file = new UnixFileInfo("test");
      } catch (Exception e) {
        Console.WriteLine("Error: {0}", e);

3. run "mcs -r:Mono.Posix crash.cs"
4. run "touch test"
5. run "mono crash.exe"

Error: System.ArgumentException: The argument type, 'Mono.Unix.FileAccessPermissions', is not the same as the enum type 'Mono.Unix.Native.FilePermissions'.
   at System.Enum.HasFlag (System.Enum flag) in <filename unknown>:line 0
   at MonoCrash.Program.Main () in <filename unknown>:line 0

Error: System.ArgumentException: The argument type, 'Mono.Unix.FileAccessPermissions', is not the same as the enum type 'Mono.Unix.Native.FilePermissions'.
   at System.Enum.HasFlag (System.Enum flag) in <filename unknown>:line 0
   at MonoCrash.Program.Main () in <filename unknown>:line 0

Native stacktrace:

        mono(+0xc164c) [0x560f7c52064c]
        mono(+0x123dd2) [0x560f7c582dd2]
        mono(+0x3e175) [0x560f7c49d175]
        /lib64/ [0x7f5cffa9e350]
        mono(+0x25b892) [0x560f7c6ba892]
        mono(+0x25d35f) [0x560f7c6bc35f]
        mono(+0x24f0c5) [0x560f7c6ae0c5]
        mono(+0x26aa28) [0x560f7c6c9a28]
        mono(+0x24ebd7) [0x560f7c6adbd7]
        mono(+0x250cd5) [0x560f7c6afcd5]
        mono(+0x250f62) [0x560f7c6aff62]
        mono(+0x2519f5) [0x560f7c6b09f5]
        mono(+0x254684) [0x560f7c6b3684]
        mono(+0x254d22) [0x560f7c6b3d22]
        mono(mono_domain_finalize+0x9c) [0x560f7c65d15c]
        mono(+0x3af53) [0x560f7c499f53]
        mono(mono_main+0x12bc) [0x560f7c4f110c]
        /lib64/ [0x7f5cff703b0b]
        mono(_start+0x29) [0x560f7c497f19]

Debug info from gdb:

warning: File "/usr/bin/" 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 /usr/bin/
line to your configuration file "/home/matthid/.gdbinit".
To completely disable this security protection add
        set auto-load safe-path /
line to your configuration file "/home/matthid/.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"
[New LWP 28108]
[New LWP 28107]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/".
0x00007f5cffa9de96 in waitpid () from /lib64/
  Id   Target Id         Frame
  3    Thread 0x7f5cfebff700 (LWP 28107) "mono" 0x00007f5cffa9a00f in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/
  2    Thread 0x7f5cff336700 (LWP 28108) "Finalizer" 0x00007f5cffa9c592 in do_futex_wait.constprop () from /lib64/
* 1    Thread 0x7f5d005b9780 (LWP 28106) "mono" 0x00007f5cffa9de96 in waitpid () from /lib64/

Thread 3 (Thread 0x7f5cfebff700 (LWP 28107)):
#0  0x00007f5cffa9a00f in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/
#1  0x0000560f7c6c8bff in thread_func (thread_data=0x0) at /mnt/temp/var/tmp/portage/dev-lang/mono-
#2  0x00007f5cffa9562c in start_thread () from /lib64/
#3  0x00007f5cff7d88ed in clone () from /lib64/

Thread 2 (Thread 0x7f5cff336700 (LWP 28108)):
#0  0x00007f5cffa9c592 in do_futex_wait.constprop () from /lib64/
#1  0x00007f5cffa9c642 in __new_sem_wait_slow.constprop.0 () from /lib64/
#2  0x0000560f7c6f4a4f in mono_sem_wait (sem=sem@entry=0x560f7ca23140 <finalizer_sem>, alertable=alertable@entry=1) at /mnt/temp/var/tmp/portage/dev-lang/mono-
#3  0x0000560f7c65c0e8 in finalizer_thread (unused=<optimized out>) at /mnt/temp/var/tmp/portage/dev-lang/mono-
#4  0x0000560f7c637b19 in start_wrapper_internal (data=<optimized out>) at /mnt/temp/var/tmp/portage/dev-lang/mono-
#5  start_wrapper (data=<optimized out>) at /mnt/temp/var/tmp/portage/dev-lang/mono-
#6  0x0000560f7c6fd9e4 in inner_start_thread (arg=0x7ffec77736e0) at /mnt/temp/var/tmp/portage/dev-lang/mono-
#7  0x00007f5cffa9562c in start_thread () from /lib64/
#8  0x00007f5cff7d88ed in clone () from /lib64/

Thread 1 (Thread 0x7f5d005b9780 (LWP 28106)):
#0  0x00007f5cffa9de96 in waitpid () from /lib64/
#1  0x0000560f7c52071f in mono_handle_native_sigsegv (signal=signal@entry=11, ctx=ctx@entry=0x7f5d004afac0, info=info@entry=0x7f5d004afbf0) at /mnt/temp/var/tmp/portage/dev-lang/mono-
#2  0x0000560f7c582dd2 in mono_arch_handle_altstack_exception (sigctx=sigctx@entry=0x7f5d004afac0, siginfo=siginfo@entry=0x7f5d004afbf0, fault_addr=<optimized out>, stack_ovf=stack_ovf@entry=0) at /mnt/temp/var/tmp/portage/dev-lang/mono-
#3  0x0000560f7c49d175 in mono_sigsegv_signal_handler (_dummy=11, _info=0x7f5d004afbf0, context=0x7f5d004afac0) at /mnt/temp/var/tmp/portage/dev-lang/mono-
#4  <signal handler called>
#5  0x0000560f7c6ba892 in copy_object_no_checks (obj=obj@entry=0x7f5cfec004d0, queue=queue@entry=0x560f7ca35060 <gray_queue>) at /mnt/temp/var/tmp/portage/dev-lang/mono-
#6  0x0000560f7c6bc35f in major_copy_or_mark_object_with_evacuation (queue=0x560f7ca35060 <gray_queue>, obj=0x7f5cfec004d0, ptr=0x560f7d2c42c8) at /mnt/temp/var/tmp/portage/dev-lang/mono-
#7  major_copy_or_mark_object_canonical (ptr=0x560f7d2c42c8, queue=0x560f7ca35060 <gray_queue>) at /mnt/temp/var/tmp/portage/dev-lang/mono-
#8  0x0000560f7c6ae0c5 in precisely_scan_objects_from (end_root=<optimized out>, n_start=<optimized out>, n_end=<optimized out>, ctx=..., desc=1, start_root=0x560f7d2c42c8) at /mnt/temp/var/tmp/portage/dev-lang/mono-
#9  scan_from_registered_roots (addr_start=<optimized out>, addr_end=<optimized out>, ctx=..., root_type=<optimized out>) at /mnt/temp/var/tmp/portage/dev-lang/mono-
#10 job_scan_from_registered_roots (worker_data_untyped=<optimized out>, job=<optimized out>) at /mnt/temp/var/tmp/portage/dev-lang/mono-
#11 0x0000560f7c6c9a28 in sgen_workers_enqueue_job (job=0x7f5d005ce050) at /mnt/temp/var/tmp/portage/dev-lang/mono-
#12 0x0000560f7c6adbd7 in enqueue_scan_from_roots_jobs (heap_start=0x0, heap_end=0xffffffffffffffff <error: Cannot access memory at address 0xffffffffffffffff>, ops=0x560f7ca3a580 <major_collector+64>) at /mnt/temp/var/tmp/portage/dev-lang/mono-
#13 0x0000560f7c6afcd5 in major_copy_or_mark_from_roots (old_next_pin_slot=old_next_pin_slot@entry=0x7ffec7773780, mode=COPY_OR_MARK_FROM_ROOTS_SERIAL, scan_whole_nursery=scan_whole_nursery@entry=0, object_ops=object_ops@entry=0x560f7ca3a580 <major_collector+64>) at /mnt/temp/var/tmp/portage/dev-lang/mono-
#14 0x0000560f7c6aff62 in major_start_collection (concurrent=concurrent@entry=0, old_next_pin_slot=old_next_pin_slot@entry=0x7ffec7773780) at /mnt/temp/var/tmp/portage/dev-lang/mono-
#15 0x0000560f7c6b09f5 in major_do_collection (reason=0x560f7c7af32f "user request", forced=1) at /mnt/temp/var/tmp/portage/dev-lang/mono-
#16 0x0000560f7c6b3684 in sgen_perform_collection (requested_size=requested_size@entry=0, generation_to_collect=generation_to_collect@entry=1, reason=reason@entry=0x560f7c7af32f "user request", wait_to_finish=<optimizedout>, wait_to_finish@entry=1) at /mnt/temp/var/tmp/portage/dev-lang/mono-
#17 0x0000560f7c6b3d22 in sgen_gc_collect (generation=1) at /mnt/temp/var/tmp/portage/dev-lang/mono-
#18 0x0000560f7c69208b in mono_gc_collect (generation=<optimized out>) at /mnt/temp/var/tmp/portage/dev-lang/mono-
#19 0x0000560f7c65d15c in mono_domain_finalize (domain=domain@entry=0x560f7d243070, timeout=timeout@entry=2000) at /mnt/temp/var/tmp/portage/dev-lang/mono-
#20 0x0000560f7c499f53 in mini_cleanup (domain=0x560f7d243070) at /mnt/temp/var/tmp/portage/dev-lang/mono-
#21 0x0000560f7c4f110c in mono_main (argc=2, argv=<optimized out>) at /mnt/temp/var/tmp/portage/dev-lang/mono-
#22 0x00007f5cff703b0b in __libc_start_main () from /lib64/
#23 0x0000560f7c497f19 in _start ()

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



Maybe it's because the Mono.Posix assembly from NuGet is somehow broken.
-> It works after "mv Mono.Posix.dll Mono.Posix.dll.old"

However I don't think the runtime should ever crash like this.


user@server ~/crashtest $ mono --version
Mono JIT compiler version 4.2.1 (Stable Fri Oct 23 20:24:22 CEST 2015)
Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors.
        TLS:           __thread
        SIGSEGV:       altstack
        Notifications: epoll
        Architecture:  amd64
        Disabled:      none
        Misc:          softdebug
        LLVM:          supported, not enabled.
        GC:            sgen

a gentoo linux system.

I had the same problem on mono 4.0 but recompiled a later version to have debug symbols and even then this was really really hard to finally track down...

Please let me know if you need more info.
Comment 1 Zoltan Varga 2015-11-07 22:54:40 UTC
Mono.Posix uses the libMonoPosixHelper helper native library which is distributed with mono, mixing different versions is going to lead to crashes like this one, since the two are designed to work together.
Comment 2 matthi.d 2015-11-08 04:03:22 UTC
Thanks for the fast answer!
I already expected something like that. But I still think this is a very subtle problem when building cross-plattform applications.

Because you need to bundle a Mono.Posix.dll to be able to run/build on Windows (obvious solution is to use/upload one on NuGet).
First it works fine, but then breaks on Linux in future mono versions and I can't find a official documentation or recommendation for this use-case.

Maybe mono should crash early when a bundled Mono.Posix.dll (without bundled libMonoPosixHelper) is found? Or Mono.Posix itself should detect such a case and fail early?

IMHO there are at least two problems here:
1. The error/crash message is not helpful at all (I'm not sure if this can be fixed). At least it wasn't for me.

2. A way to safely reference Mono.Posix on cross platform applications.
   From your answer I would expect the following to work:
   - Make sure no Mono.Posix.dll exists in the Application Folder on Linux (like "mv" from above).
   - Bundle libMonoPosixHelper as well. Would this ensure that my application works, even when they change the Mono.Posix C# API? Or is this a bad idea for some other reason?
Comment 3 Zoltan Varga 2015-11-08 09:31:44 UTC
Adding versioning checks between Mono.Posix.dll and libMonoPosixHelper would indeed be useful.
Comment 4 Rodrigo Kumpera 2015-11-17 01:17:27 UTC
Hi Andi,

Since you're spending some time on Mono.Posix, do you mind implementing Zoltan's suggestion of version check between the native and managed libraries?
Comment 5 Andi McClure 2015-12-03 20:15:03 UTC
Zoltan's suggestion implemented in master in 249ee0686bf

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