Open classilla opened 3 years ago
This is sufficient to wallpaper the crash, but obviously LinkedIn doesn't work.
The final script appears to either contain or enable the bad code. https://hg.mozilla.org/mozilla-central/rev/884a64b0fba2 doesn't fix it.
The issue is something about aliased variables. The interpreter is running JSOP_GETALIASEDVAR
at the time of crash. I'm not sure if frame 0 is legit, but 1 and 2 seem to be.
I think the actual assertion is in NativeObject.h
in getSlot(uint32_t slot)
(line 838), since ::aliasedVar(
in ScopeObject.h
simply calls straight into it. It's possible we don't have enough slots.
I think the interpreter is calling ::aliasedVar(
in vm/ScopeObject.h
at line 1371, so the backtrace should go
(slotInRange
NativeObject.cpp
line 224)
getSlot
NativeObject.h
line 839
aliasedVar
ScopeObject.h
line 1374
Interpret
Interpreter.cpp
line 3137
With a little extra debugging in slotInRange()
, we see the slot index being requested isn't nuts. There just are very few slots. The backtrace is also a little clearer, though frame 0 is still bogus.
assert imminent: slot 5 f 2 d 0
Assertion failure: slotInRange(slot), at /Volumes/BruceDeuce/src/tenfourfox/js/src/vm/NativeObject.h:839
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000000
0x0d01a5e8 in ReentrancyGuard<js::gc::StoreBuffer> () at ReentrancyGuard.h:39
39 MOZ_ASSERT(!mEntered);
(gdb) bt 5
#0 0x0d01a5e8 in ReentrancyGuard<js::gc::StoreBuffer> () at ReentrancyGuard.h:39
#1 0x0c6a01ec in js::ScopeObject::aliasedVar (this=<value temporarily unavailable, due to optimizations>) at ScopeObject.h:1375
#2 0x0c6ba3c4 in Interpret (cx=0x39360ed0, state=@0xefff4208) at Interpreter.cpp:3137
#3 0x0c6c3da0 in js::RunScript (cx=0x39360ed0, state=@0xefff4208) at Interpreter.cpp:391
#4 0x0c6c41cc in js::Invoke (cx=0x39360ed0, args=@0xefff4298, construct=NO_CONSTRUCT) at Interpreter.cpp:462
(More stack frames follow...)
Two fixed slots. numFixedSlots()
is in vm/Shape.h
line 875.
No dynamic slots. numDynamicSlots()
is in vm/NativeObject.h
line 718.
growSlots()
in vm/NativeObject.cpp
can increase the number of slots.
This is called by updateSlotsForSpan()
in the same file.
How did the shape get created with so few slots? Is it the slot request, or the shape construction?
Crash confirmed to also occur on Intel, so this is not a PPC-specific issue.
(wallpaper didn't hold, script URLs change. any block will have to be at the hostname level)
If you can reproduce this on Intel hardware, getting a trace into pernosco might be a good start to getting someone familiar with the JS engine to look at it...
I'll see if they can generate something. Thank you for the suggestion.
The offending code is
define("extended/services/m3-schema",["exports","ember-cli-pemberly-m3","extended/utils/static-schema","extended/config/environment","deco-recipes/recipes"],function(e,t,n,r,i){Object.defineProperty(e,"__esModule",{value:!0})
e.computeAttributes=o
e.default=void 0
const a=Object.freeze((0,t.normalizeKeys)(n.default))
function o(e){return e.map(e=>"*"===e[0]?e.substring(1):e)}e.default=class extends t.PemberlyM3Schema{init(){this.models=Object.create(a)
super.init.apply(this,arguments)}computeAttributes(e){return o(e)}fetchMicroSchema(e){if(this.isMicroSchemaRegistered(e))return Ember.RSVP.resolve()
const t=`/${r.default.namespace}/deco/schema?decorationId=${i.default[e]}`
return this.store.adapterFor("-ember-m3").ajax(t).then(t=>this.registerMicroSchema(e,t))}setAttribute(e,t,n,r){const i=Ember.PromiseProxyMixin.detect(n)?n.content:n
return super.setAttribute(e,t,i,r)}}})
However, this test case doesn't seem to trigger anything:
e = new Object();
Object.defineProperty(e,"__esModule",{value:!0})
e.computeAttributes=o
e.default=void 0
//const a=Object.freeze((0,t.normalizeKeys)(n.default))
function o(e){return e.map(e=>"*"===e[0]?e.substring(1):e)}
e.default=class extends Array{init(){this.models=Object.create(a)
super.init.apply(this,arguments)}computeAttributes(e){return o(e)}fetchMicroSchema(e){if(this.isMicroSchemaRegistered(e))return Ember.RSVP.resolve()
const t=`/${r.default.namespace}/deco/schema?decorationId=${i.default[e]}`
return this.store.adapterFor("-ember-m3").ajax(t).then(t=>this.registerMicroSchema(e,t))}setAttribute(e,t,n,r){const i=Ember.PromiseProxyMixin.detect(n)?n.content:n
return super.setAttribute(e,t,i,r)}}
e.computeAttributes([]);
Now reproducing on Apple Discussions: https://discussions.apple.com/thread/250091731
https://tenfourfox.tenderapp.com/discussions/problems/9083-crash-on-discussionsapplecom-page
De-minified code from Apple. tldr-demini-js.txt
Looking at isGenerator
in the bytecode emitter. Maybe this has something to do with our stub async await
implementation.
Giving up this cycle, but posting work so far. failed621-diff.txt
This crash is in the JS VM, not in the JIT.
bt full
fails. backtrace.txt