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

[Markus Neteler]

On Mon, Mar 1, 2010 at 4:53 PM, Glynn Clements <glynn at gclements.plus.com> wrote:
>
> Markus Neteler wrote:
>
>> 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:
>
>> 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!
>
> This looks very suspicious:
>
> ==15942==    by 0x9043DB4: XML_ParseBuffer (in /usr/lib/wxPython/lib/libwx_gtk2u-2.8.so.0.5.0)

Thanks for your forensic analysis in the 14MB log!
Sidenote: the strange thing for me is that it works on one machine
while on the other
not (while using the same distro with same updates; only CPU and video card are
different; both 64bit).

> On my system, libexpat contains a function named XML_ParseBuffer.

Yes, same here:

grep -i XML_ParseBuffer /usr/src/debug/expat-2.0.1/lib/*
...
/usr/src/debug/expat-2.0.1/lib/xmlparse.c:XML_ParseBuffer(XML_Parser
parser, int len, int isFinal)

> Aha. wxWidgets includes a copy of expat, which it will use if
> configured --with-expat=builtin. That's likely to cause problems if
> both wxWidgets and the system's expat are loaded into Python.
>
> Incidentally, I would expect this to be problematic regardless of
> whether you use the vdigit module.
>
> The only solution is to use a version of wxWidgets built with
> --with-expat=sys.

The changelog says:
lib64wxgtku2.8
* Sun Aug 23 2009 Oden Eriksson <oeriksson mandriva.com> 2.8.10-3mdv2010.0
        + Revision: 419407
        - try to build against system expat

[root at north neteler]# ldd
/usr/lib/wxPython/lib/libwx_gtk2u-2.8.so.0.5.0 | grep pat
[root at north neteler]#

Interestingly, no reference :(
But:

for i in /usr/lib64/libwx_gtk2u_* ; do echo "$i:" ; ldd $i | grep expat; done
...
/usr/lib64/libwx_gtk2u_xrc-2.8.so.0.6.0:
        libexpat.so.1 => /usr/lib64/libexpat.so.1 (0x00007f7c44b84000)

Indeed, the file mentioned above comes from a different RPM:
rpm -qf /usr/lib/wxPython/lib/libwx_gtk2u-2.8.so.0.5.0
lib64wxPythonGTK2.8-2.8.9.2-3mdv2010.0

So, got now the original  wxPythonGTK-2.8.9.2-3mdv2010.0.src.rpm now, there is
an expat copy inside as you state. Indeed, no trace of --with-expat=sys in the
SPEC file! This is opposite to what they do for lib64wxgtku2.8.

Ok, SPEC file enriched with  --with-expat=sys, recompiled, installed and
...MUSIC.... it works!! After 9 months or so wxNVIZ and wxVDIGIT are back
on my laptop.

Great job, Glynn.
Bug report files with the RPM maintainer.

Thanks so much,
Markus