The following testcase crashes on mozilla-central revision d374d16cbb25 (build with --enable-optimize --enable-posix-nspr-emulation --enable-valgrind --enable-gczeal --disable-tests --enable-debug, run with --fuzzing-safe --ion-offthread-compile=off --ion-eager --thread-count=2): lfcode = Array() lfcode.push("5") lfcode.push("") lfcode.push("3") lfcode.push("oomTest(()=>{gc()})") while (true) { file = lfcode.shift() loadFile(file) } function loadFile(lfVarx) { try { if (lfVarx.length != 1) switch (lfRunTypeId) { case 3: function newFunc(x) Function(x)() newFunc(lfVarx) case 5: for (lfLocal in this); } isNaN(); lfRunTypeId = parseInt(lfVarx); } catch (lfVare) {} } Backtrace: Program received signal SIGSEGV, Segmentation fault. 0x0000000000a2a25f in SetNonexistentProperty (cx=cx@entry=0x7ffff6907400, obj=..., obj@entry=..., id=..., id@entry=..., v=..., receiver=receiver@entry=..., qualified=js::Qualified, result=...) at js/src/vm/NativeObject.cpp:2159 #0 0x0000000000a2a25f in SetNonexistentProperty (cx=cx@entry=0x7ffff6907400, obj=..., obj@entry=..., id=..., id@entry=..., v=..., receiver=receiver@entry=..., qualified=js::Qualified, result=...) at js/src/vm/NativeObject.cpp:2159 #1 0x0000000000a2ace0 in js::NativeSetProperty (cx=0x7ffff6907400, obj=..., id=..., value=..., receiver=..., qualified=qualified@entry=js::Qualified, result=...) at js/src/vm/NativeObject.cpp:2339 #2 0x00000000009e2ddd in js::SetProperty (cx=<optimized out>, obj=..., id=..., v=..., receiver=..., result=...) at js/src/vm/NativeObject.h:1450 #3 0x00000000009e634b in js::SetNameOperation (cx=0x7ffff6907400, script=<optimized out>, pc=<optimized out>, scope=..., val=...) at js/src/vm/Interpreter-inl.h:297 #4 0x0000000000c35388 in js::jit::DoSetPropFallback (cx=0x7ffff6907400, frame=0x7fffffffcdb8, stub_=<optimized out>, lhs=..., rhs=..., res=...) at js/src/jit/BaselineIC.cpp:7646 #5 0x00007ffff7fea09f in ?? () #6 0x0000000000000000 in ?? () rax 0x0 0 rbx 0x7ffff6907400 140737330050048 rcx 0x7ffff6ca53cd 140737333842893 rdx 0x0 0 rsi 0x7ffff6f7a9d0 140737336814032 rdi 0x7ffff6f791c0 140737336807872 rbp 0x7fffffffc7e0 140737488340960 rsp 0x7fffffffc780 140737488340864 r8 0x7ffff7fe0780 140737354008448 r9 0x6372732f736a2f6c 7165916604736876396 r10 0x7fffffffc540 140737488340288 r11 0x7ffff6c27960 140737333328224 r12 0x7fffffffc9d0 140737488341456 r13 0x7fffffffc9b0 140737488341424 r14 0x7ffff6907400 140737330050048 r15 0x7fffffffc880 140737488341120 rip 0xa2a25f <SetNonexistentProperty(JSContext*, js::HandleNativeObject, JS::HandleId, JS::HandleValue, JS::HandleValue, js::QualifiedBool, JS::ObjectOpResult&)+175> => 0xa2a25f <SetNonexistentProperty(JSContext*, js::HandleNativeObject, JS::HandleId, JS::HandleValue, JS::HandleValue, js::QualifiedBool, JS::ObjectOpResult&)+175>: movl $0x86f,0x0 0xa2a26a <SetNonexistentProperty(JSContext*, js::HandleNativeObject, JS::HandleId, JS::HandleValue, JS::HandleValue, js::QualifiedBool, JS::ObjectOpResult&)+186>: callq 0x4a5040 <abort()> This bug isn't intermittent for me but I can't remove the while loop nor anything else to reduce it further which is quite strange.

JSBugMon: Bisection requested, result: autoBisect shows this is probably related to the following changeset: The first bad revision is: changeset: https://hg.mozilla.org/mozilla-central/rev/9c365490d4ce user: Jon Coppeard date: Tue Oct 13 13:37:07 2015 +0100 summary: Bug 1212469 - Make oomTest() into a shell function r=nbp This iteration took 258.162 seconds to run.

I can't reproduce this. decoder, do you have any other testcases that look like they might be the same problem?

I can reproduce this but I haven't been able to find out what's going wrong. What's happening is that we Ion-compile the main script and execute it, up until the successful completion of oomTest(). Then the main script gets bailed out to baseline and executes a SETGNAME op for |file = lfcode.shift()|. The attempts to set the property in the global lexical scope object, finds out it's missing, and asserts in SetNonexistentProperty() because the scope is a BlockObject. It seems to me that the property should already exist in the lexical scope at this point because we've already been round the while loop several times. I was able to reduce the range of allocation points at which oomTest() simulates failure. There are a couple in Ion compilation and three while sweeping type information but no smoking gun relating to the missing property.

It sounds like rr might be a good avenue to try.

The problem is that IonBuilder::testGlobalLexicalBinding() always returns the global lexical object if no type information is available. The |oomTest()| causes GC which leads to no type information being available, and when we then compile a SETGNAME for |file = lfcode.shift()| we end up with a SetPropertyIC that tries to write a property on the global lexical scope rather than the global, which asserts since the property is not present. The patch makes testGlobalLexicalBinding() work the same if there is no type information, except it fails if it needs to freeze the typeset for the non-existence of the property on the global lexical scope.

Comment on attachment 8704647 [details] [diff] [review] bug1215600-global-lexical Review of attachment 8704647 [details] [diff] [review]: ----------------------------------------------------------------- Nice debugging. Thanks for the fix!