1574163 - Crash in [@ js::frontend::PerHandlerParser<T>::propagateFreeNamesAndMarkClosedOverBindings]

Status: NEW

(Core :: JavaScript Engine, defect, P2)

Description

[Marcia Knous [:marcia]]

This bug is for crash report bp-f2bc98a7-2f0e-496e-88cf-01cfc0190802.

Seen while looking at 69.0b13 crash data - this crash has been around in a few different releases, but seems fairly visible in 69 betas and is #25 so far in 69.0b13: https://bit.ly/2OVRq8j

Some correlations:

(96.08% in signature vs 00.17% overall) address = 0xd
(29.41% in signature vs 01.67% overall) platform_pretty_version = OS X 10.14 [93.75% vs 10.08% if platform = Mac OS X]
(27.45% in signature vs 68.80% overall) e10s_cohort = null [100.0% vs 33.29% if process_type = content]
(100.0% in signature vs 35.56% overall) is_garbage_collecting = null
(86.27% in signature vs 13.08% overall) Addon "[e-mail]" = true
(60.78% in signature vs 100.0% overall) jit_category = null [100.0% vs 35.69% if process_type = content]
(13.73% in signature vs 73.30% overall) Addon "[e-mail]" = true
(76.47% in signature vs 15.91% overall) release_channel = aurora
(23.53% in signature vs 84.09% overall) release_channel = beta
(39.22% in signature vs 95.85% overall) abort_message = null
(31.37% in signature vs 02.51% overall) Module "libOpenScriptingUtil.dylib" = true [65.00% vs 02.00% if startup_crash = null]
(13.73% in signature vs 59.53% overall) addons_checked = null
(54.90% in signature vs 05.96% overall) reason = EXCEPTION_ACCESS_VIOLATION_WRITE
(70.59% in signature vs 28.90% overall) contains_memory_report = null
(72.55% in signature vs 33.21% overall) ipc_message_name = null
(31.37% in signature vs 01.33% overall) Module "libplugin_child_interpose.dylib" = true [50.00% vs 01.30% if startup_crash = null]
(45.10% in signature vs 07.91% overall) Addon "[e-mail]" = true
(31.37% in signature vs 01.18% overall) Addon "@react-devtools" = true

some comments:
*Crash occurs whilst developing a site in Meteor, utilizing blaze templates, bootstrap and a multitude of messy CSS.
*.. and after clicking a hyperlink to jump to source for an error that occurred (in my application code), in the Console tab of developer tools. The Debugger window opens, then the tab crashes.


Top 10 frames of crashing thread:

0 xul.dll js::frontend::PerHandlerParser<js::frontend::FullParseHandler>::propagateFreeNamesAndMarkClosedOverBindings js/src/frontend/Parser.cpp:842
1 xul.dll js::frontend::GeneralParser<js::frontend::FullParseHandler, mozilla::Utf8Unit>::functionBody js/src/frontend/Parser.cpp:1966
2 xul.dll js::frontend::GeneralParser<js::frontend::FullParseHandler, mozilla::Utf8Unit>::functionFormalParametersAndBody js/src/frontend/Parser.cpp:3045
3 xul.dll js::frontend::Parser<js::frontend::FullParseHandler, mozilla::Utf8Unit>::standaloneLazyFunction js/src/frontend/Parser.cpp:2919
4 xul.dll js::frontend::CompileLazyFunction js/src/frontend/BytecodeCompiler.cpp:996
5 xul.dll JSFunction::createScriptForLazilyInterpretedFunction js/src/vm/JSFunction.cpp:1626
6 xul.dll static class JSScript* DelazifyScript js/src/debugger/Script.cpp:134
7 xul.dll js::DebuggerScript::GetLineCountMatcher::match js/src/debugger/Script.cpp:359
8 xul.dll js::DebuggerScript::getLineCount js/src/debugger/Script.cpp:381
9  @0x172f3ae1b4f 

Comment 1

[Marcia Knous [:marcia]]

Discussed during platform triage. Recommendation was made to have triage owner take a look.

Comment 2

[Steven DeTar [:sdetar]]

Jason, any idea in who on our team would be a good person to look at this?

Comment 3

[Jason Orendorff [:jorendorff]]

Matt, would you take a look at this?

This has been going on for months at least. I see 1000+ crash reports. The URL field doesn't tell any consistent story.

Here we're delazifying a function, and the crash suggests to me that (1) when the frontend initially bytecode-compiled the enclosing script, we got the scoping information wrong; or (2) between then and now someone has been scribbling on the heap; or (3) similar, but XDR screwed it up.

My thought is, when we get here, it's very easy to check at runtime and detect that the lookup returns null. Once we know the lookup has failed, there is no way to proceed -- we have to crash. So we can then release-assert every invariant we can think of about the scope and the lazy-compilation context generally, followed by MOZ_CRASH at the end. That should tell us more about this crash. Or maybe just add the filename of the script to the crash report.

Comment 4

[Jason Orendorff [:jorendorff]]

To clarify: many crashes happen writing to 0x0d. That's the address written by setClosedOver() on this line when lookupDeclaredName returns a null Ptr.

Comment 5

[Ted Campbell [:tcampbell]]

40% of these crashes occur during Debugger-induced delazification.

I wonder if we somehow are reviving lazy functions from parse failures? The JSFunction + LazyScript is allocated early on in the parse stage.

Comment 6

[Jason Orendorff [:jorendorff]]

I asked and arai already thought of this, and added this enclosingScriptHasEverBeenCompiled check.

Arai, is it possible this is not sufficient? Or that the implementation of enclosingSccriptHasEverBeenCompiled() is no longer accurate?

Comment 7

[Tooru Fujisawa [:arai]]

so far I don't find anything suspicious, but I guess XDR case isn't much tested. I'll continue investigating.

Comment 8

[Liz Henry (:lizzard) (relman/hg->git project)]

Low crash volume, so I'm removing this from weekly crash triage.
We could still take a patch for 71/72.

Comment 9

[Tooru Fujisawa [:arai]]

No recent crash, and the latest one (88.0b4) is not for XDR case.

Comment 10

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

Since the crash volume is low (less than 5 per week), the severity is downgraded to S3. Feel free to change it back if you think the bug is still critical.

For more information, please visit auto_nag documentation.