Don't crash on exit

Review Request #101027 - Created April 5, 2011 and submitted

Information
José Manuel Santamaría Lema
rekonq
0.7-branch
269490
Reviewers
rekonq
Hi,

I'm not 100% sure but I tend to think you must not set a QApplication as the parent of a BookmarkProvider.

I think the problem is that any BookmarkProvider has QWidgets in its tree of QObjects. Therefore, you will get problems when deleting the children because of this:
http://bugreports.qt.nokia.com/browse/QTBUG-16974

So I just deleted some objects in Application::~Application in order to make sure these objects are deleted before the QApplication. Just deleting the BookmarkProvider in Application::~Application would be enough to fix the crash here, but I'm deleting the other objects ...
1 ... because if now or in the future these objects had a QWidget in its object tree I think you might get a crash.
2 ... just in case.

By the way, I think the bug mentioned in this request was introduced in this commit 2b4efa406780920631af1166e79d54e54092322a

I have push permissions, if you give me the ok I will push this patch to 0.7-branch.
I have built rekonq with the patch; problem solved for me.
Andrea Diamantini
Josè, 
many thanks for your patch and for the interesting Qt-BUG pointed out! I'll ask my Qt-devs around and try to merge your patch in a while. Anyway, I'd like to understand why this bug occurs just in a few systems. Any ideas about?
  1. > I'd like to understand why this bug occurs just in a few systems. Any ideas about?
    
    Yes. C&P from http://doc.trolltech.com/4.7/objecttrees.html#construction-destruction-order-of-qobjects
    
    > When QObjects are created on the heap (i.e., created with new), a tree can be constructed from them in any order, and later, the objects in the tree can be destroyed in any order.
    
    My conjecture is: 
    
    The problem is that in my system some QWidget is deleted after the QApplication, triggering the Qt bug/feature #16974. However, since the objects in the tree can be destroyed in any order, I think it's reasonable to guess that in different systems the the deletion order may be different, thus you may or may not get the crash. Hence why I am deleting various objects in Application::~Application and not just the BookmarkProvider instance; I hope this would save you from headaches now and/or in the future, because (with a bit of bad luck) this may happen:
    
    1. You add a QWidget to the object tree of ... let's say m_sessionManager (if you aren't doing it already).
    2. The program works perfectly for you.
    3. Some of your users get the crash and you can't reproduce it.
    
    Just in case you want a system where you could reproduce the crash: I reproduced the bug in Debian sid with this semi-official repo http://qt-kde.debian.net/
    I could reproduce under the circumstances explained here https://bugs.kde.org/show_bug.cgi?id=269490#c3 both in a virtualbox machine used to test our debian packages and in my main desktop.
  2. P.S. Sorry for the late reply, I've just realized that I didn't pushed the "Publish" button for the above comment. Also, thanks for commiting and just for the record I've been using the browser with the patch and I never got the crash again.
Commit Hook
This review has been submitted with commit a957e857480a55b02e04ddff8e84b968462804f9 by Andrea Diamantini.
Commit Hook
This review has been submitted with commit f4484b037aec7484507aecfa7fb93482a7db7dc8 by Andrea Diamantini.
Loading...