Crash on instagram.com [Mac]

[CHris Hitarori]

I've experienced odd crashes on Instagram recently, both in the most recent and slightly older Pale Moon versions. As of now I am unable to reproduce this crash reliably. Therefore I'm not filing an official bug report yet but would like to ask the general question: Has anyone noticed this besides me? I'd like to collect some feedback before testing this more thoroughly to determine a regression window (if any), the affected OS versions and clear STR.

[Garland]

I don't use instagram. But I noticed today that PM uses a SSUA for instagram telling the site that it is Firefox 68.0. PM 33.8.0 changed the Firefox compatibility mode from 115 to 128.0. So 68.0 is ancient!

See for yourself all the SSUAs. Go to about:config and search for "general.useragent" (without the quotes).

This add-on makes it easier to experiment with SSUAs: https://addons.palemoon.org/addon/ua-status/

These days, Firefox users on Windows older than Win10 are stuck on Firefox 115. So sites maintain compatibility with Firefox 115 or risk losing a lot of users. If instagram adapts their site to the UA at all these days, I suspect that Firefox 115 is a better choice than Firefox 68.

I encourage PM users to provide feedback about instagram and other sites where PM has a SSUA for an old Firefox version.

[CHris Hitarori]

I determined steps to reproduce and investigated a bit further. Can anyone reproduce this crash?

example url:
https://www.instagram.com/parteiderhumanisten/

S.T.R. for 33.8.0:
• create a fresh user profile
• quit Pale Moon
• start Pale Moon
• visit example url

result in console:
Thread XX Crashed:: JS Helper
0 XUL 0x000000010c9038e9 0x10a0c9000 + 42182889
EXC_BAD_ACCESS (SIGBUS)
KERN_PROTECTION_FAILURE at 0x0000700000531fe8

OS affected
Mac OS X 10.7.5 Lion: crash
Mac OS X 10.8.5 Mountain Lion: crash
Mac OS X 10.11 El Capitan: crash
macOS 13.7.6 Ventura: no crash
macOS 14.7.6 Sonoma: no crash
Windows 11 24H2: no crash

regression window
last good version 33.6.1
first bad version 33.7.0

no crash when
- js disabled

still crash when
- asmjs disabled
- baselinejit disabled
- ion disabled
- wasm disabled

[CHris Hitarori]

@dbsoft seems to be specific to older Mac OS X.

@moderators if you think this thread should be in 'Pale Moon for Mac OS' go ahead and move it over.

[dbsoft]

I was able to replicate the crash on 10.11, but the crash info did not give me anything of interest so I'll have to do a debug build on that system to figure it out.

The JS Helper thread doesn't generally have anything platform specific so it is little perplexing.

It did not crash on 15.5, so your results seem to be accurate.

Edit: I did a build on the 10.11 machine using a clang from MacPorts, but oddly it does not crash.

[CHris Hitarori]

Are there maybe some Javascript optimization/acceleration/vectorization methods that only crash on older Macs (processor-specific), and are turned off in the debug build?

The MacBook Pro (2009) I use for Mac OS X 10.6 - 10.11 is a Core2Duo; the MacBook Air (2018) for macOS 14 Sonoma is a Core i5; the Windows 11 machine is also a Core i5.

[Moonchild]

Maybe it's a bug in the clang version used for release builds?

[Basilisk-Dev]

Are there maybe some Javascript optimization/acceleration/vectorization methods that only crash on older Macs (processor-specific), and are turned off in the debug build?

I don't believe that this is processor specific. I get the same crash on an Apple Silicon Mac whereas your machine is using an Intel x86_64 CPU.

Confirmed that this bug does affect me on MacOS Sequoia 15.4.1, Apple Silicon (M3 Pro). Verified the crash occurs on the latest builds of both Pale Moon and Basilisk for Apple Silicon.

[dbsoft]

Confirmed that this bug does affect me on MacOS Sequoia 15.4.1, Apple Silicon (M3 Pro). Verified the crash occurs on the latest builds of both Pale Moon and Basilisk for Apple Silicon.

Interesting, if I can replicate it on my M1 it should be easy to figure out... way better than using that ancient Mac Pro with 10.11

[Lexx Diamond]

wrong thread...

[dbsoft]

Well I was able to debug the crash, but it is in the parser and kind of hard to see what is happening:

Code: Select all

Process 65046 stopped
* thread #11, name = 'JS Helper', stop reason = EXC_BAD_ACCESS (code=2, address=0x1702efc60)
    frame #0: 0x0000000130d21898 XUL`js::frontend::TokenStream::getTokenInternal(this=0x0000000170371cf8, ttp=0x00000001702f07a0, modifier=Operand) at TokenStream.cpp:1385
   1382	
   1383	bool
   1384	TokenStream::getTokenInternal(TokenKind* ttp, Modifier modifier)
-> 1385	{
   1386	    int c;
   1387	    uint32_t qc;
   1388	    Token* tp;
Target 0: (whitestar) stopped.
(lldb) bt
warning: could not execute support code to read Objective-C class data in the process. This may reduce the quality of type information available.

* thread #11, name = 'JS Helper', stop reason = EXC_BAD_ACCESS (code=2, address=0x1702efc60)
  * frame #0: 0x0000000130d21898 XUL`js::frontend::TokenStream::getTokenInternal(this=0x0000000170371cf8, ttp=0x00000001702f07a0, modifier=Operand) at TokenStream.cpp:1385
    frame #1: 0x000000012eda7af0 XUL`js::frontend::TokenStream::getToken(this=0x0000000170371cf8, ttp=0x00000001702f07a0, modifier=Operand) at TokenStream.h:610:16
    frame #2: 0x000000012ee24a9c XUL`js::frontend::Parser<js::frontend::SyntaxParseHandler>::assignExpr(this=0x0000000170371ce0, inHandling=InAllowed, yieldHandling=YieldIsName, tripledotHandling=TripledotProhibited, possibleError=0x0000000000000000, invoked=PredictUninvoked) at Parser.cpp:9113:22
    frame #3: 0x000000012ee0df34 XUL`js::frontend::Parser<js::frontend::SyntaxParseHandler>::expr(this=0x0000000170371ce0, inHandling=InAllowed, yieldHandling=YieldIsName, tripledotHandling=TripledotProhibited, possibleError=0x0000000000000000, invoked=PredictUninvoked) at Parser.cpp:8760:15
    frame #4: 0x000000012ee32690 XUL`js::frontend::Parser<js::frontend::SyntaxParseHandler>::memberElemAccess(this=0x0000000170371ce0, lhs=NodeUnparenthesizedName, yieldHandling=YieldIsName, optionalKind=0) at Parser.cpp:10283:21
    frame #5: 0x000000012ee31c70 XUL`js::frontend::Parser<js::frontend::SyntaxParseHandler>::memberExpr(this=0x0000000170371ce0, yieldHandling=YieldIsName, tripledotHandling=TripledotProhibited, tt=TOK_LB, allowCallSyntax=true, possibleError=0x00000001702f1a70, invoked=PredictUninvoked) at Parser.cpp:10174:26

Edit: Also did ASan/Debug builds on Windows and wasn't able to reproduce. It might be Mac or Apple clang specific but I am having troubles figuring it out. It isn't crashing on any particular line of code, just when transitioning from getToken() to getTokenInternal(). All the variables look good, so I am a little perplexed.

Edit 2: Actually did an ASan Mac Intel build, reproduced the crash and it gave me a different, seemingly later crash location, but still somewhat perplexing:

Code: Select all

Process 11291 stopped
* thread #21, name = 'JS Helper', stop reason = EXC_BAD_ACCESS (code=2, address=0x70000113dfe0)
    frame #0: 0x0000000125d61839 XUL`js::detail::HashTable<js::AtomStateEntry const, js::HashSet<js::AtomStateEntry, js::AtomHasher, js::SystemAllocPolicy>::SetOps, js::SystemAllocPolicy>::lookup(this=0x0000603000067870, l=0x000070000113e260, keyHash=4118753078, collisionBit=0) const at HashTable.h:1396
   1393	    // restriction but we will live with that for now because it's enabled so
   1394	    // rarely.)
   1395	    Entry& lookup(const Lookup& l, HashNumber keyHash, unsigned collisionBit) const
-> 1396	    {
   1397	        MOZ_ASSERT(isLiveHash(keyHash));
   1398	        MOZ_ASSERT(!(keyHash & sCollisionBit));
   1399	        MOZ_ASSERT(collisionBit == 0 || collisionBit == sCollisionBit);
Target 0: (whitestar) stopped.
(lldb) bt
warning: could not execute support code to read Objective-C class data in the process. This may reduce the quality of type information available.

* thread #21, name = 'JS Helper', stop reason = EXC_BAD_ACCESS (code=2, address=0x70000113dfe0)
  * frame #0: 0x0000000125d61839 XUL`js::detail::HashTable<js::AtomStateEntry const, js::HashSet<js::AtomStateEntry, js::AtomHasher, js::SystemAllocPolicy>::SetOps, js::SystemAllocPolicy>::lookup(this=0x0000603000067870, l=0x000070000113e260, keyHash=4118753078, collisionBit=0) const at HashTable.h:1396
    frame #1: 0x0000000125d65241 XUL`js::detail::HashTable<js::AtomStateEntry const, js::HashSet<js::AtomStateEntry, js::AtomHasher, js::SystemAllocPolicy>::SetOps, js::SystemAllocPolicy>::readonlyThreadsafeLookup(this=0x0000603000067870, l=0x000070000113e260) const at HashTable.h:1763:20
    frame #2: 0x0000000125d5817d XUL`js::HashSet<js::AtomStateEntry, js::AtomHasher, js::SystemAllocPolicy>::readonlyThreadsafeLookup(this=0x0000603000067870, l=0x000070000113e260) const at HashTable.h:361:71
    frame #3: 0x0000000125d58149 XUL`js::FrozenAtomSet::readonlyThreadsafeLookup(this=0x0000602000034f70, l=0x000070000113e260) const at jsatom.cpp:67:18
    frame #4: 0x0000000125d5d036 XUL`JSAtom* js::AtomizeChars<char16_t>(js::ExclusiveContext*, char16_t const*, unsigned long, js::PinningBehavior) [inlined] JSAtom* AtomizeAndCopyChars<char16_t>(cx=0x000061600047be80, tbchars=u"i64.cast([0,3948960063]),void 0).then(function(a){return d[35]=a})},function(a){return d[34]=d[35]}]):c.sequence([function(a){return c.storedProcedure(b(\"LSGetThreadParticipantDisplayName\"),d[5],d[4]).then(function(a){return a=a,d[35]=a[0],a})},function(a){return d[36]=c.createArray(),d[38]=(d[36].push(d[35]),d[36]),b(\"LSLocalize\").localizeV2Async(c.i64.cast([0,1249692047]),d[36]).then(function(a){return d[37]=a})},function(a){return d[34]=d[37]}])},function(a){return d[32]=d[34]}]):c.sequence([function(a){return c.i64.eq(d[26],c.i64.cast([0,1e3]))?c.sequence([function(a){return c.storedProcedure(b(\"LSGetViewerFBID\")).then(function(a){return a=a,d[34]=a[0],a})},function(a){return c.i64.eq(d[34],d[4])?c.sequence([function(a){return b(\"LSLocalize\").localizeV2Async(c.i64.cast([0,2326868239]),void 0).then(function(a){return d[36]=a})},function(a){return d[35]=d[36]}]):c.sequence([function(a){return c.storedProcedure(b(\"LSGetThreadParticipantDisplayName\"),d[5],d[4]).then(function(a){return a=a,d[36]=a[0],a})},fun", length=3, pin=DoNotPinAtom) at jsatom.cpp:296:48
    frame #5: 0x0000000125d5cf76 XUL`JSAtom* js::AtomizeChars<char16_t>(cx=0x000061600047be80, chars=u"i64.cast([0,3948960063]),void 0).then(function(a){return d[35]=a})},function(a){return d[34]=d[35]}]):c.sequence([function(a){return c.storedProcedure(b(\"LSGetThreadParticipantDisplayName\"),d[5],d[4]).then(function(a){return a=a,d[35]=a[0],a})},function(a){return d[36]=c.createArray(),d[38]=(d[36].push(d[35]),d[36]),b(\"LSLocalize\").localizeV2Async(c.i64.cast([0,1249692047]),d[36]).then(function(a){return d[37]=a})},function(a){return d[34]=d[37]}])},function(a){return d[32]=d[34]}]):c.sequence([function(a){return c.i64.eq(d[26],c.i64.cast([0,1e3]))?c.sequence([function(a){return c.storedProcedure(b(\"LSGetViewerFBID\")).then(function(a){return a=a,d[34]=a[0],a})},function(a){return c.i64.eq(d[34],d[4])?c.sequence([function(a){return b(\"LSLocalize\").localizeV2Async(c.i64.cast([0,2326868239]),void 0).then(function(a){return d[36]=a})},function(a){return d[35]=d[36]}]):c.sequence([function(a){return c.storedProcedure(b(\"LSGetThreadParticipantDisplayName\"),d[5],d[4]).then(function(a){return a=a,d[36]=a[0],a})},fun", length=3, pin=DoNotPinAtom) at jsatom.cpp:401:12
    frame #6: 0x000000012747145c XUL`js::frontend::TokenStream::getTokenInternal(this=0x00007000011bcde8, ttp=0x000070000113f420, modifier=None) at TokenStream.cpp:1553:24
    frame #7: 0x0000000125c09bb1 XUL`js::frontend::TokenStream::getToken(this=0x00007000011bcde8, ttp=0x000070000113f420, modifier=None) at TokenStream.h:610:16
    frame #8: 0x0000000125c88233 XUL`js::frontend::Parser<js::frontend::SyntaxParseHandler>::memberExpr(this=0x00007000011bcdd0, yieldHandling=YieldIsName, tripledotHandling=TripledotProhibited, tt=TOK_DOT, allowCallSyntax=true, possibleError=0x0000700001140040, invoked=PredictUninvoked) at Parser.cpp:10163:30
    frame #9: 0x0000000125c873e4 XUL`js::frontend::Parser<js::frontend::SyntaxParseHandler>::optionalExpr(this=0x00007000011bcdd0, yieldHandling=YieldIsName, tripledotHandling=TripledotProhibited, tt=TOK_NAME, allowCallSyntax=true, possibleError=0x0000700001140040, invoked=PredictUninvoked) at Parser.cpp:9448:16

[dbsoft]

Starting to think this is a compiler bug or something... I did some more testing with different settings, gives a different crash location... the crash address is always in the stack slightly above where the variables are located for the reported current stack frame.

[Moonchild]

Starting to think this is a compiler bug or something...

That was my thought. Maybe you need to test a few different clang versions and see if there's a pattern. I know that takes a lot of time (I've done that dance myself for 32-bit Windows builds and MSVC) but there's little else to be done. Or maybe you can add some specific compiler flags to clang to reduce its optimization to avoid the culprit.