try { for (a = 0; a < 5; a++) { x = a; } } catch(e) {} (function() { [x](__defineSetter__("", function() {}), /x/) })() crashes js debug and opt shell at js::mjit::JaegerShot near null. Tested on moo tip 9ba6da86ba7b with -m. === Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x0000003b 0x0064156e in ?? () (gdb) bt #0 0x0064156e in ?? () #1 0x001f1223 in js::mjit::JaegerShot (cx=0x809200) at ../methodjit/MethodJIT.cpp:638 #2 0x000b4942 in js::RunScript (cx=0x809200, script=0x50cf80, fun=0x0, scopeChain=0x701000) at jsinterp.cpp:466 #3 0x000b5eb2 in js::Execute (cx=0x809200, chain=0x701000, script=0x50cf80, down=0x0, flags=0, result=0xbffff6c0) at jsinterp.cpp:931 #4 0x00017286 in JS_ExecuteScript (cx=0x809200, obj=0x701000, script=0x50cf80, rval=0xbffff6c0) at ../jsapi.cpp:4637 #5 0x0000c038 in Process (cx=0x809200, obj=0x701000, filename=0x0, forceTTY=0) at ../../shell/js.cpp:533 #6 0x0000ca3b in ProcessArgs (cx=0x809200, obj=0x701000, argv=0xbffff88c, argc=1) at ../../shell/js.cpp:860 #7 0x0000cb54 in shell (cx=0x809200, argc=1, argv=0xbffff88c, envp=0xbffff894) at ../../shell/js.cpp:5038 #8 0x0000cc78 in main (argc=1, argv=0xbffff88c, envp=0xbffff894) at ../../shell/js.cpp:5129 (gdb) x/i $eip 0x64156e: movzwl 0x3a(%edi),%esi (gdb) x/b $edi 0x1: Cannot access memory at address 0x1

Reduced test case: try { x = 0 } catch(e) { } [x]()

Further reduced to: [0]()

This fixes the problem by forcing a class check for every object, and also adds the fully reduced test-case.

Perf results on v8: TEST COMPARISON FROM TO DETAILS ============================================================================= ** TOTAL **: ?? 3948.2ms +/- 1.8% 4004.4ms +/- 2.2% not conclusive: might be *1.014x as slow* ============================================================================= v8: ?? 3948.2ms +/- 1.8% 4004.4ms +/- 2.2% not conclusive: might be *1.014x as slow* crypto: ?? 242.8ms +/- 0.8% 248.6ms +/- 3.1% not conclusive: might be *1.024x as slow* deltablue: ?? 832.4ms +/- 2.3% 848.0ms +/- 3.0% not conclusive: might be *1.019x as slow* earley-boyer: - 520.6ms +/- 3.8% 510.2ms +/- 3.9% raytrace: ?? 327.4ms +/- 2.7% 329.4ms +/- 4.9% not conclusive: might be *1.006x as slow* regexp: - 673.0ms +/- 1.5% 673.2ms +/- 1.7% richards: *1.046x as slow* 656.6ms +/- 1.7% 687.0ms +/- 3.3% significant splay: ?? 695.4ms +/- 2.1% 708.0ms +/- 2.8% not conclusive: might be *1.018x as slow* This can be mitigated by keeping track of known classes. I'll post a bug for that if this patch is accepted.

Comment on attachment 456703 [details] [diff] [review] Quick-fix patch Thanks. Yeah, let's do a follow-up bug on keeping track of object types.

http://hg.mozilla.org/users/danderson_mozilla.com/moo/rev/ed16446defd4 See bug: https://bugzilla.mozilla.org/show_bug.cgi?id=577889

A testcase for this bug was automatically identified at js/src/jit-test/tests/jaeger/bug577646.js.