[PyQt] Bug report: multiple QApplication instances cause a segfault
aquavitae69 at gmail.com
Thu Jun 23 06:23:36 BST 2011
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
> > >> 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
> > > 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 ;-)
> This does not explain why the IDLE quits so early in the test, even before
> is pressed... Actually, in python3.2 if one programs in IDLE, one finds
> 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
> 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
> 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
> I would write it down to my aging memory....
> PyQt mailing list PyQt at riverbankcomputing.com
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the PyQt