The following seems to work:
i) follow the instructions at
https://my.vertica.com/docs/4.1/HTML/Master/12962.htm also see
https://bugzilla.xamarin.com/show_bug.cgi?id=6216#c26
ii) use recent mono, 3.8.0 and current master both work
iii) compile mono with --with-large-heap
iv) use boehm gc
Now it runs well enough to get as far as dying on an assertion inside Mono
:-)
Many thanks to everyone who replied.
On 7 September 2014 01:23, Rodrigo Kumpera wrote:
> 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
