The attached testcase (shell testcase, works with or without -j/-m) causes the assertion on TM tip. With an optimized build, the shell does not terminate. Because the optimized build keeps running and I can't see an obvious reason for that except the bug itself (or maybe I'm overlooking something), I'll nominate this to block. Wes looked at the test case already and says it pre-dates fatvals and is therefore present in 1.9.2 as well (he tested 21e90d198613) Note: Assertion looks similar to 608160, but in that bug, the test case is not pure JS. Found through combined fuzzing (jandem's method fuzzer + LangFuzz).

Other information which may be interesting to whoever tackles this bug - I made the following observations with the help of a debugger based on jsdb: - The loops terminate - debugger hit throw hook, msg = Applying the 'delete' operator to an unqualified name is deprecated; removing this lets us run to completion - debugger hit throw hook, msg = cyclic __proto__ value at line 23: 0021: function f39(o) { 0022: for(var j=0; j<5; j++) { >0023: try { o.__proto__ = o2; } catch(e) {} 0024: } 0025: } Note that o2 is the global object inside f39. If we skip the cyclic prototype complaints, the loop does terminate and we go into f28. f28 then sets the global object's proto to null. After the 'var i' loop terminates, we pop into jsTestDriverEnd(), it terminates, then we delete Function. After we delete Function, we reach the bottom of the script and re-run jsTestDriverEnd(). This final invocation of jsTestDriverEnd() hangs when on 'for (var optionName in x)' -- we never enter the loop body, confirmed by single-js-instruction stepping. The C stack then looks like this (note I am on ~ JS 1.8.2): #0 0xff023a78 in EnumerateNativeProperties(JSContext*, JSObject*, JSObject*, unsigned int, js::HashSet<int, js::DefaultHasher<int>, js::ContextAllocPolicy>&, js::AutoValueVector&) () from /var/surelynx/platform/SunOS-5.10-sun4u-sparc/lib/apr_surelynx/libmozjs.so #1 0xff02499c in Snapshot(JSContext*, JSObject*, unsigned int, js::AutoValueVector&) () from /var/surelynx/platform/SunOS-5.10-sun4u-sparc/lib/apr_surelynx/libmozjs.so #2 0xff0254e0 in GetIterator () from /var/surelynx/platform/SunOS-5.10-sun4u-sparc/lib/apr_surelynx/libmozjs.so #3 0xff025ac8 in js_ValueToIterator () from /var/surelynx/platform/SunOS-5.10-sun4u-sparc/lib/apr_surelynx/libmozjs.so #4 0xff0147ec in js_Interpret () from /var/surelynx/platform/SunOS-5.10-sun4u-sparc/lib/apr_surelynx/libmozjs.so #5 0xff020248 in js_Execute () from /var/surelynx/platform/SunOS-5.10-sun4u-sparc/lib/apr_surelynx/libmozjs.so #6 0xfefcadec in JS_ExecuteScript () from /var/surelynx/platform/SunOS-5.10-sun4u-sparc/lib/apr_surelynx/libmozjs.so #7 0xff1794c0 in initializeModule (cx=0x179e48, module=0x59c808) at gpsee_modules.c:1354 #8 0xff179928 in gpsee_runProgramModule (cx=0x179e48, scriptFilename=<value optimized out>, scriptCode=<value optimized out>, scriptFile=0xfedf337c, script_argv=0x26dc0, script_environ=0x0) at gpsee_modules.c:1618 #9 0x000138cc in prmain (argc=3, argv=0xffbff69c) at gsrdb.c:812 #10 0xfef4dd68 in PR_Initialize () from /usr/lib/mps/libnspr4.so #11 0x00013ca4 in main (argc=3, argv=0xffbff69c) at gsrdb.c:900 A few other tests suggest to me that after "delete Function" runs with the object graph as it is, enumeration gets hosed. I can get the debugger to print Function, then run delete Function, then if I try to print Function again, the debugger hangs. The debugger's print function does an eval in top frame's context and toStrings the result IIRC.

I think this is about as small as you can make the test case for this bug without getting silly. The 'let' at the end isn't really related to the bug, except that I'm using it to trip the resolver. I was able to repro on my pre-fatvals JSAPI, decoder tells me this hangs on tip.

autoBisect shows this is probably related to the following changeset: The first bad revision is: changeset: 47505:0694c8b0d1a6 user: Jeff Walden date: Wed Jun 23 16:57:52 2010 -0700 summary: Add cycle-detection assertions to prototype/parent-setting methods, tighten some nearby code stylistically. (let r () (r))

I think the assertion in debug mode is probably related to that patch, but I'm pretty sure my test changeset (21e90d198613) predates this patch. In release mode (how I tested), what happens is the whole engine hangs, which is the real bug. If I had to wager beer, I'd bet that the regressing patch is actually mid-february or so, when the enumeration code got a shakedown. Gary, is it possible for your auto-bisector to detect hangs? If not, can it apply jeff's patch before compiling?

The testcase from comment 2 in an opt shell from this changeset: changeset: 21062:8c52a9486c8f user: Jim Blandy date: Wed Oct 29 08:29:22 2008 -0700 summary: Bug 97954: Allow SpiderMonkey to be built on its own, or as part of Mozilla. already seems to hang. Though something might have goofed up somewhere.

WOW - this bug is as old as the hills. I just repro'd in JS 1.7.0, JS 1.6.0 and JS 1.5.0 official releases. I could not repro in JS 1.4.1. (If anybody wants help building 1.4.1 on Leopard, let me know, heh) So, I'm not sure if we need to worry about tracking the regressing patch exactly; this regression is verified to be at least 7 years old.

not blocking on a 7 year old bug

I cannot reproduce this anymore on m-c tip but I also cannot get a clear bisect right now. At some point, this turned into a crash (e.g. revision 881c06ebc5ee) with stack overflow [@ js::PropertyTable::search] but I cannot reproduce this, the assert of the infinite loop on any of the JS shells (tried release, beta, aurora and tip). It would be good if someone could verify this is no longer an issue.

Closing as WFM since this has been gone for quite a while now.

Automatically extracted testcase for this bug was committed: https://hg.mozilla.org/mozilla-central/rev/efaf8960a929