On Sun, Feb 28, 2010 at 6:10 PM, Glynn Clements <[email protected]> wrote: > Markus Neteler wrote: > >> Using gdb, I get this: >> >> GRASS 6.4.0svn (nc_spm_08):~ > gdb python >> GNU gdb 6.8-7mdv2010.0 (Mandriva Linux release 2010.0) >> ... >> (gdb) r >> /home/neteler/grass64/dist.x86_64-unknown-linux-gnu/etc/wxpython/wxgui.py ... >> [...] >> (gdb) bt >> #0 mem2chunk_check (mem=0x7f032d40a000, magic_p=0x0) at hooks.c:156 >> #1 0x00007f034d30633c in free_check (mem=0x7f032d40a000, >> caller=<value optimized out>) at hooks.c:280 >> #2 0x00007f033bde9cf2 in XML_ParserFree () from > > Something (presumably in vdigit or nviz) is corrupting the heap, > causing a crash in an unrelated free().
Here some valgrind tests: CMD="python /home/neteler/grass64/dist.x86_64-unknown-linux-gnu/etc/wxpython/wxgui.py" valgrind --tool=massif $CMD ==14220== Massif, a heap profiler ==14220== Copyright (C) 2003-2009, and GNU GPL'd, by Nicholas Nethercote ==14220== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info ==14220== Command: python /home/neteler/grass64/dist.x86_64-unknown-linux-gnu/etc/wxpython/wxgui.py ==14220== ==14220== Process terminating with default action of signal 11 (SIGSEGV) ==14220== Access not within mapped region at address 0x9 ==14220== at 0x17C5EC2B: ??? (in /usr/lib64/libexpat.so.1.5.2) ==14220== by 0x17C5FCFD: XML_ParserFree (in /usr/lib64/libexpat.so.1.5.2) ==14220== by 0x26BAF3FA: ??? (in /usr/lib64/python2.6/site-packages/_xmlplus/parsers/pyexpat.so) ==14220== by 0x4E9DF36: PyDict_DelItem (dictobject.c:755) ==14220== by 0x4E78823: instance_setattr (classobject.c:794) ==14220== by 0x4EA1C96: PyObject_SetAttr (object.c:1252) ==14220== by 0x4EF5CB8: PyEval_EvalFrameEx (ceval.c:1850) ==14220== by 0x4EF9E1A: PyEval_EvalFrameEx (ceval.c:3792) ==14220== by 0x4EFB304: PyEval_EvalCodeEx (ceval.c:2968) ==14220== by 0x4EF95EA: PyEval_EvalFrameEx (ceval.c:3802) ==14220== by 0x4EFB304: PyEval_EvalCodeEx (ceval.c:2968) ==14220== by 0x4EF95EA: PyEval_EvalFrameEx (ceval.c:3802) ==14220== If you believe this happened as a result of a stack ==14220== overflow in your program's main thread (unlikely but ==14220== possible), you can try to increase the size of the ==14220== main thread stack using the --main-stacksize= flag. ==14220== The main thread stack size used in this run was 8388608. ==14220== Killed and valgrind --tool=memcheck --leak-check=yes --show-reachable=yes $CMD 2> valgrind_memorytest.log 660k.gz: http://gis.fem-environment.eu/download/valgrind_memorytest.log.gz Not sure if that would give any insights... I hope so! Markus _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
