Closed Bug 1695989 Opened 3 years ago Closed 3 years ago

Crash in [@ nsIGlobalObject::IsScriptForbidden]

Categories

(Core :: DOM: Workers, defect, P3)

Unspecified
Android
defect

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: dveditz, Unassigned)

Details

(Keywords: crash)

Crash Data

I've crashed 6 times with this signature over the weekend, which is unusual instability for Fenix nightly (my previous crash was two months ago, Jan 7). According to Socorro there were 148 crashes reported all in build 20210227094458 which seems like a significant spike. But maybe it's gone away on its own since I don't see later build IDs? I just got updated to the 0302 build this morning after crashing again. I don't know why I'm getting so few updates, especially since I'm on WiFi practically 100% of the time during the pandemic stay-at-home.

Note: this function lives in dom/base so maybe it should be filed as a Core::DOM bug? That wasn't an option from the Socorro tab. I'll leave it here on the theory Socorro was set up that way on purpose so you can keep track of these kinds of not-happening-on-desktop crashes.

Crash report: https://crash-stats.mozilla.org/report/index/f143b79c-3de0-44ce-9df3-86a6f0210302

Reason: SIGSEGV /SEGV_MAPERR

Top 10 frames of crashing thread:

0 libxul.so nsIGlobalObject::IsScriptForbidden const dom/base/nsIGlobalObject.cpp:45
1 libxul.so mozilla::dom::CallbackObject::CallSetup::CallSetup dom/bindings/CallbackObject.cpp:255
2 libxul.so mozilla::EventListenerManager::HandleEventSubType dom/events/EventListenerManager.cpp:1099
3 libxul.so mozilla::EventListenerManager::HandleEventInternal dom/events/EventListenerManager.cpp:1296
4 libxul.so mozilla::EventTargetChainItem::HandleEventTargetChain dom/events/EventDispatcher.cpp:556
5 libxul.so mozilla::EventDispatcher::Dispatch dom/events/EventDispatcher.cpp:1099
6 libxul.so mozilla::DOMEventTargetHelper::DispatchEvent dom/events/DOMEventTargetHelper.cpp:181
7 libxul.so mozilla::dom::EventTarget::DispatchEvent dom/events/EventTarget.cpp:183
8 libxul.so mozilla::dom:: dom/serviceworkers/ServiceWorkerOp.cpp:246
9 libxul.so mozilla::dom::FetchEventOp::Exec dom/serviceworkers/ServiceWorkerOp.cpp:1257

Socorro doesn't seem to capture URLs for Android, or maybe just not this crash. I was on mobile.twitter.com for each of those crashes in case this turns out to be an older bug tickled by a site change rather than a regression in that build.

Component: General → DOM: Events
Product: GeckoView → Core

It's definitely weird that this is largely all seems tied to a single build id plus a few rarer crashes in older build ids. (Note that the "0.0a1" version, which looks weird, is actually just the version assigned to nightly Fenix builds per bug 1624911.) Creating a super search for Fenix 0.0a1 with worker runnables in the crash stack proto signature (which has more than the much more concise signature) only seems to find this signature and mozilla::dom::AbortFollower::Unfollow which was fixed-by-backout bug 1692362.

The only thing I think that would have meaningfully landed around this time would be Eden's fix in bug 1693967 to avoid creating workers once the RuntimeService is in shutdown, but these crashes all seem to be from content processes that aren't in XPCOM shutdown (and we would expect to terminate at profile-before-change in a pure-Gecko world without ever entering XPCOM shutdown... not sure when they terminate under GeckoView).

One possibility to keep in mind is that the correlation involves external factors like a ServiceWorker update involving skipWaiting that marked the given SW as redundant out from under a fetch event. Except I don't think that should actually be possible given our in-order queueing and processing of all ServiceWorker events and how our state machine reacts to termination operations.

We should keep an eye on this signature to the extent possible. (I don't think we have an automated watch/alert for spikes for a specific signature though?)

Severity: -- → S3
Priority: -- → P3

Closing because no crashes reported for 12 weeks.

Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.