PySide Bugzilla Closed for New Bugs

PySide is now a Qt Add-on and uses the Qt Project's JIRA Bug Tracker instead of this Bugzilla instance. This Bugzilla is left for reference purposes.

Bug 504 - examples/threads/mandelbrot.py crashes at exit sometimes.
: examples/threads/mandelbrot.py crashes at exit sometimes.
Status: CLOSED FIXED
Product: PySide
Classification: Unclassified
Component: Examples
: 1.0.0 beta1
: All All
: P3 normal
Assigned To: Hugo Parente Lima
:
:
:
  Show dependency treegraph
 
Reported: 2010-11-26 16:37 EET by Hugo Parente Lima
Modified: 2011-01-19 14:11 EET (History)
9 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Hugo Parente Lima 2010-11-26 16:37:25 EET
Behold the stacktrace...

#0  0x00007ffff5e26abd in QMutex::lock (this=0x100000091) at
/home/hugo/src/qt/src/corelib/thread/qmutex.cpp:151
#1  0x00007ffff5e2cd4e in QThreadPrivate::finish (arg=0xe21b20) at
/home/hugo/src/qt/src/corelib/thread/qthread_unix.cpp:307
#2  0x00007ffff5e2db8f in __pthread_cleanup_class::~__pthread_cleanup_class
(this=0x7fffec510ea0, __in_chrg=<value optimized out>) at
/usr/include/pthread.h:545
#3  0x00007ffff5e2ccf1 in QThreadPrivate::start (arg=0xe21b20) at
/home/hugo/src/qt/src/corelib/thread/qthread_unix.cpp:243
#4  0x00007ffff780ccb0 in start_thread () from /lib/libpthread.so.0
#5  0x00007ffff75779dd in clone () from /lib/libc.so.6
#6  0x0000000000000000 in ?? ()
Comment 1 Matti Airas 2010-11-29 06:06:17 EET
We obviously have a mandelbug in our mandelbrot example. How appropriate!

Prioritizing P3.
Comment 2 Matti Airas 2010-12-03 04:43:49 EET
*** Bug 522 has been marked as a duplicate of this bug. ***
Comment 3 Hugo Parente Lima 2011-01-04 19:37:44 EET
I tried it several times and it didn't crash.

At the time of thsi report I remenber that 1/3 of the attempts resulted in
crashes, so I thing it was fixed by other bug fix.

Marking my own bug report as invalid :-)
Comment 4 renato filho 2011-01-06 16:25:22 EET
released on beta3
Comment 5 Farsmo 2011-01-17 20:24:16 EET
On Windows 1.0.0-beta3 this still happens.

The following message occurs:

> QThread: Destroyed while thread is still running
> Error in sys.excepthook:
> 
> Original exception was:
>

and, sometimes, the window reopens continuously until I terminate the process.
Comment 6 Matti Airas 2011-01-18 08:07:56 EET
OK, retaining P3. Is this a deterministic issue on Windows or still a
mandelbug?
Comment 7 Farsmo 2011-01-18 16:21:42 EET
I think "QThread: Destroyed while thread is still running" happened every time
I ran it.

The exception that usually follows:
- happens most of the time (but not always) on a multi-core CPU
- never happened to me when restricting the process affinity to 1 core

And the continuously reopening window bug happens a fraction of the times when
the exception happens, but never happens when no exception occurs.
Comment 8 Matti Airas 2011-01-19 06:22:53 EET
I also get the QThread error message, but that's not the segfault described in
the original bug report. Re-resolving fixed.

Farsmo, reopening bugs is very disruptive for our internal workflow. Please do
that only if you are absolutely certain that it's the same issue as reported in
the original bug (identical symptoms).
Comment 9 Matti Airas 2011-01-19 06:23:10 EET
And closing.
Comment 10 Hugo Parente Lima 2011-01-19 11:37:28 EET
This QThread warning message happens even on the C++ version of the example.
Comment 11 Farsmo 2011-01-19 13:47:19 EET
On my system I don't have any QThread problem with the C++ version, with MinGW
and Visual Studio (I didn't recompile the VS example with the 'console' flag: I
used the precompiled binary and set QT_FATAL_WARNINGS, but it exited with no
error).

I also forgot to mention that when windows continuously reopen, the program
ends up crashing spontaneously after reopening the window 5-10 times, which is
why I was reopening a crash bug.

Of course the QThread issue is likely to be relevant to the crashes:
"Deleting a running QThread (i.e. isFinished() returns false) will probably
result in a program crash."


Matti: sorry, I had no idea it could be a disruption; I was thinking that
opening a new bug that would end up a duplicate of an old bug would be more
disruptive than reopening the old bug.

But I still get the same symptoms as bug 522, which you marked as a duplicate
of this one (although I did not elaborate on whether the bug happened every
time). Should I instead reopen bug 522? Should I open a new bug? Or should I
continue discussion in a closed bug, so you can decide what to do?
Comment 12 Matti Airas 2011-01-19 14:11:58 EET
Farsmo, I reopened 522 because apparently it shouldn't have been marked
duplicate of this one (the symptoms are different).

As for the disruption issue, of course if some issue is exactly the same as
described in some previous bug, the bug should be reopened. However, if it's
only slightly similar, it's better to open a new one. Due to the way we handle
bug reports in our sprints, reopening bugs requires us to fiddle with backlogs
of completed sprints, while new ones which turn out to be duplicates are fast
and easy to take care of.

In this case, you did of course the right thing to reopen the bug (because the
exact issue you described in bug 522 hasn't been resolved, and I had mistakenly
marked 522 as a duplicate of this bug). My bad, sorry about that.