(function() { ({ c: (function f() { var s = "" eval(s.c) f() })() }) })() crashes js debug shell (tested with a threadsafe 64-bit debug build) on m-i changeset a63f47fcbe98 with --baseline-eager at a weird memory address. Due to skipped revisions, the first bad revision could be any of: changeset: 140578:675ea8aeb804 user: Nikhil Marathe date: Tue Jul 30 13:52:27 2013 -0700 summary: Bug 884897 - Convert SimplePush to WebIDL. r=khuey changeset: 140579:eb89f19070ae user: Terrence Cole date: Fri Jul 05 16:54:39 2013 -0700 summary: Bug 889682 - Use LifoAlloc to back the StoreBuffer's allocation; r=billm

I've been investigating this issue. It seems the function f() calls itself recursively several thousand times, after which a minor GC happens. Then it crashes dereferencing 0x2b2b2b2b2b2b which it has read from 0x7ffff57fffb0. So I think it's trying to access a nursery object which has been collected. There was an IC on the stack during the crash, although the stack is unparseable by GDB, I guess as we're in JIT code. So I instrumented some ICs and found that NameIC::update() is called for every recursion, and that the value of the scopeChain handle in the last call is 0x7ffff57fffb0. So my current theory is that we're not marking this when we should be. In fact I can see this value on the stack in MarkActualArguments() after the last argument that we mark. However I don't know how marking these is meant to work. Looking at the test case, it seems similar to those in bug 906242 and bug 906236, so it may be the same underlying cause.

This is the same issue as bug 906236. A DeclEnvObject is allocated tenured, and its slots are initialized without post barriers. A CallObject is then allocated, triggering a minor GC, and the slots in the DeclEnvObject become pointers into swept nursery space. I've verified that the patch posted there fixes this issue too.