[PyQt] Bug report: multiple QApplication instances cause a segfault

[Hans-Peter Jansen]

On Friday 24 June 2011, 03:35:55 Algis Kabaila wrote:
> On Thu, 23 Jun 2011 10:08:50 PM Hans-Peter Jansen wrote:
> > Dear Al,
> >
> > On Thursday 23 June 2011, 13:26:02 Algis Kabaila wrote:
> > > On Thu, 23 Jun 2011 07:06:49 PM Hans-Peter Jansen wrote:
>
> [snip...]
> Following Pete's advise, I've installed 23 new packages that appeared
> to be dbg related (169 MiB downloaded, 802 MiB additional space of
> hdd used). The gdb was then invoked with the command, shown
> immediately after the "****" marker. After that in the invoked IDLE
> Python Shell given were
>
> the following commands:
> >>> from PyQt4 import QtGui
> >>> app = QtGui.QApplication([])
> >>> app.quit()
> >>> app = QtGui.QApplication([])
> >>> app.quit()
> >>> app = QtGui.QApplication([])
>
> At that point the IDLE Shell "froze".  Typed on the CLI shell was
> *bt*. The whole dialog is shown between the "****" markers.
>
> ************************
> ak at supremo:~$ gdb python3 -ex "set args /usr/bin/idle-python3.2 -n"
> -ex run GNU gdb (Ubuntu/Linaro 7.2-1ubuntu11) 7.2
> Copyright (C) 2010 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later
> <http://gnu.org/licenses/gpl.html> This is free software: you are
> free to change and redistribute it. There is NO WARRANTY, to the
> extent permitted by law.  Type "show copying" and "show warranty" for
> details.
> This GDB was configured as "x86_64-linux-gnu".
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>...
> Reading symbols from /usr/bin/python3...Reading symbols from
> /usr/lib/debug/usr/bin/python3.2mu...done.
> done.

Python symbols could be loaded. Fine.

> Starting program: /usr/bin/python3 /usr/bin/idle-python3.2 -n
> [Thread debugging using libthread_db enabled]
> [New Thread 0x7fffef1cd700 (LWP 2347)]
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x00007fffec894b1f in ?? () from /usr/lib/libQtGui.so.4

libQtGui symbols are still missing. They should appear 
in /usr/lib/debug/usr/lib/.

> (gdb) bt
> #0  0x00007fffec894b1f in ?? () from /usr/lib/libQtGui.so.4
> #1  0x00007ffff053ad3f in _XError () from
> /usr/lib/x86_64-linux-gnu/libX11.so.6 #2  0x00007ffff0537fb1 in ?? ()
> from /usr/lib/x86_64-linux-gnu/libX11.so.6 #3  0x00007ffff0538aa6 in
> _XReply () from /usr/lib/x86_64-linux-gnu/libX11.so.6 #4 
> 0x00007ffff052e48d in XQueryTree () from /usr/lib/x86_64-linux-
> gnu/libX11.so.6

For this case, libX11 symbols could be useful, too.

I've no idea, why these libs appear in /usr/lib/x86_64-linux-gnu? Does 
that mean, that ubuntu hosts 32bit libs in /usr/lib?

Confusing.

> #5  0x00007ffff0b8a246 in Tk_HandleEvent () from
> /usr/lib/libtk8.5.so.0 #6  0x00007ffff0b8a7c0 in ?? () from
> /usr/lib/libtk8.5.so.0
> #7  0x00007ffff08d564f in Tcl_ServiceEvent () from
> /usr/lib/libtcl8.5.so.0 #8  0x00007ffff08d58d5 in Tcl_DoOneEvent ()
> from /usr/lib/libtcl8.5.so.0 #9  0x00007ffff11ba2e9 in ?? () from
> /usr/lib/python3.2/lib- dynload/_tkinter.cpython-32mu.so

> #10 0x0000000000465d28 in call_function (f=<value optimised out>,
> throwflag=<value optimised out>)
>     at ../Python/ceval.c:3875
> #11 PyEval_EvalFrameEx (f=<value optimised out>, throwflag=<value
> optimised out>)
>     at ../Python/ceval.c:2673
> #12 0x00000000004675f2 in PyEval_EvalCodeEx (_co=<value optimised
> out>, globals=<value optimised out>,
>     locals=<value optimised out>, args=<value optimised out>,
> argcount=1, kws=0x12a0d40, kwcount=0,
>     defs=0xe76ba8, defcount=1, kwdefs=0x0, closure=0x0) at
> ../Python/ceval.c:3311

In these frames you can see the difference to missing symbols. While a 
lot of values are optimized out, you see the function arguments, the 
source code line, etc. instead of ?? ().

[...]
> ************************
>
> It is clear that there is segmentation fault. I do not know how to
> read the dbg output and would appreciate advice whether the output is
> useful or not.
>
> @ Pete - do you want me to do any more testing? If yes, just let me
> know. Thanks again!

The whole issue might be hunting a red herring. 

It looks like an unfortunate interaction of tcl, tk, X, Qt and python 
GC. Would you try Baz' suggestion of assigning None to app before 
creating another instance?

In my environment, I'm able to construct and quit a dozen app instances 
without segfaults (even without None assignment in between):

python: 2.6.2
sip: 4.12.3
qt4: 4.7.1
pyqt4: 4.8.4

Still 32bit. Yes, I'm backward..

Creating an QApplication object is one of the most involved Qt calls 
from an "interaction with other parts of the system" perspective, where 
the "other parts" depend on each other and even interact behind the 
scenes.

Now mix in pythons garbarge collector behavior, and you get a feeling, 
why these kind of issues are unpossible to get right in all kinds of 
possible permutations of elements.

I chimed into the discussion to show, how using gdb is able to shed some 
light on such issues.

Pete