[GRASS-dev] Suggestion: wxGUI as default in G6.4

[Markus Neteler]

On Sun, Feb 28, 2010 at 6:10 PM, Glynn Clements
<glynn at gclements.plus.com> 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