Closed Bug 666997 Opened 9 years ago Closed 9 years ago
Firefox Crash @ mozilla::net::ns
Preloaded Stream::Async Wait(ns IInput Stream Callback*
Seen while reviewing crash stats. Small volume Windows only crash which is only seen on the trunk: https://crash-stats.mozilla.com/report/list?signature=mozilla::net::nsPreloadedStream::AsyncWait%28nsIInputStreamCallback*,%20unsigned%20int,%20unsigned%20int,%20nsIEventTarget*%29. Crashes started showing up using the 2011062200 build. Possible pushlog regression range: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=a285146675dc&tochange=b7a93f1279b7. There was a merge during this time. https://crash-stats.mozilla.com/report/index/cb1151a3-6494-4778-bc06-f22482110624 Frame Module Signature [Expand] Source 0 xul.dll mozilla::net::nsPreloadedStream::AsyncWait netwerk/base/src/nsPreloadedStream.cpp:176 1 xul.dll mozilla::net::nsWebSocketHandler::CleanupConnection netwerk/protocol/websocket/nsWebSocketHandler.cpp:1323 2 xul.dll mozilla::net::nsWebSocketHandler::StopSession netwerk/protocol/websocket/nsWebSocketHandler.cpp:1413 3 xul.dll mozilla::net::nsWebSocketHandler::PrimeNewOutgoingMessage netwerk/protocol/websocket/nsWebSocketHandler.cpp:1173
I have a fix for this in a differnet bug, which I didn't think could happen on the trunk. This stack means do_CreateInstance("@mozilla.org/timer;1", &rv) failed. Maybe at shutdown time?
canceling asyncwait on a nsPreloadedStream with data still buffered could deref nsnull
Assignee: nobody → mcmanus
Status: NEW → ASSIGNED
Attachment #541754 - Flags: review?(cbiesinger)
Yeah, timer creation failure is typically a shutdown thing.
Comment on attachment 541754 [details] [diff] [review] preloaded asyncwait null v1 Is this bug on aurora too? If so seems worth fixing there--simple one-line fix.
Attachment #541754 - Flags: review?(cbiesinger) → review+
According to crash stats, that signature is not showing up in Aurora crash stats, only trunk. But even on trunk there is very few crashes. (In reply to comment #4) > Comment on attachment 541754 [details] [diff] [review] [review] > preloaded asyncwait null v1 > > Is this bug on aurora too? If so seems worth fixing there--simple one-line > fix.
Comment on attachment 541754 [details] [diff] [review] preloaded asyncwait null v1 Why not put this check before the if (!mLen)?
Attachment #541754 - Flags: review+
Comment on attachment 541754 [details] [diff] [review] preloaded asyncwait null v1 er, nevermind, this code is correct as it is.
the bug is on aurora - probably not seeing it there because nobody is running a website (yet) with the prefixed js api. will nom for aurora after it lands on m-c.
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla7
Attachment #541754 - Flags: approval-mozilla-aurora?
Attachment #541754 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Mozilla/5.0 (X11; Linux x86_64; rv:7.0) Gecko/20100101 Firefox/7.0 Is this issue fixed? Or are there any steps to follow in order to verify it in QA?
(In reply to Virgil Dicu from comment #11) > Mozilla/5.0 (X11; Linux x86_64; rv:7.0) Gecko/20100101 Firefox/7.0 > > Is this issue fixed? Status == FIXED. > Or are there any steps to follow in order to verify it > in QA? No known STR, fixed by inspection from the crash report.
qa- as no QA verification needed (check crashstats if you want to mark verified)
No crashes are showing up in crash stats over a 4 week period, so marking this verified fixed based on that fact.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.