Closed Bug 1263881 Opened 8 years ago Closed 8 years ago

Crash [@ intrinsic_CreateNamespaceBinding] or Crash [@ js::Shape::slot] or Assertion failure: shape, at vm/SelfHosting.cpp:2095 with parseModule

Categories

(Core :: JavaScript Engine, defect)

x86_64
Linux
defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla48
Tracking Status
firefox48 --- fixed

People

(Reporter: decoder, Assigned: jonco)

Details

(Keywords: assertion, crash, testcase, Whiteboard: [jsbugmon:update])

Crash Data

Attachments

(1 file)

The following testcase crashes on mozilla-central revision 29d5a4175c8b (build with --enable-optimize --enable-posix-nspr-emulation --enable-valgrind --enable-gczeal --disable-tests --disable-debug, run with --fuzzing-safe --ion-offthread-compile=off):

let moduleRepo = {};
setModuleResolveHook(function(module, specifier) {
        return moduleRepo[specifier];
});
moduleRepo['a'] = parseModule("export let a = 1;");
let s = "";
for (let i = 0; i < 100000; i++)
  s += "import * as ns" + i + " from 'a';\n";
let b = parseModule(s);
b.declarationInstantiation();



Backtrace:

Program received signal SIGSEGV, Segmentation fault.
intrinsic_CreateNamespaceBinding (cx=0x7ffff6907800, argc=<optimized out>, vp=0x7fffffffb3d8) at js/src/vm/SelfHosting.cpp:2097
#0  intrinsic_CreateNamespaceBinding (cx=0x7ffff6907800, argc=<optimized out>, vp=0x7fffffffb3d8) at js/src/vm/SelfHosting.cpp:2097
#1  0x00007ffff7fcf006 in ?? ()
[...]
#4  0x0000000000000000 in ?? ()
rax	0x0	0
rbx	0x7ffff6907800	140737330051072
rcx	0x10	16
rdx	0x7fffffffbf20	140737488338720
rsi	0x7ffff10876e8	140737237251816
rdi	0x7ffff7e67100	140737352462592
rbp	0x7fffffffb3d8	140737488335832
rsp	0x7fffffffb310	140737488335632
r8	0x7fffef502000	140737208393728
r9	0x0	0
r10	0x2	2
r11	0x10	16
r12	0x7ffff10876e8	140737237251816
r13	0x7fffffffb350	140737488335696
r14	0x7ffff7e6f1a0	140737352495520
r15	0x7ffff7e6f1a0	140737352495520
rip	0x8bdcbb <intrinsic_CreateNamespaceBinding(JSContext*, unsigned int, JS::Value*)+187>
=> 0x8bdcbb <intrinsic_CreateNamespaceBinding(JSContext*, unsigned int, JS::Value*)+187>:	mov    0x10(%rax),%esi
   0x8bdcbe <intrinsic_CreateNamespaceBinding(JSContext*, unsigned int, JS::Value*)+190>:	lea    0x20(%rbp),%rdx
Assignee: nobody → jcoppeard
This is not specific to modules.  It seems we don't check whether the count of body level lexicals is too big to fit into Bindings::numBodyLevelLexicals_ which is a uint16_t.

The second test case was taking a while to run and some of the time was spent in StaticBlockScope::numVariables.  Implementing this in terms of lastProperty()->slot() as suggested by the comment halved the runtime for an optdebug build on my local machine, although it still takes 7 seconds.
Attachment #8740468 - Flags: review?(shu)
Comment on attachment 8740468 [details] [diff] [review]
bug1263881-too-many-body-level-lexicals

Review of attachment 8740468 [details] [diff] [review]:
-----------------------------------------------------------------

Thanks for the fix. The current Bindings way we track these counts is pretty gross, and hopefully will get better with the rewrite.
Attachment #8740468 - Flags: review?(shu) → review+
https://hg.mozilla.org/mozilla-central/rev/009ffacae51a
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla48
Whiteboard: [jsbugmon:update,bisect] → [jsbugmon:update]
You need to log in before you can comment on or make changes to this bug.