704004 - Firefox in “work offline” mode crashes when starting a Websocket

Status: VERIFIED FIXED

(Core :: Networking: WebSockets, defect)

Description

[Ivan Enderlin]

Attachment: Bug.html

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0a1) Gecko/20111117 Firefox/11.0a1
Build ID: 20111117030939

Steps to reproduce:

Turn off your connection (Ethernet, Wifi & co.). Turn Firefox to the “work offline” mode. Close Firefox. Open the attached file (which only starts a new Websocket) in a new Firefox instance (normally in the “work offline” mode).


Actual results:

Firefox crashes :-(.


Expected results:

Starting a new Websocket in the “work offline” mode should throw an exception or should call the Websocket.onclose event.

Comment 1

[Patrick McManus [:mcmanus]]

this is wfm on linux, though it isn't hard to imagine how it could be os dependent.

do you happen to have a stack trace?

Comment 2

[Josh Matthews [:jdm]]

I'm not reproducing on a local debug build from the 18th. Do you need to have a websocket server running?

Comment 3

[Paul Rouget [:paul]]

Can't reproduce (Linux here).

Comment 4

[Ivan Enderlin]

I targeted Mac OS X.

@Patrick: I don't have any stack trace :-/.
@Josh: Even if my Websocket is running, the bug appears. I tried with a build from the 19th.

Comment 5

[Josh Matthews [:jdm]]

Ivan, just to confirm two things: are you saying that there's no crash report listed in about:crashes? Also, comment 4 isn't clear to me - can you reproduce the crash _without_ a websocket server running?

Comment 6

[Ivan Enderlin]

@Josh: It could be one of theses crashes: https://crash-stats.mozilla.com/report/index/bp-3907a952-a21c-4659-9c9f-bf3d82111122.
No Websocket server is listening/running. I just have Firefox in “work offline” mode and my Bug.html file.

Comment 7

[Patrick McManus [:mcmanus]]

Thanks for the stack ivan!

I suspect this is probably caused by 664894, but I'm not certain.

you are exiting EstablishConnection early via a failed NS_ENSURE_SUCCESS path - probably asyncopen() given your network setup.

That causes the nsAutoCloseWS class to call CloseConnection(), which in turn deref's mWebsocketChannel which is null because you're still in CONNECTING state and haven't finished EstablishConnection.

The fix is just a null ptr check; I'll attach it shortly.

Comment 8

[Ivan Enderlin]

I have suspected something like this. Good to know you have a clue :-).

Comment 9

[Patrick McManus [:mcmanus]]

Attachment: patch 0

Comment 10

[Patrick McManus [:mcmanus]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/0cffc341bd5b

Comment 11

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/0cffc341bd5b

Comment 12

[Patrick McManus [:mcmanus]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/e6dc2e642824

Comment 13

[Vlad [QA]]

I have verified this bug using the steps from the description on:
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0) Gecko/20100101 Firefox/10.0 beta 2
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0) Gecko/20100101 Firefox/10.0 beta 2

and Firefox didn't crash.

Setting resolution to verified on Beta.

Comment 14

[Vlad [QA]]

I've verified this bug using the steps from the description and Firefox did not crash.

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20100101 Firefox/11.0 beta 4
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20100101 Firefox/11.0 beta 4

Setting resolution to Verified Fixed.