[Mono-dev] Possible bug when using array of unsafe pointers

Mon Apr 13 19:27:04 UTC 2015

I can confirm that the problem does not exist with 4.0 alpha. Thanks,
Alexander.

Fabi

On Mon, 13 Apr 2015 at 19:54 Alexander Köplinger <
alex.koeplinger at outlook.com> wrote:

> I tried it on the Mono 4.0 alpha and it didn't repro there (it did crash
> for me on 3.12 as well).
> Can you try upgrading to the 4.0 alpha and see if it works for you as
> well? See
> http://www.mono-project.com/docs/getting-started/install/linux/#alpha-update-channel
>
> -- Alex
>
> ------------------------------
> From: fabian.nagel at gmail.com
> Date: Mon, 13 Apr 2015 18:44:52 +0000
> To: mono-devel-list at lists.ximian.com
> Subject: [Mono-dev] Possible bug when using array of unsafe pointers
>
>
> Dear Devs,
>
> I tried to port my .NET C# application to run on Linux (Fedora21) through
> Mono, but it crashes somewhere in the runtime's garbage collector code with
> segmentation fault. The minimal code to reproduce the problem is as follows:
> SomeStruct*[] ptrs = new SomeStruct*[1];
> ptrs[0] = (SomeStruct*)Marshal.AllocHGlobal(4);
> GC.Collect();
>
> Here some further information:
>
> [fabian at localhost Debug]$ mono --version
> Mono JIT compiler version 3.12.1 (tarball Fri Mar  6 18:53:33 GMT 2015)
> 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
>
> Stacktrace:
>
>   at <unknown> <0xffffffff>
>   at (wrapper managed-to-native) System.GC.InternalCollect (int) <IL
> 0x0000d, 0xffffffff>
>   at System.GC.Collect () [0x00000] in
> /builddir/build/BUILD/mono-3.12.1/mcs/class/corlib/System/GC.cs:51
>   at MMC.Benchmarks.MOT.TestTable (int,bool) [0x00010] in
> /home/fabian/Documents/New
> folder/MemoryContext/Benchmarks/MemoryOperationsTest.cs:227
>   at MMC.Program.Main (string[]) [0x0050d] in /home/fabian/Documents/New
> folder/MemoryContext/Program.cs:379
>   at (wrapper runtime-invoke) <Module>.runtime_invoke_void_object
> (object,intptr,intptr,intptr) <IL 0x00050, 0xffffffff>
>
> Native stacktrace:
>
> mono() [0x4b46c2]
> mono() [0x50c893]
> mono() [0x42ab73]
> /lib64/libpthread.so.0(+0x100d0) [0x7f9bba5050d0]
> /lib64/libc.so.6(+0x145e42) [0x7f9bba066e42]
> mono() [0x5dd2f3]
> mono() [0x5dd581]
> mono() [0x5ddd98]
> mono() [0x5d2d08]
> mono() [0x5d2f0f]
> mono() [0x5d4715]
> mono() [0x5d5212]
> mono() [0x5d87d0]
> mono(mono_gc_collect+0x28) [0x5d9078]
> [0x40337eb2]
>
> 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 "/home/fabian/.gdbinit".
> To completely disable this security protection add
> set auto-load safe-path /
> line to your configuration file "/home/fabian/.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 27513]
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib64/libthread_db.so.1".
> 0x00007f9bba504c6b in waitpid () from /lib64/libpthread.so.0
>   Id   Target Id         Frame
>   2    Thread 0x7f9bb18ec700 (LWP 27513) "Finalizer" 0x00007f9bb9f55cc7 in
> sigsuspend () from /lib64/libc.so.6
> * 1    Thread 0x7f9bbb021780 (LWP 27512) "mono" 0x00007f9bba504c6b in
> waitpid () from /lib64/libpthread.so.0
>
> Thread 2 (Thread 0x7f9bb18ec700 (LWP 27513)):
> #0  0x00007f9bb9f55cc7 in sigsuspend () from /lib64/libc.so.6
> #1  0x00000000005cf99c in suspend_handler ()
> #2  <signal handler called>
> #3  0x00007f9bba50370e in sem_wait () from /lib64/libpthread.so.0
> #4  0x0000000000625587 in mono_sem_wait ()
> #5  0x00000000005a7fcd in finalizer_thread ()
> #6  0x000000000058c370 in start_wrapper ()
> #7  0x000000000062a466 in inner_start_thread ()
> #8  0x00007f9bba4fc52a in start_thread () from /lib64/libpthread.so.0
> #9  0x00007f9bba02122d in clone () from /lib64/libc.so.6
>
> Thread 1 (Thread 0x7f9bbb021780 (LWP 27512)):
> #0  0x00007f9bba504c6b in waitpid () from /lib64/libpthread.so.0
> #1  0x00000000004b474f in mono_handle_native_sigsegv ()
> #2  0x000000000050c893 in mono_arch_handle_altstack_exception ()
> #3  0x000000000042ab73 in mono_sigsegv_signal_handler ()
> #4  <signal handler called>
> #5  0x00007f9bba066e42 in __memcpy_avx_unaligned () from /lib64/libc.so.6
> #6  0x00000000005dd2f3 in copy_object_no_checks ()
> #7  0x00000000005dd581 in major_copy_or_mark_object ()
> #8  0x00000000005ddd98 in major_scan_object ()
> #9  0x00000000005d2d08 in sgen_drain_gray_stack ()
> #10 0x00000000005d2f0f in job_scan_from_registered_roots ()
> #11 0x00000000005d4715 in major_copy_or_mark_from_roots ()
> #12 0x00000000005d5212 in major_do_collection ()
> #13 0x00000000005d87d0 in sgen_perform_collection ()
> #14 0x00000000005d9078 in mono_gc_collect ()
> #15 0x0000000040337eb2 in ?? ()
> #16 0x00000000014ad120 in ?? ()
> #17 0x00007ffd488929e0 in ?? ()
> #18 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)
>
>
> Thanks,
> Fabi
>
> _______________________________________________ Mono-devel-list mailing
> list 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/20150413/7311fb1f/attachment.html>