Summary: | [Qt] crash in debug mode just before exit | ||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Balazs Kelemen <kbalazs> | ||||||||||||
Component: | WebKit Qt | Assignee: | Nobody <webkit-unassigned> | ||||||||||||
Status: | CLOSED FIXED | ||||||||||||||
Severity: | Normal | CC: | agbakken, commit-queue, hausmann, kenneth, koivisto, koshuin, laszlo.gombos, yael | ||||||||||||
Priority: | P2 | ||||||||||||||
Version: | 528+ (Nightly build) | ||||||||||||||
Hardware: | PC | ||||||||||||||
OS: | Linux | ||||||||||||||
Bug Depends on: | |||||||||||||||
Bug Blocks: | 35784 | ||||||||||||||
Attachments: |
|
Description
Balazs Kelemen
2010-03-30 09:32:36 PDT
Created attachment 52048 [details]
backtrace
Created attachment 52049 [details]
proposed patch
Comment on attachment 52049 [details]
proposed patch
Why don't we save off the thread id of the main thread in a global static instead? I would look at other implementations including the posix threading implementation before making this change.
Comment on attachment 52049 [details]
proposed patch
Why don't we save off the thread id of the main thread in a global static instead? I would look at other implementations including the posix threading implementation before making this change.
Ok, what have I done is horribly overcomplicated, so I remove review flag and start to thinking about a more appropriate solution. Created attachment 52100 [details]
proposed patch
Comment on attachment 52100 [details]
proposed patch
I would suggest adding at least a comment.
Actually this will be the most straightforward: bool isMainThread() { static QThread* mainThread = QCoreApplication::instance()->thread(); return QThread::currentThread() == mainThread; } , but I am not sure that using a static is thread safe at all platforms. What do you think? Comment on attachment 52100 [details]
proposed patch
This is definitely better. Why do we need both mainThread and mainThreadIdentifier?
This seems like the same issue I was talking about on IRC and in https://bugs.webkit.org/show_bug.cgi?id=35251#c5. All you need to do to get this crash is load www.cnn.com and exit QtLauncher. The cause of the crash is that SharedTimerQt 's parent is QCoreApplication and I think this is wrong. (dll depends on the application that loaded it) (In reply to comment #10) > This seems like the same issue I was talking about on IRC and in > https://bugs.webkit.org/show_bug.cgi?id=35251#c5. > All you need to do to get this crash is load www.cnn.com and exit QtLauncher. > The cause of the crash is that SharedTimerQt 's parent is QCoreApplication and > I think this is wrong. (dll depends on the application that loaded it) As I understand the 2 bug are not related to each other. QCoreApplication is needed to be the parent of SharedTimerQt if we want to do final cleanup (not just memory deallocation, but flushing to disk, etc). Created attachment 52408 [details]
proposed patch (hopefully final)
So, let's trust in c++ (and all of it's implementation) and solve this with a static :)
(In reply to comment #11) > (In reply to comment #10) > As I understand the 2 bug are not related to each other. > QCoreApplication is needed to be the parent of SharedTimerQt if we want to do > final cleanup (not just memory deallocation, but flushing to disk, etc). The bugs are not related. Only comment #5 is. I fixed similar issue on Symbian builds few weeks back https://bugs.webkit.org/show_bug.cgi?id=34081 The patch is ok from my PoV if it is only the ASSERT that this gets away with. what worries me is this line: WebCore::JSDOMWindowBase::commonJSGlobalData () Reason why you are seeing this crash is TLS getting destroyed at main() exit and then getting reconstructed at the time of timer trigger. I remember we had same issue with Symbian builds at some point. My fix at then was to cancel all timers at d'tor instead of firing them (the right thing to do), but there was some reason why this wasn't accepted. Problem I think still exists in Symbian, but there is now no use-case that would bring it to surface. See also bug 37521 for an alternate solution. Created attachment 53678 [details]
proposed patch
Destruct the shared timer instance and firing all timers last time before ~QApplication,
as suggested by Yael and Zoltan (Zoltan did that in the other bug).
Comment on attachment 53678 [details]
proposed patch
Looks good to me, but why was the parent removed? You could add a comment about that in the ChangeLog. Also I would keeop the changelog lines shorter
I like this patch, too! :) (In reply to comment #17) > (From update of attachment 53678 [details]) > Looks good to me, but why was the parent removed? You could add a comment about > that in the ChangeLog. Also I would keeop the changelog lines shorter The connection achieves what the parent relationship tried to achieve earlier. But when the QApplication destructor ran it was too late. Comment on attachment 53678 [details] proposed patch Clearing flags on attachment: 53678 Committed r57818: <http://trac.webkit.org/changeset/57818> All reviewed patches have been landed. Closing bug. *** Bug 37521 has been marked as a duplicate of this bug. *** Revision r57818 cherry-picked into qtwebkit-2.0 with commit 95c4d11167cff1a8fd1e124e4655fedc0b00944a Revision r57818 cherry-picked into qtwebkit-4.6 with commit d6d6c3821ed111b214a753f1ce8fa969c1a94dc3 |