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

Status: VERIFIED FIXED

(Core :: Networking: WebSockets, defect)

Description

[Marcia Knous [:marcia]]

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

Comment 1

[Patrick McManus [:mcmanus]]

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?

Comment 2

[Patrick McManus [:mcmanus]]

Attachment: preloaded asyncwait null v1

canceling asyncwait on a nsPreloadedStream with data still buffered could deref nsnull

Comment 3

[Josh Matthews [:jdm]]

Yeah, timer creation failure is typically a shutdown thing.

Comment 4

[Jason Duell]

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.

Comment 5

[Marcia Knous [:marcia]]

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 6

[Christian :Biesinger (don't email me, ping me on IRC)]

Comment on attachment 541754 [details] [diff] [review]
preloaded asyncwait null v1

Why not put this check before the if (!mLen)?

Comment 7

[Christian :Biesinger (don't email me, ping me on IRC)]

Comment on attachment 541754 [details] [diff] [review]
preloaded asyncwait null v1

er, nevermind, this code is correct as it is.

Comment 8

[Patrick McManus [:mcmanus]]

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.

Comment 9

[Mounir Lamouri (:mounir)]

Pushed:
http://hg.mozilla.org/mozilla-central/rev/436d9fd4db12

Comment 10

[Patrick McManus [:mcmanus]]

http://hg.mozilla.org/releases/mozilla-aurora/rev/866ac43c5b8b

Comment 11

[Virgil Dicu [:virgil] [QA]]

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?

Comment 12

[Patrick McManus [:mcmanus]]

(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.

Comment 13

[u279076]

qa- as no QA verification needed (check crashstats if you want to mark verified)

Comment 14

[Marcia Knous [:marcia]]

No crashes are showing up in crash stats over a 4 week period, so marking this verified fixed based on that fact.