The default bug view has changed. See this FAQ.

crash in firebug-debugger after stepping over an bad object reference

RESOLVED FIXED in mozilla14

Status

()

Core
JavaScript Engine
--
critical
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: Attila Soki, Assigned: bhackett)

Tracking

({crash, reproducible})

11 Branch
mozilla14
x86
Mac OS X
crash, reproducible
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(crash signature)

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

5 years ago
Created attachment 608345 [details]
testcase-1

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:

crash


Expected results:

don't crash
(Reporter)

Updated

5 years ago
Attachment #608345 - Attachment mime type: text/plain → text/html

Updated

5 years ago
Severity: normal → critical
Crash Signature: [@ CrashIfInvalidSlot ]
Keywords: crash

Updated

5 years ago
Assignee: nobody → general
Blocks: 723445
Status: UNCONFIRMED → NEW
Component: Untriaged → JavaScript Engine
Ever confirmed: true
Keywords: reproducible
Product: Firefox → Core
QA Contact: untriaged → general
Luke, this is crashing on CrashIfInvalidSlot called from

  http://hg.mozilla.org/mozilla-central/annotate/5c13fce74f83/js/src/vm/Stack.cpp#l1159

any idea offhand what that means?

Comment 2

5 years ago
Ooh yeah, this may be STR for bug 723445!  I'll investigate.

Comment 3

5 years ago
Wow, this is a most excellent test case; thanks!  I can reproduce locally, I'll look into it hopefully tomorrow.

Comment 4

5 years ago
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.
Attachment #612785 - Flags: review?(bhackett1024)

Comment 5

5 years ago
I forgot, I'll make a shell test-case tomorrow.

Comment 6

5 years ago
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.
Attachment #612785 - Attachment is obsolete: true
Attachment #612785 - Flags: review?(bhackett1024)
Attachment #612912 - Flags: review?(bhackett1024)
Attachment #612912 - Flags: review?(bhackett1024) → review+

Comment 7

5 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/4e2d0a1a9edd
Target Milestone: --- → mozilla14
https://hg.mozilla.org/mozilla-central/rev/4e2d0a1a9edd
Assignee: general → bhackett1024
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.