Closed Bug 1081686 Opened 5 years ago Closed 5 years ago

Constant crashes on lichess.org after 20141011 Nightly [@ mozilla::dom::WebSocket::ReadyState() ]

Categories

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

35 Branch
x86_64
All
defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla36
Tracking Status
firefox34 --- unaffected
firefox35 + fixed
firefox36 --- fixed

People

(Reporter: dario.gjorgjevski, Assigned: baku)

References

()

Details

(Keywords: assertion, crash, reproducible)

Crash Data

Attachments

(2 files)

User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:35.0) Gecko/20100101 Firefox/35.0
Build ID: 20141012030203

Steps to reproduce:

1) Go to http://en.lichess.org/
2) Click `Play with the machine' (or any other means of playing a chess game)
3) Start the game


Actual results:

Nightly (both 2014-10-11 and 2014-10-12) crashes.


Expected results:

The chess game should be playable as it was with the 2014-10-10 and previous Nightlies.
Regression range:
good=2014-10-10
bad=2014-10-11
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=50b689feab5f&tochange=f74ad36bb97b

CR:
https://crash-stats.mozilla.com/report/index/7541a765-c2a7-41d7-8e12-429522141012

It crashes in  [@ mozilla::OffTheBooksMutex::Lock() ] which is bug 1067348 but I guess it masks the real crash signature (different regression ranges).
Severity: normal → critical
Status: UNCONFIRMED → NEW
Depends on: 1067348
Ever confirmed: true
Keywords: crash, reproducible
Attached file crash stack
In a local debug build on Linux64:
Assertion failure: mImpl, at content/base/src/WebSocket.cpp:2152
Component: General → Networking: WebSockets
Keywords: assertion
OS: Windows 8.1 → All
Looks like a regression from bug 504553?

What prevents a WebSocket still being visible from script after WebSocketImpl::Disconnect happens, exactly?
Blocks: 504553
Flags: needinfo?(amarchesini)
I'm not sure which browser tab happens to be the triggering cause (likely either Feedly or Washington Post, I could imagine either of them doing this), but nightly builds are unusable for me with this in place -- I crash a matter of minutes every time.

Particularly given we're cutting a branch Real Soon Now, could we back out those patches and reland with this issue fixed?
Summary: Website (lichess.org) constantly crashes after recent Nightly (2014-10-11) → Constant crashes on lichess.org after 20141011 Nightly [@ mozilla::dom::WebSocket::ReadyState() ]
Duplicate of this bug: 1081775
Another Website using the new feature that doesn't work, yet:
www.runescape.com/game?html5=true

It just keeps on loading, so I guess that there might be some issues left still.

Could also be that the reason for this is, that Runescape got mostly optimized for Chrome, since Websockets in Webworkers were missing in the past, so that they couldn't test it with FF.
Might be the case though that the reason is that Firefox blocks Cross-Origin requests.
(took a quick look at the console that revealed this error)
Assignee: nobody → amarchesini
Flags: needinfo?(amarchesini)
Attached patch crash.patchSplinter Review
Attachment #8504036 - Flags: review?(bugs)
Attachment #8504036 - Flags: review?(bugs) → review+
Crash Signature: [@ mozilla::dom::WebSocket::ReadyState()] [@ mozilla::dom::WebSocket::ReadyState() const ] [@ mozilla::dom::WebSocketImpl::Close(mozilla::dom::Optional<unsigned short> const&, mozilla::dom::Optional<nsAString_internal> const&, mozilla::ErrorResult&) ]
My fault. WebSocket tests has to be disabled for android and b2g.

https://hg.mozilla.org/integration/mozilla-inbound/rev/91b1a62d1012
I reproduced this on an OpenStack/Nova Console page (leaving the Console page).
Crash Signature: [@ mozilla::dom::WebSocket::ReadyState()] [@ mozilla::dom::WebSocket::ReadyState() const ] [@ mozilla::dom::WebSocketImpl::Close(mozilla::dom::Optional<unsigned short> const&, mozilla::dom::Optional<nsAString_internal> const&, mozilla::ErrorResult&) ] → [@ mozilla::dom::WebSocket::ReadyState()] [@ mozilla::dom::WebSocket::ReadyState() const ] [@ mozilla::dom::WebSocketImpl::ReadyState() ] [@ mozilla::dom::WebSocketImpl::Close(mozilla::dom::Optional<unsigned short> const&, mozilla::dom::Optional<nsAStr…
Duplicate of this bug: 1082845
https://hg.mozilla.org/mozilla-central/rev/91b1a62d1012
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla36
could you pls set the target milestone to 35?
I mean Websockets in Webworkers was introduced in that nightly version, now it's aurora so I guess it makes sense to fix it in the version it was introduced in and not later (we would introduce an unnecessary bug in the release which is there for one month)
Andrea, could you fill the uplift request for aurora (35) asap? This bug is blocking the aurora updates. Thanks
Flags: needinfo?(amarchesini)
Duplicate of this bug: 1082866
Comment on attachment 8504036 [details] [diff] [review]
crash.patch

Approval Request Comment
[Feature/regressing bug #]: bug 504553
[User impact if declined]: firefox crashes if WebSocket object is used when disconnected.
[Describe test coverage new/current, TBPL]: tbpl. fully green with additional mochitests. 
[String/UUID change made/needed]: none
Attachment #8504036 - Flags: approval-mozilla-aurora?
Flags: needinfo?(amarchesini)
Attachment #8504036 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
> could you pls set the target milestone to 35?

Target milestone on fixed bugs is the version of m-c when the bug was fixed.  Backports (like in 35 in this case) are tracked via the release flags.
Flags: qe-verify-
Flags: in-testsuite+
You need to log in before you can comment on or make changes to this bug.