1844221 - Crash in [@ mozilla::dom::FetchEventOp::ResolvedCallback]

Status: RESOLVED WONTFIX

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

Description

[Ryan VanderMeulen [:RyanVM]]

Crash report: https://crash-stats.mozilla.org/report/index/58b97eb6-62dc-4097-ad97-186930230718

Reason: SIGSEGV / SEGV_MAPERR

Top 10 frames of crashing thread:

0  libxul.so  mozilla::dom::FetchEventOp::ResolvedCallback  dom/serviceworkers/ServiceWorkerOp.cpp:1469
1  libxul.so  mozilla::dom::  dom/promise/Promise.cpp:469
2  libxul.so  mozilla::dom::NativeHandlerCallback  dom/promise/Promise.cpp
3  libxul.so  CallJSNative  js/src/vm/Interpreter.cpp:486
3  libxul.so  js::InternalCallOrConstruct  js/src/vm/Interpreter.cpp:580
3  libxul.so  InternalCall  js/src/vm/Interpreter.cpp:647
3  libxul.so  js::Call  js/src/vm/Interpreter.cpp:679
4  libxul.so  js::Call  js/src/vm/Interpreter.h:116
4  libxul.so  PromiseReactionJob  js/src/builtin/Promise.cpp:2240
5  libxul.so  CallJSNative  js/src/vm/Interpreter.cpp:486

Comment 1

[Olli Pettay [:smaug][[e-mail]] (vacation-ish -> Aug 1)]

That seems to be a diagnostic assert. Interestingly Android only.
Do we possible have different code paths on Fission vs non-Fission?

Comment 2

[Andrew Sutherland [:asuth] (he/him)]

(In reply to Olli Pettay [:smaug][[e-mail]] from comment #1)

That seems to be a diagnostic assert. Interestingly Android only.
Do we possible have different code paths on Fission vs non-Fission?

We have e10s and non-e10s paths but fission doesn't really matter; also it looks like pfetch should be enabled everywhere. There's a good chance this could be ORB fallout from us blocking internal responses at the process boundary. It looks like both :sefeng and :farre are out for now, but I see you and Eden reviewed https://phabricator.services.mozilla.com/D173454 on bug 1823877 so needinfo-ing you both.

Edit addition: I expect it's probably fine for us to remove the diagnostic assertion that's tripping here assuming we believe that the change in invariant is due to ORB-related blocking of the actual internal response contents at the process boundary. We probably would want to check for other similar assertions if that's the case.

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

The bug is linked to a topcrash signature, which matches the following criterion:

• Top 10 AArch64 and ARM crashes on nightly

:smaug, could you consider increasing the severity of this top-crash bug?

For more information, please visit BugBot documentation.

Comment 4

[Eden Chuang[:edenchuang]]

Attachment: Bug 1844221 - Change diagnostic assertion to debug assertion for opaque response extra checking in FetchEventOp::ResolvedCallback. r=asuth

Comment 5

[BugBot [:suhaib / :marco/ :calixte]]

Based on the topcrash criteria, the crash signature linked to this bug is not a topcrash signature anymore.

For more information, please visit BugBot documentation.

Comment 6

[Eden Chuang[:edenchuang]]

Close the bug since there has been no crash report for several months. Other patches could probably fix it.