Cameron Kaiser

This is sufficient to wallpaper the crash, but obviously LinkedIn doesn't work. [wallpaper.txt](https://github.com/classilla/tenfourfox/files/5185791/wallpaper.txt)

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...

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`...

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...

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.