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

[David Townshend]

On Thu, Jun 23, 2011 at 6:14 AM, Algis Kabaila <akabaila at pcug.org.au> wrote:

> On Thu, 23 Jun 2011 08:17:04 AM Baz Walter wrote:
> > On 22/06/11 20:49, David Townshend wrote:
> > > On Wed, Jun 22, 2011 at 2:34 PM, Baz Walter<bazwal at ftml.net>  wrote:
> > >> according to the qt docs, only one application object should be
> created
> > >> at a time, and there is a global qApp pointer which refers to the
> > >> current instance.
> > >>
> > >> this suggests that, in pyqt, something like the following should work:
> > >>
> > >> from PyQt4 import QtGui
> > >> QtGui.qApp = app = QtGui.QApplication([])
> > >> app.quit()
> > >> QtGui.qApp = app = None
> >
> > [snip]
> >
> > > I've investigated further and found that its caused by the gtk style
> > > which I am using, since I am running gnome. Simply changing the qt
> style
> > > avoids the problem. I recall reading about similar issues before with
> > > the gtk-qt style, so I think that this is a know problem.  However, I
> > > noticed that after changing the style, python still segfaults on exit.
> > > gdb indicates that it is something in the QApplication destructor, and
> > > it seems that deleting the
> > >
> > > instance after quitting solves this, e.g.:
> > >>>> from PyQt4.QtGui import QApplication
> > >
> > >>>> for i in range(10):
> > > ...     app = QApplication([])
> > > ...     app.quit()
> > > ...     del app
> > > ...
> > >
> > >>>> exit()
> > >
> > > I experimented a bit with setting qApp = None, but it didn't make a
> > > difference.
> >
> > my point was simply that you need to make sure you remove all references
> > to the current qpplication instance before creating a new one.
> >
> > in general, setting qApp to the instance of qapplication isn't
> > necessary. but it's worth noting that qApp won't refer to the same
> > *pyqt* object unless it's explicitly over-written. this may become
> > relevant when working with subclasses of qapplication. of course, if you
> > don't use qApp, it won't make any difference, as you say ;-)
>
> Baz,
>
> This does not explain why the IDLE quits so early in the test, even before
> CR
> is pressed... Actually, in python3.2 if one programs in IDLE, one finds
> that
> IDLE is useless with PyQt as it quits (just vanishes from the screen...) if
> one tries to run a script after modifying it.  Basically, IDLE works only
> if
> it is invoked from scratch each time one wants to run a program.
>
> I suggest that because of such misbehaviour it is not useful to look for
> faults in the test case - there is a fault, either in Python3 IDLE, Python
> 3,
> PyQt, Qt itself.
>
> As for the PyQt bug tracker - I was not able to find it, though I saw bug
> reports in several places, though I said earlier that I did see it
> somewhere.
>
> I would write it down to my aging memory....
>
> OldAl.
> _______________________________________________
> PyQt mailing list    PyQt at riverbankcomputing.com
> http://www.riverbankcomputing.com/mailman/listinfo/pyqt
>

Baz - Sorry, I think I misunderstood you slightly, but I reached the same
conclusion - to delete all references to the instance.  I don't think that
omitting this should cause a segfault though, so it does look like a bug,
but at least its easy to work around.

OldAl - I don't get that behaviour.  Is this is linux or windows, have you
tried to get a backtrace to see where the problem is?  I have to admit I
never use IDLE, I much prefer the console interface, so I haven't had much
opportunity to see if this happens to me.

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.riverbankcomputing.com/pipermail/pyqt/attachments/20110623/c00d6f95/attachment.html>