[opensuse-kde] eric 4 crash on exit with KDE4 from K:K:S:D on 11.1
Hi,
I suffer from a 100% reproducible crash on eric shutdown. All it takes is
running eric, load a file, split the view "New view (with new split)" via
context menu, and quit.
Since neither Phil Thompson nor Detlev Offenbach is able to reproduce
this, it's probably due to the Qt/KDE integration.
The offending line is this:
painting/qwindowsurface_x11.cpp:84
84 XFreeGC(X11->display, gc);
I guess, it's X11 being NULL at that time. For PyQt, it's nearly impossible
to control the order of d'tors during tear down due to the Python garbage
collector behavior. Would it be enough to check for X11 != NULL at this
point?
Would such a check be accepted from openSUSE Qt4 maintainers, if it's
successfully avoiding this crash? Could other reasons influence this
behavior?
My environment: openSUSE 11.1 (all packages from build service)
qscintilla-2.4
qt4-4.5.3
python-sip-4.10
python-qt4-4.7
eric-4.4.1
TIA,
Pete
Application: eric4 (eric4.py), signal: Segmentation fault
[Current thread is 1 (Thread 0xb74276c0 (LWP 25102))]
Thread 2 (Thread 0xafdffb90 (LWP 25121)):
#0 0xb6c5cebc in operator delete (ptr=0xad228430) at ../../../../libstdc++-v3/libsupc++/del_op.cc:49
#1 0xb56eac6d in QList
On Tuesday 23 of February 2010, Hans-Peter Jansen wrote:
Hi,
I suffer from a 100% reproducible crash on eric shutdown. All it takes is running eric, load a file, split the view "New view (with new split)" via context menu, and quit.
Since neither Phil Thompson nor Detlev Offenbach is able to reproduce this, it's probably due to the Qt/KDE integration.
The offending line is this: painting/qwindowsurface_x11.cpp:84 84 XFreeGC(X11->display, gc);
I guess, it's X11 being NULL at that time. For PyQt, it's nearly impossible to control the order of d'tors during tear down due to the Python garbage collector behavior. Would it be enough to check for X11 != NULL at this point?
Not really, I expect it would crash exactly the same way in some other place. QWidget really shouldn't be deleted when the application object's already gone.
Would such a check be accepted from openSUSE Qt4 maintainers, if it's successfully avoiding this crash? Could other reasons influence this behavior?
Fixes for Qt should be preferably discussed with upstream, but here I think you rather need to talk to the bindings developers. I have no experience with bindings for KDE/Qt, but I consider this to be a major flaw. IMO an object simply should not be destroyed after the QApplication cleanup, as I simply don't consider it to be feasible to handle that gracefully. If Python itself can't handle this, then the bindings should do that somehow. -- Lubos Lunak openSUSE Boosters team, KDE developer l.lunak@suse.cz , l.lunak@kde.org -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
On Thursday 25 February 2010, 16:06:29 Lubos Lunak wrote:
On Tuesday 23 of February 2010, Hans-Peter Jansen wrote:
Hi,
I suffer from a 100% reproducible crash on eric shutdown. All it takes is running eric, load a file, split the view "New view (with new split)" via context menu, and quit.
Since neither Phil Thompson nor Detlev Offenbach is able to reproduce this, it's probably due to the Qt/KDE integration.
The offending line is this: painting/qwindowsurface_x11.cpp:84 84 XFreeGC(X11->display, gc);
I guess, it's X11 being NULL at that time. For PyQt, it's nearly impossible to control the order of d'tors during tear down due to the Python garbage collector behavior. Would it be enough to check for X11 != NULL at this point?
Not really, I expect it would crash exactly the same way in some other place. QWidget really shouldn't be deleted when the application object's already gone.
Would such a check be accepted from openSUSE Qt4 maintainers, if it's successfully avoiding this crash? Could other reasons influence this behavior?
Fixes for Qt should be preferably discussed with upstream, but here I think you rather need to talk to the bindings developers. I have no experience with bindings for KDE/Qt, but I consider this to be a major flaw. IMO an object simply should not be destroyed after the QApplication cleanup, as I simply don't consider it to be feasible to handle that gracefully. If Python itself can't handle this, then the bindings should do that somehow.
Of course, you are right, but due to the dynamic nature of python, that's going to be hard to get by, even more obscured by the fact, that both developers aren't able to reproduce the problem. The more I thing about it, the more I find my idea to tackle the issue in Qt stupid. Sorry for the churn. I'm going to try to fix this issue in eric (by calling certain d'tors manually), and hope, that at the point, where PySide (the Nokia sponsored approach to Qt python bindings) is going to have similar issues. Thanks, Lubos. Cheers, Pete
-- Lubos Lunak openSUSE Boosters team, KDE developer ^^^^^^^^^^^^^^^^^^^^^^ Now that's sounding pretty cool. On what fuel your are driven?
l.lunak@suse.cz , l.lunak@kde.org
-- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
participants (2)
-
Hans-Peter Jansen -
Lubos Lunak