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 kump...@gmail.com 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 mono.user...@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 0x7fedac1b19e4 in sigsuspend () from /lib64/libc.so.6
#1 0x005cbf54 in suspend_thread (sig=value optimized out,
siginfo=value optimized out, context=0x7fffaa5a8440) at
sgen-os-posix.c:113
#2 suspend_handler (sig=value optimized out, siginfo=value optimized
out, context=0x7fffaa5a8440) at sgen-os-posix.c:140
#3 signal handler called
#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=value optimized
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 mono.user...@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
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 mono.user...@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
