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

2011-06-24 Thread 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@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
>  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:
> ...
> 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.
> 0x7fffec894b1f in ?? () from /usr/lib/libQtGui.so.4

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

> (gdb) bt
> #0  0x7fffec894b1f in ?? () from /usr/lib/libQtGui.so.4
> #1  0x7053ad3f in _XError () from
> /usr/lib/x86_64-linux-gnu/libX11.so.6 #2  0x70537fb1 in ?? ()
> from /usr/lib/x86_64-linux-gnu/libX11.so.6 #3  0x70538aa6 in
> _XReply () from /usr/lib/x86_64-linux-gnu/libX11.so.6 #4 
> 0x7052e48d 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  0x70b8a246 in Tk_HandleEvent () from
> /usr/lib/libtk8.5.so.0 #6  0x70b8a7c0 in ?? () from
> /usr/lib/libtk8.5.so.0
> #7  0x708d564f in Tcl_ServiceEvent () from
> /usr/lib/libtcl8.5.so.0 #8  0x708d58d5 in Tcl_DoOneEvent ()
> from /usr/lib/libtcl8.5.so.0 #9  0x711ba2e9 in ?? () from
> /usr/lib/python3.2/lib- dynload/_tkinter.cpython-32mu.so

> #10 0x00465d28 in call_function (f=,
> throwflag=)
> at ../Python/ceval.c:3875
> #11 PyEval_EvalFrameEx (f=, throwflag= optimised out>)
> at ../Python/ceval.c:2673
> #12 0x004675f2 in PyEval_EvalCodeEx (_co= out>, globals=,
> locals=, args=,
> 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
___
PyQt mailing listPyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt

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

2011-06-23 Thread Algis Kabaila 
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@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 
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:
...
Reading symbols from /usr/bin/python3...Reading symbols from 
/usr/lib/debug/usr/bin/python3.2mu...done.
done.
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.
0x7fffec894b1f in ?? () from /usr/lib/libQtGui.so.4
(gdb) bt
#0  0x7fffec894b1f in ?? () from /usr/lib/libQtGui.so.4
#1  0x7053ad3f in _XError () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#2  0x70537fb1 in ?? () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#3  0x70538aa6 in _XReply () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#4  0x7052e48d in XQueryTree () from /usr/lib/x86_64-linux-
gnu/libX11.so.6
#5  0x70b8a246 in Tk_HandleEvent () from /usr/lib/libtk8.5.so.0
#6  0x70b8a7c0 in ?? () from /usr/lib/libtk8.5.so.0
#7  0x708d564f in Tcl_ServiceEvent () from /usr/lib/libtcl8.5.so.0
#8  0x708d58d5 in Tcl_DoOneEvent () from /usr/lib/libtcl8.5.so.0
#9  0x711ba2e9 in ?? () from /usr/lib/python3.2/lib-
dynload/_tkinter.cpython-32mu.so
#10 0x00465d28 in call_function (f=, 
throwflag=)
at ../Python/ceval.c:3875
#11 PyEval_EvalFrameEx (f=, throwflag=)
at ../Python/ceval.c:2673
#12 0x004675f2 in PyEval_EvalCodeEx (_co=, 
globals=, 
locals=, args=, argcount=1, 
kws=0x12a0d40, kwcount=0, 
defs=0xe76ba8, defcount=1, kwdefs=0x0, closure=0x0) at 
../Python/ceval.c:3311
#13 0x00466784 in fast_function (f=, 
throwflag=)
at ../Python/ceval.c:3973
#14 call_function (f=, throwflag=) at 
../Python/ceval.c:3896
#15 PyEval_EvalFrameEx (f=, throwflag=)
at ../Python/ceval.c:2673
#16 0x00466ae0 in fast_function (f=, 
throwflag=)
at ../Python/ceval.c:3963
#17 call_function (f=, throwflag=) at 
../Python/ceval.c:3896
#18 PyEval_EvalFrameEx (f=, throwflag=)
at ../Python/ceval.c:2673
#19 0x004675f2 in PyEval_EvalCodeEx (_co=, 
globals=, 
locals=, args=, argcount=0, 
kws=0x0, kwcount=0, defs=0x0, 
defcount=0, kwdefs=0x0, closure=0x0) at ../Python/ceval.c:3311
#20 0x0046787b in PyEval_EvalCode (co=, 
globals=, 
locals=) at ../Python/ceval.c:761
#21 0x0048d00d in run_mod (fp=0xb149b0, filename=, 
start=, globals=
{'QtGui': , '__builtins__': , '__file__'---Type  to continue, or q  to 
quit---
q
Quit
(gdb) quit
A debugging session is active.

Inferior 1 [process 2344] will be killed.

Quit anyway? (y or n) y
ak@supremo:~$ 


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!

OldAl.
___
PyQt mailing listPyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt

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

2011-06-23 Thread Algis Kabaila 
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:
> > > On Thursday 23 June 2011, 08:28:06 David Townshend wrote:
> > > > 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.
> > > 
> > > Close, but no cigar.
> > > 
> > > after installing assorted .debug packages of python(3), sip, qt,
> > > PyQt, and probably glibc, glib, libstdc++, you usually invoke a
> > > python script with gdb similar to:
> > > 
> > > gdb python3 -ex "set args /usr/bin/idle" -ex run
> > > 
> > > Hth,
> > > Pete
> > 
> > Hi Pete, David et al,
> > 
> > I know "sweet all" about the gdb, so will need to read up on it (at
> > least a little bit).  I  put in the CLI your command and attach the
> > listing, warts and all.  It does not tell *me* much, so I list it all
> > below.  You will see that idle could not be found at the location
> > suggested, so I ran it with the command that IDLE gui had in the
> > properties.
> 
> Sure, that's why I wrote "similar to" ;-).
> 
> > So IDLE did start ok and it failed after the entry of
> > the same commands under (gdb) as has been tried on
> > 
> > idle window earlier (without invoking gdb):
> > >>> from PyQt4 import QtGui
> > >>> app = QtGui.QApplication([])
> > >>> app.quit()
> > >>> app = QtGui.QApplication([])
> > >>> app.quit()  <-- frozen text in IDLE Python Shell.
> > 
> > At  this point "bt" command was entered within the gdb shell.  As
> > expected there are segmentation faults. The following are the "grim
> > details":
> > 
> > **
> > ak@supremo:~$ gdb python3 -ex "set args /usr/bin/idle" -ex run
> > Starting program: /usr/bin/python3 /usr/bin/idle
> > [Thread debugging using libthread_db enabled]
> > /usr/bin/python3: can't open file '/usr/bin/idle': [Errno 2] No such
> > file or directory
> > Program exited with code 02.
> > (gdb) /usr/bin/idle-python3.2 -n
> > Undefined command: "".  Try "help".
> > (gdb) run /usr/bin/idle-python3.2 -n
> > Starting program: /usr/bin/python3 /usr/bin/idle-python3.2 -n
> > [Thread debugging using libthread_db enabled]
> > [New Thread 0x7fffef1cd700 (LWP 1705)]
> > 
> > Program received signal SIGSEGV, Segmentation fault.
> > 0x7fffec894b1f in ?? () from /usr/lib/libQtGui.so.4
> > (gdb) bt
> > #0  0x7fffec894b1f in ?? () from /usr/lib/libQtGui.so.4
> > #1  0x7053ad3f in _XError () from
> > /usr/lib/x86_64-linux-gnu/libX11.so.6 #2  0x70537fb1 in ?? ()
> > from /usr/lib/x86_64-linux-gnu/libX11.so.6 #3  0x70538aa6 in
> > _XReply () from /usr/lib/x86_64-linux-gnu/libX11.so.6 #4
> > 0x7052e48d in XQueryTree () from /usr/lib/x86_64-linux-
> > gnu/libX11.so.6
> 
> That's pretty much useless in this form. That's why I wrote about debug
> packages. I'm sure, that ubuntu provides them somewhere. In your case,
> you need to install the libqt4 (or however Ubuntu calls it) debug
> packages at least to make this backtrace useful.
> 
> Cheers,
> Pete

OK - will do after continuing to sleep.  I am on my night "walk" at the 
moment. I did gather your note on the location of IDLE in the system, but did 
not get the note about the debug packages.  It was already late in the day...

Thanks for your guidance.

Al.
___
PyQt mailing listPyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt

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

2011-06-23 Thread Hans-Peter Jansen 
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:
> > On Thursday 23 June 2011, 08:28:06 David Townshend wrote:
> > > 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.
> >
> > Close, but no cigar.
> >
> > after installing assorted .debug packages of python(3), sip, qt,
> > PyQt, and probably glibc, glib, libstdc++, you usually invoke a
> > python script with gdb similar to:
> >
> > gdb python3 -ex "set args /usr/bin/idle" -ex run
> >
> > Hth,
> > Pete
>
> Hi Pete, David et al,
>
> I know "sweet all" about the gdb, so will need to read up on it (at
> least a little bit).  I  put in the CLI your command and attach the
> listing, warts and all.  It does not tell *me* much, so I list it all
> below.  You will see that idle could not be found at the location
> suggested, so I ran it with the command that IDLE gui had in the
> properties.

Sure, that's why I wrote "similar to" ;-).

> So IDLE did start ok and it failed after the entry of 
> the same commands under (gdb) as has been tried on
>
> idle window earlier (without invoking gdb):
> >>> from PyQt4 import QtGui
> >>> app = QtGui.QApplication([])
> >>> app.quit()
> >>> app = QtGui.QApplication([])
> >>> app.quit()  <-- frozen text in IDLE Python Shell.
>
> At  this point "bt" command was entered within the gdb shell.  As
> expected there are segmentation faults. The following are the "grim
> details":
>
> **
> ak@supremo:~$ gdb python3 -ex "set args /usr/bin/idle" -ex run
> Starting program: /usr/bin/python3 /usr/bin/idle
> [Thread debugging using libthread_db enabled]
> /usr/bin/python3: can't open file '/usr/bin/idle': [Errno 2] No such
> file or directory
> Program exited with code 02.
> (gdb) /usr/bin/idle-python3.2 -n
> Undefined command: "".  Try "help".
> (gdb) run /usr/bin/idle-python3.2 -n
> Starting program: /usr/bin/python3 /usr/bin/idle-python3.2 -n
> [Thread debugging using libthread_db enabled]
> [New Thread 0x7fffef1cd700 (LWP 1705)]
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x7fffec894b1f in ?? () from /usr/lib/libQtGui.so.4
> (gdb) bt
> #0  0x7fffec894b1f in ?? () from /usr/lib/libQtGui.so.4
> #1  0x7053ad3f in _XError () from
> /usr/lib/x86_64-linux-gnu/libX11.so.6 #2  0x70537fb1 in ?? ()
> from /usr/lib/x86_64-linux-gnu/libX11.so.6 #3  0x70538aa6 in
> _XReply () from /usr/lib/x86_64-linux-gnu/libX11.so.6 #4 
> 0x7052e48d in XQueryTree () from /usr/lib/x86_64-linux-
> gnu/libX11.so.6

That's pretty much useless in this form. That's why I wrote about debug 
packages. I'm sure, that ubuntu provides them somewhere. In your case, 
you need to install the libqt4 (or however Ubuntu calls it) debug 
packages at least to make this backtrace useful.

Cheers,
Pete
___
PyQt mailing listPyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt

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

2011-06-23 Thread Algis Kabaila 
On Thu, 23 Jun 2011 07:06:49 PM Hans-Peter Jansen wrote:
> On Thursday 23 June 2011, 08:28:06 David Townshend wrote:
> > 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.
> 
> Close, but no cigar.
> 
> after installing assorted .debug packages of python(3), sip, qt, PyQt,
> and probably glibc, glib, libstdc++, you usually invoke a python script
> with gdb similar to:
> 
> gdb python3 -ex "set args /usr/bin/idle" -ex run
> 
> Hth,
> Pete

Hi Pete, David et al,

I know "sweet all" about the gdb, so will need to read up on it (at least a 
little bit).  I  put in the CLI your command and attach the listing, warts and 
all.  It does not tell *me* much, so I list it all below.  You will see that 
idle could not be found at the location suggested, so I ran it with the 
command that IDLE gui had in the properties.  So IDLE did start ok and it 
failed after the entry of the same commands under (gdb) as has been tried on 
idle window earlier (without invoking gdb):

>>> from PyQt4 import QtGui
>>> app = QtGui.QApplication([])
>>> app.quit()
>>> app = QtGui.QApplication([])
>>> app.quit()  <-- frozen text in IDLE Python Shell.

At  this point "bt" command was entered within the gdb shell.  As expected 
there are segmentation faults. The following are the "grim details":

**
ak@supremo:~$ gdb python3 -ex "set args /usr/bin/idle" -ex run
Starting program: /usr/bin/python3 /usr/bin/idle
[Thread debugging using libthread_db enabled]
/usr/bin/python3: can't open file '/usr/bin/idle': [Errno 2] No such file or 
directory
Program exited with code 02.
(gdb) /usr/bin/idle-python3.2 -n
Undefined command: "".  Try "help".
(gdb) run /usr/bin/idle-python3.2 -n
Starting program: /usr/bin/python3 /usr/bin/idle-python3.2 -n
[Thread debugging using libthread_db enabled]
[New Thread 0x7fffef1cd700 (LWP 1705)]

Program received signal SIGSEGV, Segmentation fault.
0x7fffec894b1f in ?? () from /usr/lib/libQtGui.so.4
(gdb) bt
#0  0x7fffec894b1f in ?? () from /usr/lib/libQtGui.so.4
#1  0x7053ad3f in _XError () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#2  0x70537fb1 in ?? () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#3  0x70538aa6 in _XReply () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#4  0x7052e48d in XQueryTree () from /usr/lib/x86_64-linux-
gnu/libX11.so.6
#5  0x70b8a246 in Tk_HandleEvent () from /usr/lib/libtk8.5.so.0
#6  0x70b8a7c0 in ?? () from /usr/lib/libtk8.5.so.0
#7  0x708d564f in Tcl_ServiceEvent () from /usr/lib/libtcl8.5.so.0
#8  0x708d58d5 in Tcl_DoOneEvent () from /usr/lib/libtcl8.5.so.0
#9  0x711ba2e9 in ?? () from /usr/lib/python3.2/lib-
dynload/_tkinter.cpython-32mu.so
#10 0x00465d28 in call_function (f=, 
throwflag=)
at ../Python/ceval.c:3875
#11 PyEval_EvalFrameEx (f=, throwflag=)
at ../Python/ceval.c:2673
#12 0x004675f2 in PyEval_EvalCodeEx (_co=, 
globals=, 
locals=, args=, argcount=1, 
kws=0x12a0d40, kwcount=0, 
defs=0xe76b68, defcount=1, kwdefs=0x0, closure=0x0) at 
../Python/ceval.c:3311
#13 0x00466784 in fast_function (f=, 
throwflag=)
at ../Python/ceval.c:3973
#14 call_function (f=, throwflag=) at 
../Python/ceval.c:3896
#15 PyEval_EvalFrameEx (f=, throwflag=)
at ../Python/ceval.c:2673
#16 0x00466ae0 in fast_function (f=, 
throwflag=)
at ../Python/ceval.c:3963
#17 call_function (f=, throwflag=) at 
../Python/ceval.c:3896
#18 PyEval_EvalFrameEx (f=, throwflag=)
at ../Python/ceval.c:2673
#19 0x004675f2 in PyEval_EvalCodeEx (_co=, 
globals=, 
locals=, args=, argcount=0, 
kws=0x0, kwcount=0, defs=0x0, 
defcount=0, kwdefs=0x0, closure=0x0) at ../Python/ceval.c:3311
#20 0x0046787b in PyEval_EvalCode (co=, 
globals=, 
locals=) at ../Python/ceval.c:761
#21 0x0048d00d in run_mod (fp=0xb149b0, filename=, 
start=, globals=
{'QtGui': , '__builtins__': , '__file__'---Type  to continue, or q  to 
quit---
q
Quit
(gdb) quit
A debugging session is active.

Inferior 1 [process 1704] will be killed.

Quit anyway? (y or n) y
ak@supremo:~$ 
ak@supremo:~$ gdb python3 -ex "set args /usr/bin/idle" -ex run
Starting program: /usr/bin/python3 /usr/bin/idle
[Thread debugging using libthread_db enabled]
/usr/bin/python3: can't open file '/usr/bin/idle': [Errno 2] No such file or 
directory
Program exited with code 02.
(gdb) /usr/bin/idle-python3.2 -n
Undefined command: "".  Try "help".
(gdb) run /usr/bin/idle-python3.2 -n
Starting program: /usr/bin/python3 /usr/bin/idle-python3.2 -n
[Thread debugging using libthread_db enabled]
[New Thread 0x7fffef1

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

2011-06-23 Thread Hans-Peter Jansen 
On Thursday 23 June 2011, 08:28:06 David Townshend wrote:
> 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.

Close, but no cigar.

after installing assorted .debug packages of python(3), sip, qt, PyQt, 
and probably glibc, glib, libstdc++, you usually invoke a python script 
with gdb similar to:

gdb python3 -ex "set args /usr/bin/idle" -ex run

Hth,
Pete
___
PyQt mailing listPyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt

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

2011-06-22 Thread 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  wrote:

> On Thu, 23 Jun 2011 03:23:36 PM David Townshend wrote:
> > On Thu, Jun 23, 2011 at 6:14 AM, Algis Kabaila 
> 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
>  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 listPyQt@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@supremo:~$ lsb_release -a
> No LSB modules are available.

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

2011-06-22 Thread Algis Kabaila 
On Thu, 23 Jun 2011 03:23:36 PM David Townshend wrote:
> On Thu, Jun 23, 2011 at 6:14 AM, Algis Kabaila  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  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 listPyQt@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@supremo:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu 11.04
Release:11.04
Codename:   natty
ak@supremo:~$ 
ak@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.
___
PyQt mailing listPyQt@riverbankcomputing.com
http://ww

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

2011-06-22 Thread David Townshend 
On Thu, Jun 23, 2011 at 6:14 AM, Algis Kabaila  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  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 listPyQt@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
___
PyQt mailing listPyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt

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

2011-06-22 Thread Algis Kabaila 
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  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 listPyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt

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

2011-06-22 Thread Baz Walter 

On 22/06/11 20:49, David Townshend wrote:

On Wed, Jun 22, 2011 at 2:34 PM, Baz Walter  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 ;-)

___
PyQt mailing listPyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt

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

2011-06-22 Thread David Townshend 
On Wed, Jun 22, 2011 at 2:34 PM, Baz Walter  wrote:

> On 21/06/11 17:04, David Townshend wrote:
>
>> The problem is that creating (and quitting) multiple QApplications in
>> succession causes a segfault.  This situation tends to occur in unit
>> tests,
>> particularly in testing subclasses of QApplication.
>>
>> The following snippet illustrates the problem:
>>
>>  >>> from PyQt4 import QtGui
> >>> app = QtGui.QApplication([])
> >>> app.quit()
> >>> app = QtGui.QApplication([])
> >>> app.quit()
> >>> app = QtGui.QApplication([])
>
 Segmentation fault
>>
>
> 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
> __**_
> PyQt mailing listPyQt@riverbankcomputing.com
> http://www.riverbankcomputing.**com/mailman/listinfo/pyqt
>

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.
___
PyQt mailing listPyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt

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

2011-06-22 Thread Baz Walter 

On 21/06/11 17:04, David Townshend wrote:

The problem is that creating (and quitting) multiple QApplications in
succession causes a segfault.  This situation tends to occur in unit tests,
particularly in testing subclasses of QApplication.

The following snippet illustrates the problem:


>>> from PyQt4 import QtGui
>>> app = QtGui.QApplication([])
>>> app.quit()
>>> app = QtGui.QApplication([])
>>> app.quit()
>>> app = QtGui.QApplication([])

Segmentation fault


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
___
PyQt mailing listPyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt

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

2011-06-22 Thread David Townshend 
On Tue, Jun 21, 2011 at 11:21 PM, Algis Kabaila wrote:

> On Wed, 22 Jun 2011 02:04:25 AM David Townshend wrote:
> > Hi
> >
> > I'm not sure of the appropriate place to file a PyQt bug report, so I
> hope
> > its ok to send it to this mailing list.
> >
> > The problem is that creating (and quitting) multiple QApplications in
> > succession causes a segfault.  This situation tends to occur in unit
> tests,
> > particularly in testing subclasses of QApplication.
> >
> > The following snippet illustrates the problem:
> > >>> from PyQt4 import QtGui
> > >>> app = QtGui.QApplication([])
> > >>> app.quit()
> > >>> app = QtGui.QApplication([])
> > >>> app.quit()
> > >>> app = QtGui.QApplication([])
> >
> > Segmentation fault
> >
> > Here is my python info:
> > Python 3.2 (r32:88445, Apr 15 2011, 11:09:05)
> > [GCC 4.5.2 20110127 (prerelease)] on linux2
> >
> > I'm using PyQt 4.8.4 on Arch Linux.  I have tried it on Windows XP, but
> the
> > segfault does not occur there.  I haven't tried other linux
> distributions.
> >
> > David
>
> David,
>
> There is a bug tracker for bug reports where the bugs should be reported. I
> do
> not remember its URL, however.
>
> On my  kubuntu "natty" OS  the results are somewhat different:
>
> Using GUI Bash Shell:
>
> ak@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 QtGui
> >>> app = QtGui.QApplication([])
> >>> app.quit()
> >>> app = QtGui.QApplication([])
> >>> app.quit()
> >>> app = QtGui.QApplication([])
> >>> app.quit()
> >>> app = QtGui.QApplication([])
> >>> app.quit()
> >>> app = QtGui.QApplication([])
> >>> app.quit()
> >>>   [---> ctrl+D pressed to quit python3.2]
> Segmentation fault
> ak@supremo:~$
>
> Segmentation fault occured when quitting Python3.2, not when repeatedly
> creating and quitting app.
>
> Using IDLE things go strange sooner:
>
> Python 3.2 (r32:88445, Mar 25 2011, 19:56:22)
> [GCC 4.5.2] on linux2
> Type "copyright", "credits" or "license()" for more information.
>  No Subprocess 
> >>> from PyQt4 import QtGui
> >>> app = QtGui.QApplication([])
> >>> app.quit()
> >>> app = QtGui.QApplication([])
> >>> app.quit()
>
> Python 3.2 IDLE shell vanishes from the screen without warning. No 
> pressed after typing app.quit() !
>
> My Linux OS:
> ak@supremo:~$ lsb_release -a
> No LSB modules are available.
> Distributor ID: Ubuntu
> Description:Ubuntu 11.04
> Release:11.04
> Codename:   natty
> ak@supremo:~$
>
> PyQt4 and Qt versions:
>
> 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.QtCore import (PYQT_VERSION_STR, QT_VERSION_STR)
> >>> PYQT_VERSION_STR
> '4.8.4'
> >>> QT_VERSION_STR
> '4.7.2'
> >>>
>
> I've encountered similar problems in PySide.  I think it was considered to
> be
> a Python IDLE fault.  I know it does not shed much light on your problem,
> only
> some additional information.
>
> OldAl.
>

Thanks for the info.  If this doesn't happen in Kubuntu then perhaps it is
specific to my distro (I was working in a terminal, not idle, so its not
that).  Either way, I think I'll dig a little deeper and see if I can get a
useful traceback.

I did look around for a bug report website for quite a while, but didn't
find anything. If anyone knows where I can report a pyqt bug, please let me
know.

David
___
PyQt mailing listPyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt

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

2011-06-21 Thread Algis Kabaila 
On Wed, 22 Jun 2011 02:04:25 AM David Townshend wrote:
> Hi
> 
> I'm not sure of the appropriate place to file a PyQt bug report, so I hope
> its ok to send it to this mailing list.
> 
> The problem is that creating (and quitting) multiple QApplications in
> succession causes a segfault.  This situation tends to occur in unit tests,
> particularly in testing subclasses of QApplication.
> 
> The following snippet illustrates the problem:
> >>> from PyQt4 import QtGui
> >>> app = QtGui.QApplication([])
> >>> app.quit()
> >>> app = QtGui.QApplication([])
> >>> app.quit()
> >>> app = QtGui.QApplication([])
> 
> Segmentation fault
> 
> Here is my python info:
> Python 3.2 (r32:88445, Apr 15 2011, 11:09:05)
> [GCC 4.5.2 20110127 (prerelease)] on linux2
> 
> I'm using PyQt 4.8.4 on Arch Linux.  I have tried it on Windows XP, but the
> segfault does not occur there.  I haven't tried other linux distributions.
> 
> David

David,

There is a bug tracker for bug reports where the bugs should be reported. I do 
not remember its URL, however.

On my  kubuntu "natty" OS  the results are somewhat different:

Using GUI Bash Shell: 

ak@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 QtGui
>>> app = QtGui.QApplication([])
>>> app.quit()
>>> app = QtGui.QApplication([])
>>> app.quit()
>>> app = QtGui.QApplication([])
>>> app.quit()
>>> app = QtGui.QApplication([])
>>> app.quit()
>>> app = QtGui.QApplication([])
>>> app.quit()
>>>   [---> ctrl+D pressed to quit python3.2] 
Segmentation fault
ak@supremo:~$ 

Segmentation fault occured when quitting Python3.2, not when repeatedly 
creating and quitting app.

Using IDLE things go strange sooner:

Python 3.2 (r32:88445, Mar 25 2011, 19:56:22) 
[GCC 4.5.2] on linux2
Type "copyright", "credits" or "license()" for more information.
 No Subprocess 
>>> from PyQt4 import QtGui
>>> app = QtGui.QApplication([])
>>> app.quit()
>>> app = QtGui.QApplication([])
>>> app.quit()

Python 3.2 IDLE shell vanishes from the screen without warning. No  
pressed after typing app.quit() !

My Linux OS:
ak@supremo:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu 11.04
Release:11.04
Codename:   natty
ak@supremo:~$ 

PyQt4 and Qt versions:

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.QtCore import (PYQT_VERSION_STR, QT_VERSION_STR)
>>> PYQT_VERSION_STR
'4.8.4'
>>> QT_VERSION_STR
'4.7.2'
>>> 

I've encountered similar problems in PySide.  I think it was considered to be 
a Python IDLE fault.  I know it does not shed much light on your problem, only 
some additional information.

OldAl.
___
PyQt mailing listPyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt

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

2011-06-21 Thread David Townshend 
Hi

I'm not sure of the appropriate place to file a PyQt bug report, so I hope
its ok to send it to this mailing list.

The problem is that creating (and quitting) multiple QApplications in
succession causes a segfault.  This situation tends to occur in unit tests,
particularly in testing subclasses of QApplication.

The following snippet illustrates the problem:

>>> from PyQt4 import QtGui
>>> app = QtGui.QApplication([])
>>> app.quit()
>>> app = QtGui.QApplication([])
>>> app.quit()
>>> app = QtGui.QApplication([])
Segmentation fault

Here is my python info:
Python 3.2 (r32:88445, Apr 15 2011, 11:09:05)
[GCC 4.5.2 20110127 (prerelease)] on linux2

I'm using PyQt 4.8.4 on Arch Linux.  I have tried it on Windows XP, but the
segfault does not occur there.  I haven't tried other linux distributions.

David
___
PyQt mailing listPyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt