Bug 25062 - Calling UnixFileSystemInfo derivatives eventually fail with SIGSEGV, sometimes with NullReferenceException caused by System.String
Summary: Calling UnixFileSystemInfo derivatives eventually fail with SIGSEGV, sometime...
Status: RESOLVED INVALID
Alias: None
Product: Class Libraries
Classification: Mono
Component: Mono.POSIX ()
Version: unspecified
Hardware: PC Linux
: --- normal
Target Milestone: Untriaged
Assignee: Bugzilla
URL:
Depends on:
Blocks:
 
Reported: 2014-12-04 05:10 UTC by Toms
Modified: 2014-12-18 04:45 UTC (History)
2 users (show)

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


Attachments
Application source. (7.79 KB, text/plain)
2014-12-04 05:10 UTC, Toms
Details
Another, more simple test case. (1.63 KB, text/plain)
2014-12-08 05:41 UTC, Toms
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 INVALID

Description Toms 2014-12-04 05:10:27 UTC
Created attachment 8961 [details]
Application source.

I have already created a post on StackOverflow, but was suggested to file a report here.

INTRODUCTION:
-------------
I am working on a fairly large Mono application for Linux - could call it a WebOS. Apparently, I have stumbled upon a problem where my application ends up erroring out with SIGSEGV or sometimes with NullReferenceException.

Having found out even more cases where this happens, I gave a shot at creating a side application that might also have such problem. As a matter of fact, it did. The example application is uploaded as an attachment.

The interval of the timer recurrence is as low just for the sake of example. Apparently when running it as fast, I can get to the error faster.

ENVIRONMENT:
------------
Linux stone-development-arch 3.17.2-1-ARCH #1 SMP PREEMPT Thu Oct 30 20:49:39 CET 2014 x86_64 GNU/Linux

Mono JIT compiler version 3.10.0 (tarball Mon Oct  6 20:46:04 UTC 2014)
Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com
        TLS:           __thread
        SIGSEGV:       altstack
        Notifications: epoll
        Architecture:  amd64
        Disabled:      none
        Misc:          softdebug
        LLVM:          supported, not enabled.
        GC:            sgen

I am running this Arch Linux installation in a VirtualBox, have not tested outside Virtual Environment, but I feel that should have no impact here.

Total memory available for the environment ~512MB:

    [root@stone-development-arch ~]# free -b
                  total        used        free      shared  buff/cache   available
    Mem:      517984256    88875008    14987264      233472   414121984   406884352
    Swap:     536866816     2686976   534179840

DETAILS:
--------
As can be seen in source code, lines 41 & 42, respectively:

    // var unixInfo = new FileInfo(statsFile);
    var unixInfo = new UnixFileInfo(statsFile);

I have set up and attempted two solutions. One utilizing the native .NET/Mono itself, the other - Mono.Posix.

When compiled and ran with .NET/Mono, namely, `FileInfo` - there are no problems, everything works as expected.

Now, when compiling and running with Mono.Posix version, namely, `UnixFileInfo` - the application eventually ends up erroring with a SIGSEGV, though, sometimes with NullReferenceException instead.

Error reported with NullReferenceException:

    Unhandled Exception:
    System.NullReferenceException: Object reference not set to an instance of an object
      at System.String.IndexOfAnyUnchecked (System.Char[] anyOf, Int32 startIndex, Int32 count) [0x00000] in :0
      at System.String.IndexOfAny (System.Char[] anyOf) [0x00019] in /build/mono/src/mono-    3.10.0/mcs/class/corlib/System/String.cs:896
      at Mono.Unix.UnixPath.CheckPath (System.String path) [0x00000] in :0
      at Mono.Unix.UnixFileSystemInfo..ctor (System.String path) [0x00000] in :0
      at Mono.Unix.UnixFileInfo..ctor (System.String path) [0x00000] in :0
      at StoneOS.ResourceMonitor.Program.CPUUsage () [0x00008] in /home/stone/sandbox/StoneOS.ResourceMonitor/StoneOS.ResourceMonitor/Program.cs:44
      at StoneOS.ResourceMonitor.Program.m__0 (System.Object state) [0x00001] in /home/stone/sandbox/StoneOS.ResourceMonitor/StoneOS.ResourceMonitor/Program.cs:20
      at System.Threading.Timer+Scheduler.TimerCB (System.Object o) [0x00007] in /build/mono/src/mono-3.10.0/mcs/class/corlib/System.Threading/Timer.cs:317

SIGSEGV case:

    Stacktrace:


    Native stacktrace:

            /usr/lib/libmonosgen-2.0.so.1(+0xd546a) [0x7f2d9851f46a]
            /usr/lib/libmonosgen-2.0.so.1(+0x133aeb) [0x7f2d9857daeb]
            /usr/lib/libmonosgen-2.0.so.1(+0x3fde6) [0x7f2d98489de6]
            /usr/lib/libpthread.so.0(+0x10200) [0x7f2d9823e200]
            /usr/lib/libmonosgen-2.0.so.1(+0x204d70) [0x7f2d9864ed70]
            /usr/lib/libmonosgen-2.0.so.1(+0x20bd4f) [0x7f2d98655d4f]
            /usr/lib/libmonosgen-2.0.so.1(+0x20c159) [0x7f2d98656159]
            /usr/lib/libmonosgen-2.0.so.1(+0x229cb3) [0x7f2d98673cb3]
            /usr/lib/libmonosgen-2.0.so.1(+0x229d7f) [0x7f2d98673d7f]
            [0x4150ff33]

    Debug info from gdb:

    warning: File "/usr/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 /usr/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"
    warning: Could not load shared library symbols for linux-vdso.so.1.
    Do you need "set solib-search-path" or "set sysroot"?
    [New LWP 441]
    [New LWP 440]
    [New LWP 439]
    [New LWP 438]
    [Thread debugging using libthread_db enabled]
    Using host libthread_db library "/usr/lib/libthread_db.so.1".
    0x00007f2d97ebed57 in sigsuspend () from /usr/lib/libc.so.6
      Id   Target Id         Frame
      5    Thread 0x7f2d95c9b700 (LWP 438) "Finalizer" 0x00007f2d97ebed57 in sigsuspend () from /usr/lib/libc.so.6
      4    Thread 0x7f2d956ff700 (LWP 439) "Timer-Scheduler" 0x00007f2d97ebed57 in sigsuspend () from /usr/lib/libc.so.6
      3    Thread 0x7f2d954fe700 (LWP 440) "Threadpool moni" 0x00007f2d97ebed57 in sigsuspend () from /usr/lib/libc.so.6
      2    Thread 0x7f2d954bd700 (LWP 441) "Threadpool work" 0x00007f2d9823ddeb in waitpid () from /usr/lib/libpthread.so.0
    * 1    Thread 0x7f2d98c48780 (LWP 437) "mono" 0x00007f2d97ebed57 in sigsuspend () from /usr/lib/libc.so.6

    Thread 5 (Thread 0x7f2d95c9b700 (LWP 438)):
    #0  0x00007f2d97ebed57 in sigsuspend () from /usr/lib/libc.so.6
    #1  0x00007f2d9864cd46 in ?? () from /usr/lib/libmonosgen-2.0.so.1
    #2  
    #3  0x00007f2d9823c90e in sem_wait () from /usr/lib/libpthread.so.0
    #4  0x00007f2d986ab5c6 in mono_sem_wait () from /usr/lib/libmonosgen-2.0.so.1
    #5  0x00007f2d98624529 in ?? () from /usr/lib/libmonosgen-2.0.so.1
    #6  0x00007f2d986069e7 in ?? () from /usr/lib/libmonosgen-2.0.so.1
    #7  0x00007f2d986b0dd5 in ?? () from /usr/lib/libmonosgen-2.0.so.1
    #8  0x00007f2d98235314 in start_thread () from /usr/lib/libpthread.so.0
    #9  0x00007f2d97f733ed in clone () from /usr/lib/libc.so.6

    Thread 4 (Thread 0x7f2d956ff700 (LWP 439)):
    #0  0x00007f2d97ebed57 in sigsuspend () from /usr/lib/libc.so.6
    #1  0x00007f2d9864cd46 in ?? () from /usr/lib/libmonosgen-2.0.so.1
    #2  
    #3  0x00007f2d9823ac68 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /usr/lib/libpthread.so.0
    #4  0x00007f2d986885ba in ?? () from /usr/lib/libmonosgen-2.0.so.1
    #5  0x00007f2d9869c9c2 in ?? () from /usr/lib/libmonosgen-2.0.so.1
    #6  0x00007f2d9860642f in ?? () from /usr/lib/libmonosgen-2.0.so.1
    #7  0x00007f2d986078dc in ?? () from /usr/lib/libmonosgen-2.0.so.1
    #8  0x000000004152a6ad in ?? ()
    #9  0x0000000000000001 in ?? ()
    #10 0x0000000000000001 in ?? ()
    #11 0x0000000000000032 in ?? ()
    #12 0x00007f2d97002cd0 in ?? ()
    #13 0x0000000000000031 in ?? ()
    #14 0x00007f2d880025e0 in ?? ()
    #15 0x00007f2d956febb0 in ?? ()
    #16 0x00007f2d956fe9f0 in ?? ()
    #17 0x00007f2d956fe950 in ?? ()
    #18 0x000000004152a418 in ?? ()
    #19 0x0000000000000000 in ?? ()

    Thread 3 (Thread 0x7f2d954fe700 (LWP 440)):
    #0  0x00007f2d97ebed57 in sigsuspend () from /usr/lib/libc.so.6
    #1  0x00007f2d9864cd46 in ?? () from /usr/lib/libmonosgen-2.0.so.1
    #2  
    #3  0x00007f2d97f802ca in clock_nanosleep () from /usr/lib/libc.so.6
    #4  0x00007f2d9869df48 in ?? () from /usr/lib/libmonosgen-2.0.so.1
    #5  0x00007f2d98609abe in ?? () from /usr/lib/libmonosgen-2.0.so.1
    #6  0x00007f2d986069e7 in ?? () from /usr/lib/libmonosgen-2.0.so.1
    #7  0x00007f2d986b0dd5 in ?? () from /usr/lib/libmonosgen-2.0.so.1
    #8  0x00007f2d98235314 in start_thread () from /usr/lib/libpthread.so.0
    #9  0x00007f2d97f733ed in clone () from /usr/lib/libc.so.6

    Thread 2 (Thread 0x7f2d954bd700 (LWP 441)):
    #0  0x00007f2d9823ddeb in waitpid () from /usr/lib/libpthread.so.0
    #1  0x00007f2d9851f500 in ?? () from /usr/lib/libmonosgen-2.0.so.1
    #2  0x00007f2d9857daeb in ?? () from /usr/lib/libmonosgen-2.0.so.1
    #3  0x00007f2d98489de6 in ?? () from /usr/lib/libmonosgen-2.0.so.1
    #4  
    #5  0x00007f2d9864ed70 in ?? () from /usr/lib/libmonosgen-2.0.so.1
    #6  0x00007f2d98655d4f in ?? () from /usr/lib/libmonosgen-2.0.so.1
    #7  0x00007f2d98656159 in ?? () from /usr/lib/libmonosgen-2.0.so.1
    #8  0x00007f2d98673cb3 in ?? () from /usr/lib/libmonosgen-2.0.so.1
    #9  0x00007f2d98673d7f in ?? () from /usr/lib/libmonosgen-2.0.so.1
    #10 0x000000004150ff33 in ?? ()
    #11 0x00007f2d973fffa0 in ?? ()
    #12 0x00007f2d973ff108 in ?? ()
    #13 0x000000000000001d in ?? ()
    #14 0x00007f2d973ff108 in ?? ()
    #15 0x0000000000000001 in ?? ()
    #16 0x00007f2d800025e0 in ?? ()
    #17 0x000000000000001f in ?? ()
    #18 0x00007f2d954bc6d0 in ?? ()
    #19 0x00007f2d954bc5e0 in ?? ()
    #20 0x0000000041557efc in ?? ()
    #21 0x00007f2d97000d30 in ?? ()
    #22 0x00007f2d973fffa0 in ?? ()
    #23 0x00007f2d973f1ae8 in ?? ()
    #24 0x000000000000001f in ?? ()
    #25 0x0000000000000001 in ?? ()
    #26 0x000000000000001d in ?? ()
    #27 0x00007f2d954bd680 in ?? ()
    #28 0x00007f2d98673d3f in ?? () from /usr/lib/libmonosgen-2.0.so.1
    #29 0x000000004150ff33 in ?? ()
    #30 0x00007f2d97000d30 in ?? ()
    #31 0x00007f2d973f1ae8 in ?? ()
    #32 0x0000000000000001 in ?? ()
    #33 0x0000000000000025 in ?? ()
    #34 0x00007f2d973f1ae8 in ?? ()
    #35 0x00007f2d97000d30 in ?? ()
    #36 0x00007f2d973f1ae8 in ?? ()
    #37 0x00007f2d97000d30 in ?? ()
    #38 0x00007f2d954bc770 in ?? ()
    #39 0x00000000415577e4 in ?? ()
    #40 0x000000000000001f in ?? ()
    #41 0x0000000000000001 in ?? ()
    #42 0x0000000000000001 in ?? ()
    #43 0x000000000000001c in ?? ()
    #44 0x0000000000000001 in ?? ()
    #45 0x0000000000000025 in ?? ()
    #46 0x000000000000001f in ?? ()
    #47 0x0000000000000001 in ?? ()
    #48 0x0000000000000001 in ?? ()
    #49 0x00007f2d973f1ae8 in ?? ()
    #50 0x00007f2d973fffa0 in ?? ()
    #51 0x0000000000000000 in ?? ()

    Thread 1 (Thread 0x7f2d98c48780 (LWP 437)):
    #0  0x00007f2d97ebed57 in sigsuspend () from /usr/lib/libc.so.6
    #1  0x00007f2d9864cd46 in ?? () from /usr/lib/libmonosgen-2.0.so.1
    #2  
    #3  0x00007f2d9823d3bb in read () from /usr/lib/libpthread.so.0
    #4  0x00007f2d986897e1 in ?? () from /usr/lib/libmonosgen-2.0.so.1
    #5  0x00007f2d985ac234 in ?? () from /usr/lib/libmonosgen-2.0.so.1
    #6  0x0000000041530c61 in ?? ()
    #7  0x00007f2d970168c0 in ?? ()
    #8  0x0000000000000000 in ?? ()

    =================================================================
    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.
    =================================================================

    Aborted (core dumped)

After walking through Mono GDB Debugging guide and setting up the provided .gdbinit and running with gdb:

    Program received signal SIGSEGV, Segmentation fault.
    [Switching to Thread 0x7ffff47fe700 (LWP 4558)]
    0x00007ffff7a1cc47 in ?? () from /usr/lib/libmonosgen-2.0.so.1
    (gdb) mono_backtrace 15
    #0  0x00007ffff7a1cc47 in ?? () from /usr/lib/libmonosgen-2.0.so.1
    #1  0x00007ffff7a1caf8 in ?? () from /usr/lib/libmonosgen-2.0.so.1
    #2  0x00007ffff79f236d in ?? () from /usr/lib/libmonosgen-2.0.so.1
    #3  0x00007ffff79f7725 in ?? () from /usr/lib/libmonosgen-2.0.so.1
    #4  0x00007ffff79f8159 in ?? () from /usr/lib/libmonosgen-2.0.so.1
    #5  0x00007ffff7a15cb3 in ?? () from /usr/lib/libmonosgen-2.0.so.1
    #6  0x00007ffff7a15ed4 in ?? () from /usr/lib/libmonosgen-2.0.so.1
    #7  0x00007ffff79cdb16 in mono_array_new_specific ()
       from /usr/lib/libmonosgen-2.0.so.1
    #8 0x400135cb in Cannot access memory at address 0xffffffffe00f2410

This gives something new, though - the call to mono_array_new_specific, which cannot be seen elsewhere, though, I'm not sure whether it's relevant here.

Well, this feels like a problem with memory management, though, I'm no expert in the field of compiled software - this is my first full blown project in compiled environment.

Another feeling I have is that this is a bug in Mono.Posix library when dealing with those native calls, though, I may be wrong. Anyways, I have found out that this happens (may happen?) when creating an instance of any derivative of UnixFileSystemInfo (UnixFileInfo, UnixSymbolicLinkInfo, ...).

What is the problem here?

P.S. I have ticked the "unspecified" version in reports version field, but, I simply, there is no 3.10.x.
Comment 2 Toms 2014-12-08 05:41:30 UTC
Created attachment 8995 [details]
Another, more simple test case.

Another test case, very weird.

There are 2 regions in the Main method - SIGSEGV_CODE and WORKING_CODE. In short, the SIGSEGV part is just abstracted behind a method but that's enough to immediately cause the SIGSEGV error:

    [stone@stone-development-arch UnixSymbolicLink]$ gdb mono
    GNU gdb (GDB) 7.8.1
    Copyright (C) 2014 Free Software Foundation, Inc.
    License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
    This is free software: you are free to change and redistribute it.
    There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
    and "show warranty" for details.
    This GDB was configured as "x86_64-unknown-linux-gnu".
    Type "show configuration" for configuration details.
    For bug reporting instructions, please see:
    <http://www.gnu.org/software/gdb/bugs/>.
    Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.
    For help, type "help".
    Type "apropos word" to search for commands related to "word"...
    Reading symbols from mono...(no debugging symbols found)...done.
    warning: File "/usr/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 /usr/bin/mono-sgen-gdb.py
    line to your configuration file "/home/stone/.gdbinit".
    To completely disable this security protection add
            set auto-load safe-path /
    line to your configuration file "/home/stone/.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"
    (gdb) run --debug UnixSymbolicLink/bin/Debug/UnixSymbolicLink.exe
    Starting program: /usr/bin/mono --debug UnixSymbolicLink/bin/Debug/UnixSymbolicLink.exe
    warning: Could not load shared library symbols for linux-vdso.so.1.
    Do you need "set solib-search-path" or "set sysroot"?
    [Thread debugging using libthread_db enabled]
    Using host libthread_db library "/usr/lib/libthread_db.so.1".
    [New Thread 0x7ffff4fe9700 (LWP 1025)]
    [New Thread 0x7ffff4bff700 (LWP 1026)]
    [New Thread 0x7ffff6847700 (LWP 1027)]
    [New Thread 0x7ffff49fe700 (LWP 1028)]
    FullName: /etc/localtime; Name: localtime; Attributes: ReadOnly, ReparsePoint; Extension:

    Program received signal SIGSEGV, Segmentation fault.
    [Switching to Thread 0x7ffff49fe700 (LWP 1028)]
    0x000000001d9987ff in ?? ()

Apparently, I cannot seem to get more info out of it, but it feels that the problem is related to the initially asked one.
Comment 3 Toms 2014-12-08 05:58:02 UTC
Attempted to increase memory from 512MB to 1024MB of my Virtual Box - no luck, still segfaults immediately.
Comment 4 Toms 2014-12-09 10:30:09 UTC
Just tested it on Ubuntu Server 14.04 and also on a different (up-to-date, though) Arch system - both yield the same result.

The newest attachment I gave above, always ends up with a SIGSEGV right after starting.
Comment 5 Zoltan Varga 2014-12-10 20:49:24 UTC
I can't reproduce this with current mono master.
Comment 6 Toms 2014-12-11 02:08:00 UTC
What about the latest stable - 3.10.0?
Comment 7 Toms 2014-12-11 05:24:59 UTC
I went through both of these guides:
    http://www.mono-project.com/docs/compiling-mono/linux/
    http://www.mono-project.com/docs/compiling-mono/parallel-mono-environments/

I have built mono.git version (had some complation warnings, but it did finish successfully).

And, set up the ~/mono-git-env:
    #!/bin/bash
    MONO_PREFIX=~/.mono
    export LD_LIBRARY_PATH=$MONO_PREFIX/lib:$LD_LIBRARY_PATH
    export C_INCLUDE_PATH=$MONO_PREFIX/include
    export ACLOCAL_PATH=$MONO_PREFIX/share/aclocal
    export PKG_CONFIG_PATH=$MONO_PREFIX/lib/pkgconfig
    export PATH=$MONO_PREFIX/bin:$PATH
    PS1="[mono] \w @"

Executed it by: 
    source ~/mono-git-env

And still, running the UnixSymbolicLink software (2nd attachment), I end up in a world of Segmentation faults, the same on as before.

Here is a little information about environment (with the fancy PS1 prompt):

    [mono] ~/mono/UnixSymbolicLink @which xbuild
    /root/.mono/bin/xbuild
    [mono] ~/mono/UnixSymbolicLink @xbuild /version
    XBuild Engine Version 12.0
    Mono, Version 3.99.0.0
    Copyright (C) 2005-2013 Various Mono authors

    [mono] ~/mono/UnixSymbolicLink @which mcs
    /root/.mono/bin/mcs
    [mono] ~/mono/UnixSymbolicLink @mcs --version
    Mono C# compiler version 3.99.0.0

    [mono] ~/mono/UnixSymbolicLink @which mono
    /root/.mono/bin/mono
    [mono] ~/mono/UnixSymbolicLink @mono -V
    Mono JIT compiler version 3.99.0 (master/5572635 Thu Dec 11 11:36:39 EET 2014)
    Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com
            TLS:            __thread
            SIGSEGV:        altstack
            Notifications:  epoll
            Architecture:   amd64
            Disabled:       none
            Misc:           softdebug
            LLVM:           supported, not enabled.
            GC:             sgen

    [mono] ~/mono/UnixSymbolicLink @env
    XDG_VTNR=1
    XDG_SESSION_ID=c7
    TERM=linux
    SHELL=/bin/bash
    USER=root
    LD_LIBRARY_PATH=/root/.mono/lib:
    MAIL=/var/spool/mail/root
    PATH=/root/.mono/bin:/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl
    C_INCLUDE_PATH=/root/.mono/include
    PWD=/root/mono/UnixSymbolicLink
    LANG=en_US.UTF-8
    SHLVL=1
    XDG_SEAT=seat0
    HOME=/root
    LOGNAME=root
    PKG_CONFIG_PATH=/root/.mono/lib/pkgconfig
    ACLOCAL_PATH=/root/.mono/share/aclocal
    XDG_RUNTIME_DIR=/run/user/0
    _=/usr/bin/env
    OLDPWD=/root/mono

Well, I'm not a guru in this Linux/Mono world and the problem with mono.git version may reside in my environment not having some exports, therefore looking into the libraries that stable mono is using.

If so, I would really appreciate hints on the matter.

If the libraries is not the case, then I don't know, I'm out of clues. As I already said, building the solution with 3.99.0 xbuild and running with the equivalent mono, yields the same basic segmentation fault error as before.

gdb mono -> run --debug UnixSymbolicLink/bin/Debug/UnixSymbolicLink.exe:
    Starting program: /root/.mono/bin/mono --debug UnixSymbolicLink/bin/Debug/UnixSymbolicLink.exe
    warning: Could not load shared library symbols for linux-vdso.so.1.
    Do you need "set solib-search-path" or "set sysroot"?
    [Thread debugging using libthread_db enabled]
    Using host libthread_db library "/usr/lib/libthread_db.so.1".
    [New Thread 0x7ffff4e72700 (LWP 27345)]
    [New Thread 0x7ffff4aff700 (LWP 27346)]
    [New Thread 0x7ffff4c71700 (LWP 27347)]
    [New Thread 0x7ffff48fe700 (LWP 27348)]
    FullName: /etc/localtime; Name: localtime; Attributes: Normal, ReparsePoint; Extension:

    Program received signal SIGSEGV, Segmentation fault.
    [Switching to Thread 0xffff48fe700 (LWP 27348)]
    0x0000000038bdb91a in ?? ()

mono --debug UnixSymbolicLink/bin/Debug/UnixSymbolicLink.exe
    FullName: /etc/localtime; Name: localtime; Attributes: Normal, ReparsePoint; Extension:
    Stacktrace:


    Native stacktrace:

    Segmentation fault (core dumped)

Maybe there is a way to increase the verbosity/debugging information?
Comment 8 Toms 2014-12-18 04:45:46 UTC
TL;DR:
False alert. The problem is that the nugget version of Mono.Posix, which as of now, seems to be unofficial - and yes, I know nothing is stated there about it being official, contained the bug.

Using the library found in the package of the shipped Mono version (lib/mono) solved the issue.

---

A little time and effort in, and I got it working.

The issue seems to be with the Mono.Posix nuget - I have a feeling it's a little outdated.

While the Mono 3.99.0 (git-master) didn't work, it just came to my mind, that I should try to only replace the Mono.Posix library. Having replaced the Mono.Posix from nuggets' version (https://www.nuget.org/packages/Mono.Posix/) to the one found in lib/mono of my custom git-master build have solved the issue.

I can run it with 3.99.0 runtime - works, can go back to 3.10.0 - also works.

---

Hmm, assuming that the problem relies only in the Nugget version, I just tried to use the library found in Mono 3.10.0's lib/mono - worked too.