https://crash-stats.mozilla.com/report/index/e58f8612-b90a-48c9-80a5-30a3b0171027 is an example. I think the issue is that mElement is somehow null in https://hg.mozilla.org/releases/mozilla-beta/annotate/86534d5daeef/dom/script/ScriptLoader.cpp#l2892 I'll look this a bit, and if nothing else, add a null check.
Hmm, this is trickier than I thought. Looks like only preloading doesn't have mElement set, but why do we call ContinueParserAsync on such requests. By mistake?
oh, hmm, maybe this is something else after all. Compilers clearly inline methods here, so a bit hard to follow this all.
mExecutor is null, if I read various crash reports right.
Looks like that may have happened if we've unlinked parser.
Quick and dirty. Other option is to go through all of the ownership model of parser to see why we get unlinked. But in principle if we end up closing the window or such and spin event loop, that could rather easily lead to this kinds result.
Attachment #8924270 - Flags: review?(hsivonen)
Attachment #8924270 - Flags: review?(hsivonen) → review+
Pushed by email@example.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/9d76daebda99 ensure we have still the executor before trying to continue parsing, r=hsivonen
Status: NEW → RESOLVED
Last Resolved: a year ago
status-firefox58: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla58
Component: DOM → DOM: Core & HTML
Product: Core → Core
You need to log in before you can comment on or make changes to this bug.