[PyQt] Very strange matplotlib behavior

[Hans-Peter Jansen]

Am Sonntag 11 Oktober 2009 schrieb Serge Montagnac:
> I am working on the last releases of PyQt4 and Matplotlib (on mandriva
> Cooker)
> May be I'm tired but found a new problem .... the question looks trivial:
>
> If I copy as a normal user the official example of embedding_in_gtk2.py
> all works well as usual.
> But with  "embedding_in_qt4.py" it is crashing with a segfault.
>
> if I su Root and launch "python embedding_in_qt4.py" it works well !!
>
> I can't understand what is different and it is a big problem when I
> promote an mplWidget as QWidget.
> (Not to say that I had no problem with  previous PyQt4 releases)
> =============================
> I did my best in really checking all environment :
> .bashrc
> .matplolib/matplotlibrc and matplotlib.conf
> permissions in backends distrib directory ....
>
> ... no way ... root works and not serge ! have you an idea.

First, do you have anything compiled from tarballs, which you had also 
installed with rpm, or do you use any of the rpm switches: --force 
or --nodeps?

If the answer is yes, you're in trouble, go fix you system (clean everything 
below /usr/local, fix all suspicious output from rpm -Va and learn how to 
build rpm packages).

Given, that you installed everything with your package manager, here's what 
I would do:

install the debug{info,source} packages of [lib]qt4, pyqt4, python, 
matplotlib

$ gdb python -ex "set args embedding_in_qt4.py" -ex run
[some output]
[when it crashed, something similar to the following appears, paste it  
completely into a reply, but please switch off line breaks _before_]:

Program received signal SIGSEGV, Segmentation fault.
0xffffffff in ?? ()
(gdb) bt
#0  0xffffffff in ?? ()
#1  0xb7b1e2bf in PyQtProxy::qt_metacall (this=0xa90cb98, 
_c=QMetaObject::InvokeMetaMethod, _id=1, _a=0xa998b48)
    at qpycore_pyqtproxy.cpp:344
#2  0xb789c788 in QMetaObject::activate(QObject*, int, int, void**) () 
from /usr/lib/libQtCore.so.4
#3  0xb7b24440 in qpycore_emit (qtx=0xa79bea0, signal_index=5, 
parsed_signature=0xada8258, sigargs=0xb7c5702c)
[...]

It may give us a clue.

Pete