function f() { try { y = w; } catch(y) {} } dis(f) trap(f, 16, '') f() asserts js debug shell on JM changeset aec367836312 with -m, -d, and -a at Assertion failure: retval == !isDummyFrame(), flags: NULL_CLOSURE off op ----- -- main: 00000: try 00001: bindgname "y" 00004: getgname "w" 00009: setgname "y" 00012: pop 00013: goto 32 (19) 00016: enterblock depth 0 {y: 0} <-- trap goes here 00019: exception 00020: setlocalpop 0 00023: leaveblock 1 00028: goto 32 (4) 00031: nop 00032: stop Source notes: ofs line pc delta desc args ---- ---- ----- ------ -------- ------ 0: 1 0 [ 0] newline 1: 2 13 [ 13] xdelta 2: 2 13 [ 0] hidden 3: 2 16 [ 3] catch 5: 2 23 [ 7] catch stack depth 1 7: 2 28 [ 5] hidden 8: 2 31 [ 3] endbrace Exception table: kind stack start end catch 0 1 16

TM bug (but fixed in JM), if there is a TRAP at an exception handler and that handler catches an exception, we called the trap while the frame pointer was still incoherent. In the browser, can traps be inserted at arbitrary opcodes? There are a handful of places where JM assumes opcodes are fused (e.g. MOREITER + IFNE/IFEQ) and I don't know if these are bugs or if the 'trap' function needs more filtering to model what can happen in the browser. http://hg.mozilla.org/projects/jaegermonkey/rev/eb33123abf17

Probably fine, but backed out for now due to problems with patches for bug 673125.