Crash in [@ mozilla::dom::FetchEventOp::ResolvedCallback]
Categories
(Core :: DOM: Service Workers, defect)
Tracking
()
People
(Reporter: u608768, Unassigned)
Details
(Keywords: crash)
Crash Data
Crash report: https://crash-stats.mozilla.org/report/index/23794f6a-245a-485a-a636-ff1180201002
MOZ_CRASH Reason: MOZ_DIAGNOSTIC_ASSERT(false) (Cors or opaque Response without a URL)
Top 10 frames of crashing thread:
0 XUL mozilla::dom::FetchEventOp::ResolvedCallback dom/serviceworkers/ServiceWorkerOp.cpp:1428
1 XUL mozilla::dom:: dom/promise/Promise.cpp:383
2 XUL mozilla::dom::NativeHandlerCallback dom/promise/Promise.cpp:336
3 XUL js::InternalCallOrConstruct js/src/vm/Interpreter.cpp:600
4 XUL js::Call js/src/vm/Interpreter.cpp:682
5 XUL PromiseReactionJob js/src/builtin/Promise.cpp:1903
6 XUL js::InternalCallOrConstruct js/src/vm/Interpreter.cpp:600
7 XUL JS::Call js/src/jsapi.cpp:2830
8 XUL mozilla::dom::PromiseJobCallback::Call dom/bindings/PromiseBinding.cpp:30
9 XUL mozilla::PromiseJobRunnable::Run xpcom/base/CycleCollectedJSContext.cpp:211
Started in build 20201001094020.
|
||
Comment 1•4 years ago
|
||
Hi Andrew, do you remember, what exactly we wanted to check with that diagnostic assert?
|
||
Comment 3•4 years ago
|
||
(In reply to Jens Stutte [:jstutte] from comment #1)
Hi Andrew, do you remember, what exactly we wanted to check with that diagnostic assert?
I believe the general idea is that the only source of Responses with a type other than "default" are those created by the system, and the system won't create such a response without a URL. Specifically, only main fetch step 7.2 should be able to do this.
The most likely reasons for this assertion to fail would involve some kind of serialization/deserialization edge case. In particular, older Cache API storage state or some very weird IPC path might seem feasible. Also, just disk/memory corruption. Because Responses currently aren't transferable, there are pretty severe limitations on how this could happen. It might also be possible that some kind of COOP/COEP defense is involved somehow?
|
|
||
Comment 4•4 years ago
|
||
After looking also at a minidump I do not see much actionable here, disk/memory corruption seems likely. There are only three "crash-days" and on each we had 3-4 crashes from the same install in a very short time frame.
|
||
Comment 5•3 years ago
|
||
Closing because no crashes reported for 12 weeks.
|
|
||
Comment 6•3 years ago
|
||
Since the bug is closed, the stalled keyword is now meaningless.
For more information, please visit auto_nag documentation.
Description
•