Closed Bug 666997 Opened 9 years ago Closed 9 years ago

Firefox Crash @ mozilla::net::nsPreloadedStream::AsyncWait(nsIInputStreamCallback*

Categories

(Core :: Networking: WebSockets, defect, critical)

x86
Windows 7
defect
Not set
critical

Tracking

()

VERIFIED FIXED
mozilla7
Tracking Status
firefox6 --- fixed
firefox7 --- fixed

People

(Reporter: marcia, Assigned: mcmanus)

Details

(Keywords: crash, Whiteboard: [qa-])

Crash Data

Attachments

(1 file)

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.
Whiteboard: [inbound]
Pushed:
http://hg.mozilla.org/mozilla-central/rev/436d9fd4db12
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Flags: in-testsuite?
Resolution: --- → FIXED
Whiteboard: [inbound]
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)
Whiteboard: [qa-]
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.