Crash on metacpan.org

[ptribble]

I get a crash when attempting to visit a page on metacpan.org, for example https://metacpan.org/dist/DBD-Pg

This is Pale Moon 34.1.0 on illumos (Tribblix).

Wondering if it's just me, or whether it's a more general problem.

Relevant top of stack below, but all that shows me is that it's inside libxul, and as this is illumos it may be more useful if you got a dump off something you're more familiar with

Code: Select all

fffffc7fffdfbe00 0xffffffffffffffff()
fffffc7fffdfbe60 libxul.so`_ZN2js3jit16BaselineCompiler8emitBodyEv+0x255()
fffffc7fffdfc100 libxul.so`_ZN2js3jit16BaselineCompiler7compileEv+0x310()
fffffc7fffdfce90 libxul.so`_ZN2js3jit15BaselineCompileEP9JSContextP8JSScriptb+0x16b()
fffffc7fffdfcee0 libxul.so`_ZN2js3jit24CanEnterBaselineAtBranchEP9JSContextPNS_16InterpreterFrameEb+0xa6()
fffffc7fffdfd360 libxul.so`_ZL9InterpretP9JSContextRN2js8RunStateE+0x2cd5()
fffffc7fffdfd450 libxul.so`_ZN2js9RunScriptEP9JSContextRNS_8RunStateE+0x116()
fffffc7fffdfd4d0 libxul.so`_ZN2js13ExecuteKernelEP9JSContextN2JS6HandleIP8JSScriptEER8JSObjectRKNS2_5ValueENS_16AbstractFramePtrEPS9_+0x128()
fffffc7fffdfd530 libxul.so`_ZN2js7ExecuteEP9JSContextN2JS6HandleIP8JSScriptEER8JSObjectPNS2_5ValueE+0x9b()
fffffc7fffdfd600 libxul.so`_ZN2js12ModuleObject7executeEP9JSContextN2JS6HandleIPS0_EENS3_13MutableHandleINS3_5ValueEEE+0x184()
fffffc7fffdfd640 libxul.so`_ZL23intrinsic_ExecuteModuleP9JSContextjPN2JS5ValueE+0x64()
fffffc7fffdfd6f0 libxul.so`_ZN2js23InternalCallOrConstructEP9JSContextRKN2JS8CallArgsENS_14MaybeConstructE+0x125()
fffffc7fffdfdb70 libxul.so`_ZL9InterpretP9JSContextRN2js8RunStateE+0xb30()
fffffc7fffdfdc60 libxul.so`_ZN2js9RunScriptEP9JSContextRNS_8RunStateE+0x116()
fffffc7fffdfdd10 libxul.so`_ZN2js23InternalCallOrConstructEP9JSContextRKN2JS8CallArgsENS_14MaybeConstructE+0x244()
fffffc7fffdfe190 libxul.so`_ZL9InterpretP9JSContextRN2js8RunStateE+0xb30()
fffffc7fffdfe280 libxul.so`_ZN2js9RunScriptEP9JSContextRNS_8RunStateE+0x116()
fffffc7fffdfe330 libxul.so`_ZN2js23InternalCallOrConstructEP9JSContextRKN2JS8CallArgsENS_14MaybeConstructE+0x244()
fffffc7fffdfe350 libxul.so`_ZN2js4CallEP9JSContextN2JS6HandleINS2_5ValueEEES5_RKNS_13AnyInvokeArgsENS2_13MutableHandleIS4_EE+0x29()
fffffc7fffdfe420 libxul.so`_ZL22InvokeSelfHostedMethodP9JSContextN2JS6HandleIPN2js12ModuleObjectEEENS2_IPNS3_12PropertyNameEEE+0x163()
fffffc7fffdfe440 libxul.so`_ZN9nsJSUtils14ModuleEvaluateEP9JSContextN2JS6HandleIP8JSObjectEE+0x2d()
fffffc7fffdfe7e0 libxul.so`_ZN7mozilla3dom12ScriptLoader14EvaluateScriptEPNS0_17ScriptLoadRequestE+0x79e()

[Gemmaugr]

Confirmed here too (Win 10, PM 64-bit).

I finally managed to get a use out of WinDBG!!

Though I couldn't get Pale Moon FTP to work, I uploaded a default new profile dump here: https://litter.catbox.moe/xy2ivdt3umknrre0.7z (3 day expiration)

[q160765803]

turning off javascript.options.baselinejit in about:config seems help.

[jobbautista9]

PR Issue #3002 (UXP) should fix the crash. Surprised we haven't encountered this sooner... I guess we can't count on Interpret() to just interpret the code and never enter baseline JIT.

[q160765803]

PR Issue #3002 (UXP) should fix the crash. Surprised we haven't encountered this sooner... I guess we can't count on Interpret() to just interpret the code and never enter baseline JIT.

just noticed that when it crashes in metacpan, stackDepth and stack.length() are not match (i.e. lesser), so MOZ_ASSERT should fail if it is compiled in debug mode.

[Moonchild]

We already looked at this before, it's a known issue that they get out of sync and that happens only with top-level await. There is no immediate solution for this so we decided foregoing baseline compilation if we run into this particular situation, also considering the modules in question not really ever being hot paths.

[Basilisk-Dev]

Interestingly enough, I am not able to replicate this crash on Apple Silicon MacOS or aarch64 Linux. Probably a difference between how x86 and ARM Baseline JITs behave considering I can replicate the crash on an x86 machine.

[ptribble]

PR Issue #3002 (UXP) should fix the crash. Surprised we haven't encountered this sooner... I guess we can't count on Interpret() to just interpret the code and never enter baseline JIT.

Excellent news. Thanks!