Crash in [@ mozilla::extensions::ExtensionsParent::RecvStateChange]
Categories
(WebExtensions :: General, defect, P5)
Tracking
(firefox-esr78 unaffected, firefox88 unaffected, firefox89 affected, firefox90 affected)
Tracking | Status | |
---|---|---|
firefox-esr78 | --- | unaffected |
firefox88 | --- | unaffected |
firefox89 | --- | affected |
firefox90 | --- | affected |
People
(Reporter: aryx, Unassigned)
References
(Regression)
Details
(Keywords: crash, regression)
Crash Data
Crash report: https://crash-stats.mozilla.org/report/index/ae9fd61a-cc7f-4659-bad9-22c810210511
MOZ_CRASH Reason: MOZ_RELEASE_ASSERT(mWebNavigation)
Top 10 frames of crashing thread:
0 libxul.so mozilla::extensions::ExtensionsParent::RecvStateChange toolkit/components/extensions/ExtensionsParent.cpp:99
1 libxul.so mozilla::extensions::PExtensionsParent::OnMessageReceived ipc/ipdl/PExtensionsParent.cpp:293
2 libxul.so mozilla::dom::PContentParent::OnMessageReceived ipc/ipdl/PContentParent.cpp:6563
3 libxul.so mozilla::ipc::MessageChannel::DispatchMessage ipc/glue/MessageChannel.cpp:2076
4 libxul.so mozilla::TaskController::DoExecuteNextTaskOnlyMainThreadInternal xpcom/threads/TaskController.cpp:766
5 libxul.so nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:1159
6 libxul.so mozilla::ipc::MessagePump::Run ipc/glue/MessagePump.cpp:85
7 libxul.so MessageLoop::Run ipc/chromium/src/base/message_loop.cc:310
8 libxul.so nsBaseAppShell::Run widget/nsBaseAppShell.cpp:137
9 libxul.so nsAppStartup::Run toolkit/components/startup/nsAppStartup.cpp:273
Reporter | ||
Updated•3 years ago
|
Comment 1•3 years ago
•
|
||
This is weird, basically just asserting that the load of a module succeeded in:
https://searchfox.org/mozilla-central/rev/cecdac0aa5733fee515a166b6e31e38cc58abf32/toolkit/components/extensions/ExtensionsParent.cpp#26
And WebNavigation.jsm
does almost nothing, imports Services.jsm
and sets up the exported object with some methods. Basically, my only guess why this might fail is OOM or similar.
Kris, do you have a better idea what's happening perhaps? Can we try to detect OOM somewhere, or maybe paper over this (drop the assert) and hope it crashes in a more obvious place if it is in fact OOM?
Comment 2•3 years ago
|
||
This is probably just another instance of bug 1616059. At least the Firefox ones. No idea about Thunderbird. The RecvDocumentChange
once certainly is. They're all from a single installation. And one of the reports has the comment "Crashes on Browser startup. Rebooting system does not help. I have plenty of opened tabs but it worked for months. Now after an update it keeps crashing." which suggests corruption.
It doesn't look like an OOM. A lot of the reports do have the JSOutOfMemory
annotation, but the machines still have plenty of physical/virtual memory and page file, so it's unlikely that's the actual cause.
Comment 3•3 years ago
|
||
Thanks Kris.
Updated•3 years ago
|
Description
•