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

[David Townshend]

If it vanishes, it implies a segfault which you will probably see if you run
idle form the command line. You should be able to get a backtrace by running
idle through gdb, i.e, from the command line, run "gdb idle". Then in gdb
type "run". Idle should start as usual, so get it to crash.  Then within gdb
type "bt". This will give a backtrace which will hopefully at least point to
whether its python, pyqt or qt.

David

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

> On Thu, 23 Jun 2011 03:23:36 PM David Townshend wrote:
> > 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
> No backtrace possible - it's vanishing act of IDLE...  It only happens with
> IDLE for python 3 (3.2).  My os is kubuntu 11.04 "natty".  Sip and PyQt are
> compiled with python 3.2, but Qt is from debian (ubuntu) binaries.
>
> As I could not make use of IDLE, I compiled eric5 from source.  It is a
> really
> nice IDE!  [press "(" gives (), press "," - adds a space after it - and the
> code completion is only the beginning!] - free sales pitch.  It is free as
> in
> beer and OSS.
>
> Here are my system details:
> ak at supremo:~$ lsb_release -a
> No LSB modules are available.
> Distributor ID: Ubuntu
> Description:    Ubuntu 11.04
> Release:        11.04
> Codename:       natty
> ak at supremo:~$
> ak at supremo:~$ python3
> Python 3.2 (r32:88445, Mar 25 2011, 19:56:22)
> [GCC 4.5.2] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> from PyQt4 import QtCore
> >>> QtCore.PYQT_VERSION_STR
> '4.8.4'
> >>> QtCore.QT_VERSION_STR
> '4.7.2'
>
> The key point is that IDLE is for Python3.2 and sip, PyQt are compiled with
> Python3.2.
>
> I have observed this kind of errant behaviour with PySide too.  (PySide
> does
> not yet have a Python3 version).
>
> OldAl.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.riverbankcomputing.com/pipermail/pyqt/attachments/20110623/3b6ea4f3/attachment-0001.html>