[Mono-dev] Mono crash
mono user
mono.user789 at gmail.com
Fri Sep 5 18:24:27 UTC 2014
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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ximian.com/pipermail/mono-devel-list/attachments/20140905/cf4f6f9f/attachment.html>
More information about the Mono-devel-list
mailing list