Closed Bug 1336529 Opened 8 years ago Closed 8 years ago

Crash in nsRefPtrHashtable<T>::Get | mozilla::dom::workers::ServiceWorkerManager::GetRegistration

Categories

(Core :: DOM: Service Workers, defect)

Product:
Core
Component:
DOM: Service Workers
Platform:
x86
Windows 7
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla54
Tracking Flags:
Tracking Status
firefox51 --- wontfix
firefox52 --- fixed
firefox53 --- fixed
firefox54 --- fixed

People

(Reporter: bkelly, Assigned: bkelly)

References

Details

(Keywords: crash)

Crash Data

Attachments

(1 file)

Handle ServiceWorkerInfo destruction while released KeepAliveToken. r=asuth
(deleted), patch
asuth
: review+
gchang
: approval-mozilla-aurora+
jcristau
: approval-mozilla-beta+
Details | Diff | Splinter Review
This bug was filed from the Socorro interface and is report bp-0f9e0613-c545-4c34-9eea-8111d2170203. ============================================================= This appears to be due to ServiceWorkerPrivate::NoteDeadServiceWorker() being called while we are trying to proxy release the KeepAliveToken. This leads to a possible nullptr mInfo being passed ServiceWorkerManager::WorkerIsIdle().
I believe this crash is due to a race where a service worker is unregistered or an old SW version is doomed at the same time a KeepAliveToken is being async released via a runnable. The ReleaseToken() method assumes mInfo is non-nullptr, but can be nullptr if the ServiceWorkerInfo is destroyed at the same time.
Attachment #8833431 - Flags: review?(bugmail)
Attachment #8833431 - Flags: review?(bugmail) → review+
Pushed by bkelly@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/7d9895066136 Handle ServiceWorkerInfo destruction while released KeepAliveToken. r=asuth
https://hg.mozilla.org/mozilla-central/rev/7d9895066136
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
status-firefox54: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla54
Looks like the one report I see with this signature came from 51.0.1, so I guess that means 52/53 are also affected? Assuming that's the case, please request approval when you get a chance :)
status-firefox51: --- → wontfix
status-firefox52: --- → affected
status-firefox53: --- → affected
Flags: needinfo?(bkelly)
Comment on attachment 8833431 [details] [diff] [review] Handle ServiceWorkerInfo destruction while released KeepAliveToken. r=asuth Approval Request Comment [Feature/Bug causing the regression]: Bug 1170543 [User impact if declined]: Low frequency crashes [Is this code covered by automated tests?]: Many tests, but they don't trigger this race [Has the fix been verified in Nightly?]: Its low frequency without exact STR, so can't verify. [Needs manual test from QE? If yes, steps to reproduce]: No [List of other uplifts needed for the feature/fix]: None [Is the change risky?]: Minimal risk [Why is the change risky/not risky?]: It just adds a nullptr check. [String changes made/needed]: None
Flags: needinfo?(bkelly)
Attachment #8833431 - Flags: approval-mozilla-beta?
Attachment #8833431 - Flags: approval-mozilla-aurora?
Blocks: 1170543
Comment on attachment 8833431 [details] [diff] [review] Handle ServiceWorkerInfo destruction while released KeepAliveToken. r=asuth Fix a crash. Aurora53+.
Attachment #8833431 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Comment on attachment 8833431 [details] [diff] [review] Handle ServiceWorkerInfo destruction while released KeepAliveToken. r=asuth service worker crash fix for beta52
Attachment #8833431 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Flags: qe-verify-
Iteration: --- → 54.1 - Feb 6
Whiteboard: [e10s-multi:+]
Iteration: 54.1 - Feb 6 → ---
Whiteboard: [e10s-multi:+]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: