1700586 - Startup Crash in [@ js::frontend::CompilationStencil::instantiateStencils]

Status: RESOLVED DUPLICATE of bug 1697952

(Core :: JavaScript Engine, defect, P1)

Description

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

~70% of the crashes hit in the first minute after startup, starting with the 87 branch; 88.0b1 hit it on 9 installations in less than a day

Tooru, please evaluate if this crash needs action.

Crash report: https://crash-stats.mozilla.org/report/index/e83791f9-a48a-4b39-91fb-d92c30210324

Reason: EXCEPTION_ACCESS_VIOLATION_WRITE

Top 10 frames of crashing thread:

0 xul.dll static js::frontend::CompilationStencil::instantiateStencils js/src/frontend/Stencil.cpp:1257
1 xul.dll js::frontend::InstantiateStencils js/src/frontend/BytecodeCompiler.cpp:386
2 xul.dll js::ParseTask::instantiateStencils js/src/vm/HelperThreads.cpp:722
3 xul.dll js::ScriptDecodeTask::parse js/src/vm/HelperThreads.cpp:836
4 xul.dll js::ParseTask::runHelperThreadTask js/src/vm/HelperThreads.cpp:619
5 xul.dll static js::HelperThread::ThreadMain js/src/vm/HelperThreads.cpp:2364
6 xul.dll static js::detail::ThreadTrampoline<void  js/src/threading/Thread.h:205
7 ucrtbase.dll thread_start<unsigned int , 1> 
8 kernel32.dll BaseThreadInitThunk 
9 ntdll.dll RtlUserThreadStart 

Comment 1

[Tooru Fujisawa [:arai]]

This is same crash as bug 1697952.
Will continue investigating.

Comment 2

[Ted Campbell [:tcampbell]]

Inline frame info:

    xul!js::ScriptWarmUpData::setTaggedPtr   
    xul!js::ScriptWarmUpData::initEnclosingScript   
    xul!js::BaseScript::setEnclosingScript   
    xul!JSFunction::setEnclosingLazyScript + 0x4   
    xul!LinkEnclosingLazyScript + 0xfa   
    xul!js::frontend::CompilationStencil::instantiateStencilAfterPreparation + 0x7f2   
0   xul!js::frontend::CompilationStencil::instantiateStencils + 0x8e2   
1   xul!js::frontend::InstantiateStencils + 0x96   
2   xul!js::ParseTask::instantiateStencils + 0x168   
3   xul!js::ScriptDecodeTask::parse + 0x29a   
    xul!js::ParseTask::runTask + 0x106   

As in the other bug, the BaseScript is a nullptr.

Comment 3

[Ryan VanderMeulen [:RyanVM]]

This is showing up pretty high in the Beta topcrash list (#3 overall at the moment). Anything we can do to help bump the priority?

Comment 4

[Steven DeTar [:sdetar]]

Arai, do you have any new status on this bug (and/or on the related bug 1697952)

Comment 5

[Nicolas B. Pierron [:nbp]]

The bug appear mostly on the aurora release channel, which corresponds to the dev-edition channel of Firefox beta.
The URL are show mostly addresses with localhost or debug, dev in the name.
The user comments are suggesting something related to breakpoint which are not working properly and cannot be removed.

Jan found the following regression range:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=c7e489f5759a6dc1e0dabdab8772339410e5e12b&tochange=5199ec2d73fa7daf423b72416be41383ac1042dc

User comments suggest some bad debugger interaction, while another mention seeing this bug after angular 11 update.

As Arai suggested, this could be a merge issue, potentially between 87.0b9 and 88.0b1.

Comment 6

[Nicolas B. Pierron [:nbp]]

(In reply to Nicolas B. Pierron [:nbp] from comment #5)

As Arai suggested, this could be a merge issue, potentially between 87.0b9 and 88.0b1.

I do not see any significant differences between FIREFOX_BETA_88_BASE and DEVEDITION_88_0b1_BUILD1.

Comment 7

[Nicolas B. Pierron [:nbp]]

Looking at the regression range around when bug 1697952 started, it seems that Bug 1687095 might also be the root cause.

Comment 8

[Ted Campbell [:tcampbell]]

We have a theory that is being investigated now. In this theory, the bug only applies in edge cases after using devtools debugger breakpoints on a page.

Comment 9

[Tooru Fujisawa [:arai]]

we're handling this in bug 1697952