Last Comment Bug 738279 - crash in firebug-debugger after stepping over an bad object reference
: crash in firebug-debugger after stepping over an bad object reference
: crash, reproducible
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: 11 Branch
: x86 Mac OS X
-- critical (vote)
: mozilla14
Assigned To: Brian Hackett (:bhackett)
: Jason Orendorff [:jorendorff]
Depends on:
Blocks: 723445
  Show dependency treegraph
Reported: 2012-03-22 08:54 PDT by Attila Soki
Modified: 2012-04-10 08:41 PDT (History)
6 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

testcase-1 (1.20 KB, text/html)
2012-03-22 08:54 PDT, Attila Soki
no flags Details
fix forced return (792 bytes, patch)
2012-04-05 19:48 PDT, Luke Wagner [:luke]
no flags Details | Diff | Splinter Review
fix forced return (1.69 KB, patch)
2012-04-06 09:52 PDT, Luke Wagner [:luke]
bhackett1024: review+
Details | Diff | Splinter Review

Description User image Attila Soki 2012-03-22 08:54:51 PDT
Created attachment 608345 [details]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20100101 Firefox/11.0
Build ID: 20120312181643

Steps to reproduce:

Debugged the attached testcase-1.

1. open Firebug, enable the script tab and load the attached testcase-1
2. debugger stops at breakpoint (A), (reload the site if the debugger don't stops)
3. click step over
4. now the cursor is at line (B), click step over again
5. now, hover the sourcecode in the firebug window at the bottom
6. crash

Firefox 11.0 + Firebug 1.9.1
Firefox nightly 14.0a1 (2012-03-22) + Firebug 10.0.a5

Crash ID: bp-1de8762a-de1f-4850-976d-afc0e2120322

Actual results:


Expected results:

don't crash
Comment 1 User image David Mandelin [:dmandelin] 2012-04-04 18:22:39 PDT
Luke, this is crashing on CrashIfInvalidSlot called from

any idea offhand what that means?
Comment 2 User image Luke Wagner [:luke] 2012-04-04 18:39:17 PDT
Ooh yeah, this may be STR for bug 723445!  I'll investigate.
Comment 3 User image Luke Wagner [:luke] 2012-04-05 19:03:18 PDT
Wow, this is a most excellent test case; thanks!  I can reproduce locally, I'll look into it hopefully tomorrow.
Comment 4 User image Luke Wagner [:luke] 2012-04-05 19:48:00 PDT
Created attachment 612785 [details] [diff] [review]
fix forced return

Ah, I see the bug.  The problem is that forced_return (jumped to by the debugger) is setting the stack depth to 0, but leaving pc pointing to the JSOP_CALL which the debugger interrupted.  Thus, when the ScriptDebugEpilogue runs, js_ReconstructStackDepth(pc) is not equal to the actual stack depth and we go touching invalid memory (the next frame).

Thank you again Attila for taking the time to create a reproducible test-case.  It was certainly invaluable!  We've been trying to track down reports of this crash for a while and between this and bug 723445, I bet we have it fixed.
Comment 5 User image Luke Wagner [:luke] 2012-04-05 19:48:24 PDT
I forgot, I'll make a shell test-case tomorrow.
Comment 6 User image Luke Wagner [:luke] 2012-04-06 09:52:05 PDT
Created attachment 612912 [details] [diff] [review]
fix forced return

This patch adds a shell testcase.  In finding a testcase, I can see why this was relatively hard to hit: you have to trap on a 'call' instruction, force an early return, then, in the leave-frame hook for that function, you need to runs some code that inspects the stack via StackIter.  Phew.

Note You need to log in before you can comment on or make changes to this bug.