Crash in [@ nsParser::UnblockParser]
Categories
(Core :: DOM: HTML Parser, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr91 | --- | unaffected |
firefox100 | --- | wontfix |
firefox101 | --- | wontfix |
firefox102 | --- | fixed |
People
(Reporter: sefeng, Assigned: kmag)
References
Details
(Keywords: crash)
Crash Data
Attachments
(1 file)
Maybe Fission related. (DOMFissionEnabled=1)
Crash report: https://crash-stats.mozilla.org/report/index/6b9d743f-f762-46a4-b8ea-aaa140210901
MOZ_CRASH Reason: MOZ_DIAGNOSTIC_ASSERT(mBlocked > 0)
Top 10 frames of crashing thread:
0 xul.dll nsParser::UnblockParser parser/htmlparser/nsParser.cpp:620
1 xul.dll mozilla::dom::`anonymous namespace'::NotifyOffThreadScriptLoadCompletedRunnable::Run dom/script/ScriptLoader.cpp:2462
2 xul.dll mozilla::SchedulerGroup::Runnable::Run xpcom/threads/SchedulerGroup.cpp:144
3 xul.dll mozilla::TaskController::DoExecuteNextTaskOnlyMainThreadInternal xpcom/threads/TaskController.cpp:805
4 xul.dll nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:1148
5 xul.dll mozilla::ipc::MessagePump::Run ipc/glue/MessagePump.cpp:107
6 xul.dll MessageLoop::RunHandler ipc/chromium/src/base/message_loop.cc:324
7 xul.dll MessageLoop::Run ipc/chromium/src/base/message_loop.cc:306
8 xul.dll nsBaseAppShell::Run widget/nsBaseAppShell.cpp:137
9 xul.dll nsAppShell::Run widget/windows/nsAppShell.cpp:603
https://addons.mozilla.org/en-US/firefox/addon/violentmonkey/ seems to trigger it.
Can this be true?
Was this nightly build good, bad, or broken? (type 'good', 'bad', 'skip', 'retry', 'back' or 'exit' and press Enter): good
8:18.31 INFO: Narrowed nightly regression window from [2019-04-17, 2019-04-19] (2 days) to [2019-04-18, 2019-04-19] (1 days) (~0 steps left)
8:18.31 INFO: Got as far as we can go bisecting nightlies...
8:18.31 INFO: Last good revision: 2ccc6648064315964dd23039ad28ebf7d9f82999 (2019-04-18)
8:18.31 INFO: First bad revision: 30b70a449280e6df10496a51e89c01b8c98bb92e (2019-04-19)
8:18.31 INFO: Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=2ccc6648064315964dd23039ad28ebf7d9f82999&tochange=30b70a449280e6df10496a51e89c01b8c98bb92e
8:18.31 INFO: Switching bisection method to taskcluster
...
8:35.41 INFO: There are no build artifacts for these changesets (they are probably too old).
Comment 5•2 years ago
|
||
The crash number increased in 99.0a1.
Comment 6•2 years ago
|
||
From a cursory look at the crash reports, this indeed looks extension-related, which would explain why whatever happens here isn't caught by out test suite.
Since this is a diagnostic assert, it doesn't manifest as a crash in release. In release, this likely appears to the user as if the network stream for the HTML input had stalled. While that's not good, it's also isn't as disruptive-looking as a crash.
Next steps would be to audit the parser blocking/unblocking code as called from extensions and perhaps trying to catch the situation in rr.
The following STR triggers a "part of this page crashed" message 100% of the time for me:
macOS 11.6.5
Firefox 102 (2022-05-03)
- Install Preact DevTools extension 1.4.4 (https://preactjs.github.io/preact-devtools/)
- Go to https://www.indiegogo.com
Example crash report: https://crash-stats.mozilla.org/report/index/0c1bc7fe-7cf9-4456-b9c2-a79d70220503
Assignee | ||
Comment 8•2 years ago
|
||
Bug 1333990 added the ability to have multiple parser blockers at the same
time, so we no longer need to guard against recursively blocking. What's more,
if we do, and skip calling BlockParser
while it's blocked for another reason,
we still call UnblockParser
when we receive script data, at which point we
crash.
The only way I've seen this manifest as a bug is when we have an XHTML
document with a top-level <script> element, and an extension with content
scripts that cause us to block parsing when we see that top-level element and
need to wait for them to compile.
Updated•2 years ago
|
Pushed by maglione.k@gmail.com: https://hg.mozilla.org/integration/autoland/rev/1ac8a4436a21 Recursively block parsing for parser blocking scripts. r=hsivonen
Comment 10•2 years ago
|
||
Backed out changeset 1ac8a4436a21 (bug 1729005) for causing xpc/mochitest failures in test_blockParsing.
Backout link: https://hg.mozilla.org/integration/autoland/rev/b8e13455b4df58c953d941ba1dcfa3e3cff192ef
INFO - TEST-UNEXPECTED-FAIL | dom/base/test/test_blockParsing.html | Test timed out. -
[task 2022-05-05T19:19:36.389Z] 19:19:36 INFO - GECKO(1567) | MEMORY STAT | vsize 11438MB | residentFast 463MB | heapAllocated 179MB
[task 2022-05-05T19:19:36.395Z] 19:19:36 INFO - TEST-OK | dom/base/test/test_blockParsing.html | took 318570ms
[task 2022-05-05T19:19:36.411Z] 19:19:36 INFO - GECKO(1567) | [Parent 1567, Main Thread] WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x80004005 (NS_ERROR_FAILURE): file /builds/worker/checkouts/gecko/chrome/nsChromeRegistry.cpp:180
[task 2022-05-05T19:19:36.412Z] 19:19:36 INFO - GECKO(1567) | [Parent 1567, Main Thread] WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x80004005 (NS_ERROR_FAILURE): file /builds/worker/checkouts/gecko/dom/security/nsCSPService.cpp:190
[task 2022-05-05T19:19:36.439Z] 19:19:36 INFO - Not taking screenshot here: see the one that was previously logged
Comment 11•2 years ago
|
||
Pushed by maglione.k@gmail.com: https://hg.mozilla.org/integration/autoland/rev/ae4f4209538e Recursively block parsing for parser blocking scripts. r=hsivonen
Comment 12•2 years ago
|
||
Backed out changeset ae4f4209538e (Bug 1729005) for causing xpcshell failures on test_blockParsing.js.
Backout link
Push with failures <--> X1
Failure Log
Comment 13•2 years ago
|
||
Backout by nbeleuzu@mozilla.com: https://hg.mozilla.org/mozilla-central/rev/f1e87b2a9a25 Backed out changeset ae4f4209538e for causing xpcshell failures on test_blockParsing.js.
Updated•2 years ago
|
Comment 14•2 years ago
|
||
Pushed by maglione.k@gmail.com: https://hg.mozilla.org/integration/autoland/rev/46772bfff9dc Recursively block parsing for parser blocking scripts. r=hsivonen
Comment 15•2 years ago
|
||
bugherder |
Updated•2 years ago
|
Description
•