[Mono-dev] Mono crash

Rodrigo Kumpera kumpera at gmail.com
Sun Sep 7 00:23:00 UTC 2014 

This last backtrace looks perfectly fine.

It's the GC suspend signal handler been executed.


On Sat, Sep 6, 2014 at 10:39 AM, mono user <mono.user789 at gmail.com> wrote:

> I am afraid that max-heap-size might not be the reason. I am seeing the
> crashes at different levels of memory usage.
>
> I have checked that setting the heap size to a small value does not result
> in a crash - an exception is thrown instead. It does not appear to be the
> same OOM exception as under .net, but there is no crash with mono
> stacktraces etc. In contrast, the issue I need help with produces several
> native stacktraces and no IL stacktrace.
>
> Also, it would be be hard to explain why running under a debugger might
> make the problem go away if that was the reason.
>
> BTW, The message at the end of this stacktrace didn't use to happen under
> mono 3.6 and might be an additional indication that some mono internals are
> rather ill at crashtime, though in principle it could be unprovoked and/or
> unrelated gdb breakage.
>
> Thread 1 (Thread 0x7fedacfca780 (LWP 30016)):
> #0  0x00007fedac1b19e4 in sigsuspend () from /lib64/libc.so.6
> #1  0x00000000005cbf54 in suspend_thread (sig=<value optimized out>,
> siginfo=<va            lue optimized out>, context=0x7fffaa5a8440) at
> sgen-os-posix.c:113
> #2  suspend_handler (sig=<value optimized out>, siginfo=<value optimized
> out>, c            ontext=0x7fffaa5a8440) at sgen-os-posix.c:140
> #3  <signal handler called>
> #4  0x00007fedac51e5ba in pthread_cond_wait@@GLIBC_2.3.2 () from
> /lib64/libpthre            ad.so.0
> #5  0x000000000060d99c in _wapi_handle_timedwait_signal_handle
> (handle=0x280a, t            imeout=0x0, alertable=1, poll=<value optimized
> out>) at handles.c:1596
> #6  0x000000000061fe4b in WaitForSingleObjectEx (handle=0x280a,
> timeout=42949672            95, alertable=1) at wait.c:194
> #7  0x000000000058233c in ves_icall_System_Threading_Thread_Join_internal
> (this=            0x7fedacf242d0, ms=-1, thread=0x280a) at threads.c:1306
> #8  0x00000000414e04de in ?? ()
> #9  0x00007feda5c50908 in ?? ()
> #10 0x00007fffaa5a8fa0 in ?? ()
> #11 0x0000000000000001 in ?? ()
> #12 0x00007fffaa5a8fa0 in ?? ()
> #13 0x00000000414c5c40 in ?? ()
> #14 0x0000000000a0ba50 in ?? ()
> #15 0x00000000414e046c in ?? ()
> #16 0x00007fffaa5a8d40 in ?? ()
> #17 0x00007fffaa5a8b30 in ?? ()
> #18 0x00007feda45a51b3 in System.Threading.Thread:Join
> (this=../../gdb/dwarf2-fr            ame.c:694: internal-error: Unknown CFI
> encountered.
> A problem internal to GDB has been detected,
> further debugging may prove unreliable.
> Quit this debugging session? (y or n) [answered Y; input not from terminal]
> ../../gdb/dwarf2-frame.c:694: internal-error: Unknown CFI encountered.
> A problem internal to GDB has been detected,
> further debugging may prove unreliable.
> Create a core file of GDB? (y or n) [answered Y; input not from terminal]
>
>
>
>
>
> On 6 September 2014 08:58, Andrea Francesco Iuorio <
> andreafrancesco.iuorio at gmail.com> wrote:
>
>> Stupid question but someone have to ask: have you set MONO_GC_PARAMS for
>> use a bigger heap ? You can set mono heap size appending
>> "max-heap-size=xxxx" to your MONO_GC_PARAMS.
>>
>>
>> 2014-09-05 20:24 GMT+02:00 mono user <mono.user789 at gmail.com>:
>>
>>> Sorry, I meant to say I was using 3.8.0, not 3.0.8. I'll try the git
>>> version later.
>>>
>>>
>>> On 5 September 2014 19:19, Juan Cristóbal Olivares <
>>> cristobal at cxsoftware.com> wrote:
>>>
>>>> I think you should try with mono 3.8 or, even better, with the git
>>>> version.
>>>>
>>>>
>>>> On Fri, Sep 5, 2014 at 1:26 PM, mono user <mono.user789 at gmail.com>
>>>> wrote:
>>>>
>>>>> It was suggested I try the boehm garbage collector. My code dies
>>>>> quickly, saying "Too many heap sections: Increase MAXHINCR or
>>>>> MAX_HEAP_SECTS"
>>>>>
>>>>> It was also suggested the reason might be that I am running out of
>>>>> memory. That is a possibility, though I now have a crash that happens when
>>>>> Mono is using about 12G of virtual space on a 64G machine. I still wanted
>>>>> to verify if the reason was a failed allocation, and ran mono in a
>>>>> debugger. The code then executed fine, suggesting that lack of resources
>>>>> might not be the reason for the crashes. The same code fails reliably when
>>>>> started from the command line. Having said that, something probably does
>>>>> think that memory has run out. I have seen error messages along the lines
>>>>> of "Error: Garbage collector could not allocate 16384 bytes of memory for
>>>>> major heap section." even though there is plenty of memory available. I
>>>>> have also seen clean out-of-memory crashes (i.e. my code terminates cleanly
>>>>> with a clear error message and no mono stacktrace(s)).
>>>>>
>>>>> I am afraid I cannot provide an example, except possibly if we can
>>>>> narrow down the cause so I can reproduce the crash using a small amount of
>>>>> code and without using any proprietary data (that is currently needed to
>>>>> reproduce the crashes). I am running 3.0.8.
>>>>>
>>>>> Many thanks for any help/suggestions/etc.
>>>>>
>>>>>
>>>>>
>>>>> On 22 August 2014 15:55, mono user <mono.user789 at gmail.com> wrote:
>>>>>
>>>>>> Is there anything I can do to avoid the following crash? I am running
>>>>>> Mono 3.6.0. I am not using any native libraries that don't ship witth Mono.
>>>>>> Many thanks.
>>>>>>
>>>>>>
>>>>>> Stacktrace:
>>>>>>
>>>>>>
>>>>>> Native stacktrace:
>>>>>>
>>>>>>
>>>>>> Debug info from gdb:
>>>>>>
>>>>>> Mono support loaded.
>>>>>> [Thread debugging using libthread_db enabled]
>>>>>> [New Thread 0x7fba882d4700 (LWP 7103)]
>>>>>> [New Thread 0x7fba88315700 (LWP 7102)]
>>>>>> [New Thread 0x7fba833d0700 (LWP 7100)]
>>>>>> [New Thread 0x7fba88b0e700 (LWP 7099)]
>>>>>> 0x00007fba90992cd4 in sigsuspend () from /lib64/libc.so.6
>>>>>>   5 Thread 0x7fba88b0e700 (LWP 7099)  0x00007fba90992cd4 in
>>>>>> sigsuspend () from /lib64/libc.so.6
>>>>>>   4 Thread 0x7fba833d0700 (LWP 7100)  0x00007fba90d032ad in waitpid
>>>>>> () from /lib64/libpthread.s        o.0
>>>>>>   3 Thread 0x7fba88315700 (LWP 7102)  0x00007fba90a49163 in
>>>>>> epoll_wait () from /lib64/libc.so.6
>>>>>>   2 Thread 0x7fba882d4700 (LWP 7103)  0x00007fba90d01a21 in
>>>>>> sem_timedwait () from /lib64/libpth        read.so.0
>>>>>> * 1 Thread 0x7fba917ab780 (LWP 7098)  0x00007fba90992cd4 in
>>>>>> sigsuspend () from /lib64/libc.so.6
>>>>>>
>>>>>> Thread 5 (Thread 0x7fba88b0e700 (LWP 7099)):
>>>>>> #0  0x00007fba90992cd4 in sigsuspend () from /lib64/libc.so.6
>>>>>> #1  0x00000000005cac54 in suspend_thread (sig=<value optimized out>,
>>>>>> siginfo=<value optimized o        ut>, context=0x7fba88b0d780) at
>>>>>> sgen-os-posix.c:113
>>>>>> #2  suspend_handler (sig=<value optimized out>, siginfo=<value
>>>>>> optimized out>, context=0x7fba88        b0d780) at sgen-os-posix.c:140
>>>>>> #3  <signal handler called>
>>>>>> #4  0x00007fba90d0192e in sem_wait () from /lib64/libpthread.so.0
>>>>>> #5  0x000000000062c488 in mono_sem_wait (sem=0x977ca0, alertable=1)
>>>>>> at mono-semaphore.c:101
>>>>>> #6  0x00000000005a501a in finalizer_thread (unused=<value optimized
>>>>>> out>) at gc.c:1073
>>>>>> #7  0x00000000005823ab in start_wrapper_internal (data=<value
>>>>>> optimized out>) at threads.c:660
>>>>>> #8  start_wrapper (data=<value optimized out>) at threads.c:707
>>>>>> #9  0x0000000000631b16 in inner_start_thread (arg=<value optimized
>>>>>> out>) at mono-threads-posix.        c:100
>>>>>> #10 0x00007fba90cfb9d1 in start_thread () from /lib64/libpthread.so.0
>>>>>> #11 0x00007fba90a48b6d in clone () from /lib64/libc.so.6
>>>>>>
>>>>>> Thread 4 (Thread 0x7fba833d0700 (LWP 7100)):
>>>>>> #0  0x00007fba90d032ad in waitpid () from /lib64/libpthread.so.0
>>>>>> #1  0x00000000004a33f8 in mono_handle_native_sigsegv (signal=<value
>>>>>> optimized out>, ctx=<value         optimized out>) at mini-exceptions.c:2305
>>>>>> #2  0x00000000005005cf in mono_arch_handle_altstack_exception
>>>>>> (sigctx=0x7fba9173bac0, fault_add        r=<value optimized out>,
>>>>>> stack_ovf=0) at exceptions-amd64.c:905
>>>>>> #3  0x0000000000415b69 in mono_sigsegv_signal_handler (_dummy=11,
>>>>>> info=0x7fba9173bbf0, context=        0x7fba9173bac0) at mini.c:6842
>>>>>> #4  <signal handler called>
>>>>>> #5  alloc_sb (heap=0x979530) at lock-free-alloc.c:166
>>>>>> #6  alloc_from_new_sb (heap=0x979530) at lock-free-alloc.c:415
>>>>>> #7  mono_lock_free_alloc (heap=0x979530) at lock-free-alloc.c:459
>>>>>> #8  0x00000000005d4bc7 in sgen_alloc_internal (type=<value optimized
>>>>>> out>) at sgen-internal.c:1        69
>>>>>> #9  0x00000000005eda92 in sgen_gray_object_alloc_queue_section
>>>>>> (queue=0x978ba0) at sgen-gray.c:        58
>>>>>> #10 0x00000000005edadd in sgen_gray_object_enqueue (queue=0x978ba0,
>>>>>> obj=<value optimized out>)         at sgen-gray.c:96
>>>>>> #11 0x00000000005d0a1c in pin_objects_from_addresses
>>>>>> (section=0x7fba91744010, start=<value opti        mized out>,
>>>>>> end=0x7fb481428040, start_nursery=<value optimized out>, end_nursery=<value
>>>>>> optimiz        ed out>, ctx=...) at sgen-gc.c:987
>>>>>> #12 0x00000000005d0afb in sgen_pin_objects_in_section
>>>>>> (section=0x7fba91744010, ctx=...) at sgen        -gc.c:1025
>>>>>> #13 0x00000000005d2d81 in collect_nursery (unpin_queue=0x0,
>>>>>> finish_up_concurrent_mark=0) at sge        n-gc.c:2284
>>>>>> #14 0x00000000005d3d88 in sgen_perform_collection
>>>>>> (requested_size=4096, generation_to_collect=0        , reason=0x706be2
>>>>>> "Nursery full", wait_to_finish=<value optimized out>) at sgen-gc.c:3174
>>>>>> #15 0x00000000005f0c64 in mono_gc_alloc_obj_nolock
>>>>>> (vtable=0x7fb78073c190
>>>>>> 0xbcc240
>>>>>> 0xbcc240
>>>>>> 0x7fb78073c190
>>>>>> 0x7fb78073c190
>>>>>> vtable(%s), size=<value optimized out>) at sgen-alloc.c:314
>>>>>> #16 0x00000000005f1074 in mono_gc_alloc_obj (vtable=0x7fb78073c190
>>>>>> 0xbcc240
>>>>>> 0xbcc240
>>>>>> 0x7fb78073c190
>>>>>> 0x7fb78073c190
>>>>>> vtable(%s), size=40) at sgen-alloc.c:490
>>>>>> #17 0x0000000041e50e83 in ?? ()
>>>>>> #18 0x00007fb9fc0025d0 in ?? ()
>>>>>> #19 0x00007fb44dd3cda8 in ?? ()
>>>>>> #20 0x0000000000000028 in ?? ()
>>>>>> #21 0x00007fba8a778ef0 in ?? ()
>>>>>> #22 0x00007fba83279d20 in ?? ()
>>>>>> #23 0x00007fba8a553e58 in ?? ()
>>>>>> #24 0x00007fba8a553e30 in ?? ()
>>>>>> #25 0x00007fba833d06e0 in ?? ()
>>>>>> #26 0x00007fb780721a38 in ?? ()
>>>>>> #27 0x0000000041e4d004 in ?? ()
>>>>>> #28 0x00007fb4e5be8c70 in ?? ()
>>>>>> #29 0x0000000000000000 in ?? ()
>>>>>>
>>>>>> Thread 3 (Thread 0x7fba88315700 (LWP 7102)):
>>>>>> #0  0x00007fba90a49163 in epoll_wait () from /lib64/libc.so.6
>>>>>> #1  0x0000000000585e0a in tp_epoll_wait (p=0x9776a0) at
>>>>>> ../../mono/metadata/tpool-epoll.c:118
>>>>>> #2  0x00000000005823ab in start_wrapper_internal (data=<value
>>>>>> optimized out>) at threads.c:660
>>>>>> #3  start_wrapper (data=<value optimized out>) at threads.c:707
>>>>>> #4  0x0000000000631b16 in inner_start_thread (arg=<value optimized
>>>>>> out>) at mono-threads-posix.        c:100
>>>>>> #5  0x00007fba90cfb9d1 in start_thread () from /lib64/libpthread.so.0
>>>>>> #6  0x00007fba90a48b6d in clone () from /lib64/libc.so.6
>>>>>>
>>>>>> Thread 2 (Thread 0x7fba882d4700 (LWP 7103)):
>>>>>> #0  0x00007fba90d01a21 in sem_timedwait () from /lib64/libpthread.so.0
>>>>>> #1  0x000000000062c59c in mono_sem_timedwait (sem=0x977808,
>>>>>> timeout_ms=<value optimized out>, a        lertable=1) at
>>>>>> mono-semaphore.c:64
>>>>>> #2  0x00000000005870ea in async_invoke_thread (data=0x0) at
>>>>>> threadpool.c:1566
>>>>>> #3  0x00000000005823ab in start_wrapper_internal (data=<value
>>>>>> optimized out>) at threads.c:660
>>>>>> #4  start_wrapper (data=<value optimized out>) at threads.c:707
>>>>>> #5  0x0000000000631b16 in inner_start_thread (arg=<value optimized
>>>>>> out>) at mono-threads-posix.        c:100
>>>>>> #6  0x00007fba90cfb9d1 in start_thread () from /lib64/libpthread.so.0
>>>>>> #7  0x00007fba90a48b6d in clone () from /lib64/libc.so.6
>>>>>>
>>>>>> Thread 1 (Thread 0x7fba917ab780 (LWP 7098)):
>>>>>> #0  0x00007fba90992cd4 in sigsuspend () from /lib64/libc.so.6
>>>>>> #1  0x00000000005cac54 in suspend_thread (sig=<value optimized out>,
>>>>>> siginfo=<value optimized o        ut>, context=0x7fff0cb35880) at
>>>>>> sgen-os-posix.c:113
>>>>>> #2  suspend_handler (sig=<value optimized out>, siginfo=<value
>>>>>> optimized out>, context=0x7fff0c        b35880) at sgen-os-posix.c:140
>>>>>> #3  <signal handler called>
>>>>>> #4  0x00007fba90cff5ba in pthread_cond_wait@@GLIBC_2.3.2 () from
>>>>>> /lib64/libpthread.so.0
>>>>>> #5  0x000000000060c34c in _wapi_handle_timedwait_signal_handle
>>>>>> (handle=0x280a, timeout=0x0, ale        rtable=1, poll=<value optimized
>>>>>> out>) at handles.c:1596
>>>>>> #6  0x000000000061e7fb in WaitForSingleObjectEx (handle=0x280a,
>>>>>> timeout=4294967295, alertable=1        ) at wait.c:194
>>>>>> #7  0x000000000058122c in
>>>>>> ves_icall_System_Threading_Thread_Join_internal (this=0x7fba917102d0,
>>>>>>   ms=-1, thread=0x280a) at threads.c:1306
>>>>>> #8  0x0000000041e653f9 in ?? ()
>>>>>> #9  0x0000000000a16d80 in ?? ()
>>>>>> #10 0x00007fff0cb363f0 in ?? ()
>>>>>> #11 0x00007fba8a4514a8 in ?? ()
>>>>>> #12 0x00007fff0cb36190 in ?? ()
>>>>>> #13 0x00007fff0cb35f80 in ?? ()
>>>>>> #14 0x0000000000a23e40 in ?? ()
>>>>>> #15 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.
>>>>>> =================================================================
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Mono-devel-list mailing list
>>>>> Mono-devel-list at lists.ximian.com
>>>>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Atte,
>>>> Juan Cristóbal Olivares
>>>>
>>>>
>>>> *cxsoftware.com <http://www.cxsoftware.com/>*
>>>> Skype: cxsoftware6001
>>>> Celular: +56-9 9871 7277
>>>> Central: +56-2 2348 7642
>>>>
>>>>
>>>>
>>>
>>>
>>> _______________________________________________
>>> Mono-devel-list mailing list
>>> Mono-devel-list at lists.ximian.com
>>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>>
>>>
>>
>>
>> --
>> *Andrea Francesco Iuorio*
>> Student in Computer Science, Università degli Studi di Milano
>> andreafrancesco.iuorio at gmail.com
>>
>
>
> _______________________________________________
> 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/20140906/e5d37fb7/attachment-0001.html>

More information about the Mono-devel-list mailing list