Closed Bug 551448 Opened 16 years ago Closed 16 years ago

crash [@ FireOrClearDelayedEvents]

Categories

(Core :: DOM: Events, defect)

Product:
Core
Component:
DOM: Events
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: stransky, Unassigned)

References

Details

(Keywords: crash)

Crash Data

Crash at FireOrClearDelayedEvents(nsTArray<nsCOMPtr<nsIDocument> >& aDocuments, PRBool aFireEvents) 7574 static void 7575 FireOrClearDelayedEvents(nsTArray<nsCOMPtr<nsIDocument> >& aDocuments, 7576 PRBool aFireEvents) 7577 { 7578 nsIFocusManager* fm = nsFocusManager::GetFocusManager(); 7579 if (!fm) 7580 return; 7581 7582 for (PRUint32 i = 0; i < aDocuments.Length(); ++i) { 7583 if (!aDocuments[i]->EventHandlingSuppressed()) { <<<<< here 7584 fm->FireDelayedEvents(aDocuments[i]); 7585 nsCOMPtr<nsIPresShell> shell = aDocuments[i]->GetPrimaryShell(); 7586 if (shell) { 7587 shell->FireOrClearDelayedEvents(aFireEvents); 7588 } 7589 } 7590 } 7591 } looks like the aDocuments[i] is NULL (gdb) p i $3 = 1 (gdb) p aDocuments[i] $2 = (nsCOMPtr<nsIDocument> &) @0xa8fbad4c: {mRawPtr = 0x0} (gdb) p* aDocuments.mHdr $6 = {mLength = 3, mCapacity = 4, mIsAutoArray = 0} (gdb) do #0 0x01279de2 in nsIDocument::EventHandlingSuppressed (this=0x0) at ../../dist/include/nsIDocument.h:1191 1191 PRUint32 EventHandlingSuppressed() const { return mEventsSuppressed; }
From reporter: I have managed to reproduce the bug by repeatedly reloading the following Tumblr blog with Disqus comments, i.e. pressing Ctrl+R before the previous reload has finished. http://clearsimplewrong.tumblr.com/post/402481875/my-thoughts-about-brian-carpers-rpg-post#disqus_thread
See Also: → https://bugzilla.redhat.com/show_bug.cgi?id=567123
Not sure if the NULL check is the propper fix here...
A bit longer stack trace would be great.
And what are the steps to reproduce?
Oh, and which version of Firefox? Based on redhat report I assume the old 3.5.x
Fully reproducible with latest trunk. Reproduction steps: 1) Load http://clearsimplewrong.tumblr.com/post/402481875/my-thoughts-about-brian-carpers-rpg-post#disqus_thread 2) Reload the page sometimes. It helps if you have open some other browser tabs/windows with some content. The stacktrace is unfortunately pretty short - it crashes just in main even loop, see https://bugzilla.redhat.com/attachment.cgi?id=395382
BTW. original Red Hat report is based on optimized 3.5.x build. This report is based on my trunk debug build.
Haven't managed to reproduce on trunk/64-bit linux
Severity: normal → critical
Keywords: crash
I just managed to reproduce it with official 3.6/i386 mozilla build on Fedora12/x68_64, submitted report ID 578f4816-4b9f-dc14-263ee142-76ccdc9f. I leaved the page loaded for some time and reloaded it after that. But it's pretty tricky to catch it, happens once in five/ten minutes.
This could be related: ###!!! ASSERTION: aRequest should be pending!: 'mRequests.IndexOf(aRequest) >= 0 || mAsyncRequests.IndexOf(aRequest) >= 0 || mPreloads.Contains(aRequest, PreloadRequestComparator())', file nsScriptLoader.cpp, line 1071 [...] WARNING: NS_ENSURE_SUCCESS(rv, 0) failed with result 0x8000FFFF: file nsContentUtils.cpp, line 2806 [...] ###!!! ASSERTION: You can't dereference a NULL nsCOMPtr with operator->().: 'mRawPtr != 0', file ../../../dist/include/nsCOMPtr.h, line 796
backtrace from trunk: (gdb) bt #0 0x00f7fde2 in nsIDocument::EventHandlingSuppressed (this=0x0) at ../../dist/include/nsIDocument.h:1191 #1 0x01254259 in FireOrClearDelayedEvents (aDocuments=..., aFireEvents=1) at nsDocument.cpp:7583 #2 0x01257514 in nsDelayedEventDispatcher::Run (this=0xa4d4c410) at nsDocument.cpp:7674 #3 0x01e4a98c in nsThread::ProcessNextEvent (this=0xb7d7f970, mayWait=0, result=0xbfffe8bc) at nsThread.cpp:527 #4 0x01de6819 in NS_ProcessNextEvent_P (thread=0xb7d7f970, mayWait=0) at nsThreadUtils.cpp:250 #5 0x01d51612 in mozilla::ipc::MessagePump::Run (this=0xb7dcf970, aDelegate=0xb7d21600) at MessagePump.cpp:118 #6 0x01eb654b in MessageLoop::RunInternal (this=0xb7d21600) at ./src/base/message_loop.cc:216 #7 0x01eb64c7 in MessageLoop::RunHandler (this=0xb7d21600) at ./src/base/message_loop.cc:199 #8 0x01eb644b in MessageLoop::Run (this=0xb7d21600) at ./src/base/message_loop.cc:173 #9 0x01c4a800 in nsBaseAppShell::Run (this=0xb4216f10) at nsBaseAppShell.cpp:174 #10 0x019f07a9 in nsAppStartup::Run (this=0xb3fead90) at nsAppStartup.cpp:182 #11 0x00c189aa in XRE_main (argc=1, argv=0xbfffefe4, aAppData=0xb7d16380) at nsAppRunner.cpp:3548 #12 0x08049817 in main (argc=1, argv=0xbfffefe4) at nsBrowserApp.cpp:158
Note - I've managed to reproduce it only with i386 builds so far.
Ah, I may need to try out on my 32bit linux.
Any news here?
If I just could reproduce this...
Yep, from my debug: 1) all events are set correctly in nsDelayedEventDispatcher(), mDocuments.Length() = 3, mDocuments[0], mDocuments[1], mDocuments[2] are set ok. 2) event loop is entered 3) in FireOrClearDelayedEvents(), aDocuments[1] is null, aDocuments[0] and aDocuments[2] are correct. I'm going to investigate it more this week.
I've managed to catch it with HW watchpoint, latest trunk, debug build: ******************* nsDelayedEventDispatcher start mDocuments.Length() = 3, (0xb1deeac8)mDocuments[0] = 0xa89da400 mDocuments.Length() = 3, (0xb1deeacc)mDocuments[1] = 0xaa30a000 mDocuments.Length() = 3, (0xb1deead0)mDocuments[2] = 0xa89dac00 ******************* nsDelayedEventDispatcher end Hardware watchpoint 29: *(int *)0xb1deeacc Old value = -1439653888 New value = 0 nsNonOwningRunnableMethod<nsContentSink, void>::Revoke (this=0xb1deeac0) at ../../../dist/include/nsThreadUtils.h:365 (gdb) bt #0 nsNonOwningRunnableMethod<nsContentSink, void>::Revoke (this=0xb1deeac0) at ../../../dist/include/nsThreadUtils.h:365 #1 0x0134f2dc in nsRevocableEventPtr<nsNonOwningRunnableMethod<nsContentSink, void> >::Revoke (this=0xa89e20b0) at ../../../dist/include/nsThreadUtils.h:462 #2 0x0134e5c5 in nsContentSink::WillBuildModelImpl (this=0xa89e2000) at nsContentSink.cpp:1722 #3 0x01508601 in HTMLContentSink::WillBuildModel (this=0xa89e2000, aDTDMode=eDTDMode_full_standards) at nsHTMLContentSink.cpp:1724 #4 0x01001f5e in nsParser::WillBuildModel (this=0xb1d4ef80, aFilename=...) at nsParser.cpp:1561 #5 0x01003a8a in nsParser::ResumeParse (this=0xb1d4ef80, allowIteration=1, aIsFinalChunk=0, aCanInterrupt=1) at nsParser.cpp:2298 #6 0x010056bb in nsParser::OnDataAvailable (this=0xb1d4ef80, request=0xb1143f90, aContext=0x0, pIStream=0xb1fda490, sourceOffset=0, aLength=14249) at nsParser.cpp:2955 #7 0x01a80947 in nsDocumentOpenInfo::OnDataAvailable (this=0xb3f81640, request=0xb1143f90, aCtxt=0x0, inStr=0xb1fda490, sourceOffset=0, count=14249) at nsURILoader.cpp:306 #8 0x00ece290 in nsHTTPCompressConv::do_OnDataAvailable (this=0xaa3863a0, request=0xb1143f90, context=0x0, offset=0, buffer= 0xb1203000 "<!DOCTYPE html PUBLIC \"-//W3C//DTD XHTML 1.0 Strict//EN\"\r\n\t\"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd\">\r\n<html xmlns=\"http://www.w3.org/1999/xhtml\" xml:lang=\"en\" lang=\"en\">\r\n<head>\r\n\t<meta htt"..., count= 14249) at nsHTTPCompressConv.cpp:375 #9 0x00ece01c in nsHTTPCompressConv::OnDataAvailable (this=0xaa3863a0, request=0xb1143f90, aContext=0x0, iStr=0xb12d5360, aSourceOffset=0, aCount=5137) at nsHTTPCompressConv.cpp:306 #10 0x00eacca8 in nsStreamListenerTee::OnDataAvailable (this=0xb12d5340, request=0xb1143f90, context=0x0, input=0xb1a9d6ac, offset=0, count=5137) at nsStreamListenerTee.cpp:111 #11 0x00f55b16 in nsHttpChannel::OnDataAvailable (this=0xb1143f60, request=0xb1d26fa0, ctxt=0x0, input=0xb1a9d6ac, offset=0, count=5137) at nsHttpChannel.cpp:5383 #12 0x00e7c12a in nsInputStreamPump::OnStateTransfer (this=0xb1d26fa0) at nsInputStreamPump.cpp:508 #13 0x00e7bc81 in nsInputStreamPump::OnInputStreamReady (this=0xb1d26fa0, stream=0xb1a9d6ac) at nsInputStreamPump.cpp:398 #14 0x01f6965e in nsInputStreamReadyEvent::Run (this=0xb1dee8c0) at nsStreamUtils.cpp:112 #15 0x01f91edc in nsThread::ProcessNextEvent (this=0xb7d82970, mayWait=1, result=0xbfffe99c) at nsThread.cpp:527 #16 0x01f2dd69 in NS_ProcessNextEvent_P (thread=0xb7d82970, mayWait=1) at nsThreadUtils.cpp:250 #17 0x01e98c73 in mozilla::ipc::MessagePump::Run (this=0xb7dcf9a0, aDelegate=0xb7d24600) at MessagePump.cpp:142 #18 0x01ffda9b in MessageLoop::RunInternal (this=0xb7d24600) at ./src/base/message_loop.cc:216 #19 0x01ffda17 in MessageLoop::RunHandler (this=0xb7d24600) at ./src/base/message_loop.cc:199 #20 0x01ffd99b in MessageLoop::Run (this=0xb7d24600) at ./src/base/message_loop.cc:173 #21 0x01d91d50 in nsBaseAppShell::Run (this=0xb3ec9380) at nsBaseAppShell.cpp:174 #22 0x01b37cf9 in nsAppStartup::Run (this=0xb3b63280) at nsAppStartup.cpp:182 #23 0x00d5f9aa in XRE_main (argc=1, argv=0xbffff0c4, aAppData=0xb7d16380) at nsAppRunner.cpp:3548 #24 0x08049817 in main (argc=1, argv=0xbffff0c4) at nsBrowserApp.cpp:158
Hm, unable to reproduce with latest trunk but fully reproducible with FIREFOX_3_7a2_RELEASE
Can't reproduce with latest trunk & 3.6.4 build 4.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → WORKSFORME
Crash Signature: [@ FireOrClearDelayedEvents]
You need to log in before you can comment on or make changes to this bug.