print(disassemble("-l", function () { for (var i = 0; // line 2 i < 9; // line 3 i++) { // line 4 f(); // line 5 } // line 6 })); 00000: 2 zero 00001: 2 setlocal 0 00004: 2 pop 00005: 2 goto 22 (+17) 00008: 2 trace 0 <--- bogus 00011: 5 callgname "f" 00014: 5 call 0 00017: 5 pop 00018: 4 localinc 0 00021: 4 pop 00022: 3 getlocal 0 00025: 3 int8 9 00027: 3 lt 00028: 3 ifne 8 (-20) 00031: 6 stop JSOP_TRACE gets the line number 2 just because the code immediately before it happens to be on line 2. When stepping through this code in the debugger, your line numbers would go 2 3 2 5 4 3 2 5 4 3 2 5 4 3 2 5 4 3... which makes no sense. It makes more sense for JSOP_TRACE to have the line number of the code immediately after it.

I discovered this while writing tests for the new breakpoint API in jsdbg2 branch (landing soon). In short, a breakpoint on line 2 of the above sample code shouldn't hit more than once, but it hits each time through the loop because of the JSOP_TRACE instruction. So here's the fix. The heuristic is kind of lame, but it works in this case and makes my test pass.

This has landed in jsdbg2, not tracemonkey. http://hg.mozilla.org/users/jblandy_mozilla.com/jsdbg2/rev/13c14153bd63 And the obligatory minutes-later crash fix: http://hg.mozilla.org/users/jblandy_mozilla.com/jsdbg2/rev/9545334d35a3