The default bug view has changed. See this FAQ.

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

VERIFIED FIXED in Firefox 6

Status

()

Core
Networking: WebSockets
--
critical
VERIFIED FIXED
6 years ago
6 years ago

People

(Reporter: marcia, Assigned: mcmanus)

Tracking

({crash})

Trunk
mozilla7
x86
Windows 7
crash
Points:
---
Bug Flags:
in-testsuite ?

Firefox Tracking Flags

(firefox6 fixed, firefox7 fixed)

Details

(Whiteboard: [qa-], crash signature)

Attachments

(1 attachment)

(Reporter)

Description

6 years ago
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
(Assignee)

Comment 1

6 years ago
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?
(Assignee)

Comment 2

6 years ago
Created attachment 541754 [details] [diff] [review]
preloaded asyncwait null v1

canceling asyncwait on a nsPreloadedStream with data still buffered could deref nsnull
Assignee: nobody → mcmanus
Status: NEW → ASSIGNED
Attachment #541754 - Flags: review?(cbiesinger)

Comment 3

6 years ago
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+
(Reporter)

Comment 5

6 years ago
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.
(Assignee)

Comment 8

6 years ago
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-firefox6: --- → affected
status-firefox7: --- → affected
Whiteboard: [inbound]
Pushed:
http://hg.mozilla.org/mozilla-central/rev/436d9fd4db12
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Flags: in-testsuite?
Resolution: --- → FIXED
Whiteboard: [inbound]
Target Milestone: --- → mozilla7
(Assignee)

Updated

6 years ago
Attachment #541754 - Flags: approval-mozilla-aurora?

Updated

6 years ago
Attachment #541754 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
(Assignee)

Comment 10

6 years ago
http://hg.mozilla.org/releases/mozilla-aurora/rev/866ac43c5b8b
status-firefox6: affected → fixed
status-firefox7: affected → fixed
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?
(Assignee)

Comment 12

6 years ago
(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-]
(Reporter)

Comment 14

6 years ago
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.