not so bad… that actually means that you are running out of heap, badly :P and since I see a primitiveNativeCall there, most probably your (athens?) program is leaking somewhere.
Esteban > On 30 Oct 2015, at 18:01, Johan Fabry <jfa...@dcc.uchile.cl> wrote: > > > More bad luck I’m afraid. What can I do next? > > Program received signal SIGSEGV, Segmentation fault. > 0xb8c0b92d in ?? () > (gdb) p (void)printCallStack() > Cannot access memory at address 0xffffffff > (gdb) > >> On Oct 30, 2015, at 08:11, Esteban Lorenzano <esteba...@gmail.com >> <mailto:esteba...@gmail.com>> wrote: >> >> you can type >> >> p (void)printCallStack() >> >> then you will have the active stack when crash happened. Is often a lot more >> useful than the trace of the vm. >> >> Esteban >> >>> On 29 Oct 2015, at 19:03, Johan Fabry <jfa...@dcc.uchile.cl >>> <mailto:jfa...@dcc.uchile.cl>> wrote: >>> >>> >>> OK, back with access to the Ubuntu machine, I reproduced the crash when >>> running under gdb (reproducing it is never an issue, finding the minimal >>> case is the issue). See below for gdb output. But my vm has no debug >>> information compiled, so it is not really useful. Can I download a vm with >>> debug info compiled from somewhere? I would prefer to avoid having to >>> download the sources and compile et cetera … >>> >>> Once I have such a VM I will make some time to further investigate, and >>> report results. >>> >>> Program received signal SIGSEGV, Segmentation fault. >>> 0xb8c2bc31 in ?? () >>> (gdb) bt >>> #0 0xb8c2bc31 in ?? () >>> #1 0x080fc9f2 in primitiveNativeCall () >>> #2 0xb4fba770 in ?? () >>> #3 0xb503b05e in ?? () >>> #4 0xb503afcb in ?? () >>> #5 0xb5011abd in ?? () >>> #6 0xb4fba5c0 in ?? () >>> (gdb) >>> > > > > ---> Save our in-boxes! http://emailcharter.org <http://emailcharter.org/> > <--- > > Johan Fabry - http://pleiad.cl/~jfabry <http://pleiad.cl/~jfabry> > PLEIAD and RyCh labs - Computer Science Department (DCC) - University of > Chile >
