Re: [Mono-dev] Mono crash
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 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 0x7fedac1b19e4 in sigsuspend () from /lib64/libc.so.6 > #1 0x005cbf54 in suspend_thread (sig=, > siginfo=, context=0x7fffaa5a8440) at > sgen-os-posix.c:113 > #2 suspend_handler (sig=, siginfo= out>, context=0x7fffaa5a8440) at sgen-os-posix.c:140 > #3 > #4 0x7fedac51e5ba in pthread_cond_wait@@GLIBC_2.3.2 () from > /lib64/libpthread.so.0 > #5 0x0060d99c in _wapi_handle_timedwait_signal_handle > (handle=0x280a, timeout=0x0, alertable=1, poll= out>) at handles.c:1596 > #6 0x0061fe4b in WaitForSingleObjectEx (handle=0x280a, > timeout=4294967295, alertable=1) at wait.c:194 > #7 0x0058233c in ves_icall_System_Threading_Thread_Join_internal > (this=0x7fedacf242d0, ms=-1, thread=0x280a) at threads.c:1306 > #8 0x414e04de in ?? () > #9 0x7feda5c50908 in ?? () > #10 0x7fffaa5a8fa0 in ?? () > #11 0x0001 in ?? () > #12 0x7fffaa5a8fa0 in ?? () > #13 0x414c5c40 in ?? () > #14 0x00a0ba50 in ?? () > #15 0x414e046c in ?? () > #16 0x7fffaa5a8d40 in ?? () > #17 0x7fffaa5a8b30 in ?? () > #18 0x7feda45a51b3 in System.Threading.Thread:Join > (this=../../gdb/dwarf2-frame.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.iuo...@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=" to your MONO_GC_PARAMS. >> >> >> 2014-09-05 20:24 GMT+02:00 mono user : >> >>> 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 < >>> cristo...@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 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 wrote: > >> Is there an
Re: [Mono-dev] Mono crash
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 0x7fedac1b19e4 in sigsuspend () from /lib64/libc.so.6 #1 0x005cbf54 in suspend_thread (sig=, siginfo=, context=0x7fffaa5a8440) at sgen-os-posix.c:113 #2 suspend_handler (sig=, siginfo=, context=0x7fffaa5a8440) at sgen-os-posix.c:140 #3 #4 0x7fedac51e5ba in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #5 0x0060d99c in _wapi_handle_timedwait_signal_handle (handle=0x280a, timeout=0x0, alertable=1, poll=) at handles.c:1596 #6 0x0061fe4b in WaitForSingleObjectEx (handle=0x280a, timeout=4294967295, alertable=1) at wait.c:194 #7 0x0058233c in ves_icall_System_Threading_Thread_Join_internal (this=0x7fedacf242d0, ms=-1, thread=0x280a) at threads.c:1306 #8 0x414e04de in ?? () #9 0x7feda5c50908 in ?? () #10 0x7fffaa5a8fa0 in ?? () #11 0x0001 in ?? () #12 0x7fffaa5a8fa0 in ?? () #13 0x414c5c40 in ?? () #14 0x00a0ba50 in ?? () #15 0x414e046c in ?? () #16 0x7fffaa5a8d40 in ?? () #17 0x7fffaa5a8b30 in ?? () #18 0x7feda45a51b3 in System.Threading.Thread:Join (this=../../gdb/dwarf2-frame.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.iuo...@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=" to your MONO_GC_PARAMS. > > > 2014-09-05 20:24 GMT+02:00 mono user : > >> 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 < >> cristo...@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 >>> 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 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 debu
Re: [Mono-dev] Mono crash
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=" to your MONO_GC_PARAMS. 2014-09-05 20:24 GMT+02:00 mono user : > 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 < > cristo...@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 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 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)] 0x7fba90992cd4 in sigsuspend () from /lib64/libc.so.6 5 Thread 0x7fba88b0e700 (LWP 7099) 0x7fba90992cd4 in sigsuspend () from /lib64/libc.so.6 4 Thread 0x7fba833d0700 (LWP 7100) 0x7fba90d032ad in waitpid () from /lib64/libpthread.so.0 3 Thread 0x7fba88315700 (LWP 7102) 0x7fba90a49163 in epoll_wait () from /lib64/libc.so.6 2 Thread 0x7fba882d4700 (LWP 7103) 0x7fba90d01a21 in sem_timedwait () from /lib64/libpthread.so.0 * 1 Thread 0x7fba917ab780 (LWP 7098) 0x7fba90992cd4 in sigsuspend () from /lib64/libc.so.6 Thread 5 (Thread 0x7fba88b0e700 (LWP 7099)): #0 0x7fba90992cd4 in sigsuspend () from /lib64/libc.so.6 #1 0x005cac54 in suspend_thread (sig=, siginfo=, context=0x7fba88b0d780) at sgen-os-posix.c:113 #2 suspend_handler (sig=, siginfo=>>> optimized out>, context=0x7fba88b0d780) at sgen-os-posix.c:140 #3 #4 0x7fba90d0192e in sem_wait () from /lib64/libpthread.so.0 #5 0x0062c488 in mono_sem_wait (sem=0x977ca0, alertable=1) at mono-semaphore.c:101 #6 0x005a501a in finalizer_thread (unused=>>> out>) at gc.c:1073 #7 0x005823ab in start_wrapper_internal (data=>>> out>) at threads.c:660 #8 start_wrapper (data=) at threads.c:707 #9 0x00631b16 in inner_start_thread (arg=>>> out>) at mono-threads-posix.c:100 #10 0x7fba90cfb9d1 in start_thread () from /lib64/libpthread.so.0 #11 0x7fba90a48b6d in clone () from /lib64/libc.so.6 Thread 4 (Thread 0x7fba833d0700 (LWP 7100)): #0 0x7fba90d032ad in waitpid () from /lib64/libpthread.so.0 #1 0x004a33f8 in mono_handle_native_sigsegv (signal=>>> optimized out>, ctx=) at mini-exceptions.c:2305 #2 0x005005cf in mono_arch_handle_altstack_exception (sigctx=0x7fba9173bac0, fault_addr=, stack_ovf=0) at exceptions-amd64.c:905 #3 0x00415b69 in mono_sigsegv_signal_handler (_dummy=11, info=0x7fba9173bbf0, context=0x7fba9173bac0) at mini.c:6842 #4 #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 0x005d4bc7 in sgen_alloc_internal (type=>>> out>) at sgen-internal.c:16
