Last Comment Bug 749697 - Assertion failure: cx->stack.containsSlow(fp)
: Assertion failure: cx->stack.containsSlow(fp)
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: Trunk
: x86 Mac OS X
: -- normal (vote)
: mozilla15
Assigned To: Jason Orendorff [:jorendorff]
:
: Jason Orendorff [:jorendorff]
Mentors:
Depends on: 755808
Blocks: 724862
  Show dependency treegraph
 
Reported: 2012-04-27 10:43 PDT by Panos Astithas [:past]
Modified: 2012-05-18 13:22 PDT (History)
7 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
v1, part 1 - weaken the failing assertion (3.98 KB, patch)
2012-05-16 11:41 PDT, Jason Orendorff [:jorendorff]
luke: review+
Details | Diff | Splinter Review
v1, part 2 - the fix and tests (6.21 KB, patch)
2012-05-16 11:50 PDT, Jason Orendorff [:jorendorff]
luke: review+
Details | Diff | Splinter Review

Description Panos Astithas [:past] 2012-04-27 10:43:24 PDT
STR:

1) Apply patches in bug 723062 and bug 724862 on top of fx-team.
2) Visit http://htmlpad.org/debugger/
3) Open the debugger.
4) Set a breakpoint in line 12 of the debugger/ script.
5) Click on 'Click me!'.
6)In the variables pane, change the value of 'a' to 2 and hit ENTER.
7) Boom.

Crash data:

http://past.pastebin.mozilla.org/1601020
Comment 1 Panos Astithas [:past] 2012-05-08 05:37:33 PDT
Jason, this still happens in fx-team tip, although the line is the previous one:

Assertion failure: cx->stack.containsSlow(fp), at /Users/past/src/fx-team/js/src/jsdbgapi.cpp:557
Comment 2 Jason Orendorff [:jorendorff] 2012-05-10 13:48:52 PDT
The funny thing about this is that the frame must already have passed the assertion in THIS_FRAME() that StackContains(cx, fp). It's not immediately clear what difference there is between the two; I'll look closer tomorrow.
Comment 3 Jason Orendorff [:jorendorff] 2012-05-16 11:00:45 PDT
Status: I reproduced this, filed bug 755808 to make this testable in the shell, wrote a shell test case, figured out why it's crashing, and asked luke what to do. Now trying to actually do that. Here's the test (but you need the patch in bug 755808 to make the test run).


// frame.eval can evaluate code in a frame pushed in another context. Bug 749697.

// In other words, the debugger can see all frames on the stack, even though
// each frame is attached to a particular JSContext and multiple JSContexts may
// have frames on the stack.

var g = newGlobal('new-compartment');
g.eval('function f(a) { debugger; evaluate("debugger;", {newContext: true}); }');

var dbg = new Debugger(g);
var hits = 0;
dbg.onDebuggerStatement = function (frame1) {
    dbg.onDebuggerStatement = function (frame2) {
        assertEq(frame1.eval("a").return, 31);
        hits++;
    };
};

g.f(31);
assertEq(hits, 1);
Comment 4 Jason Orendorff [:jorendorff] 2012-05-16 11:41:59 PDT
Created attachment 624469 [details] [diff] [review]
v1, part 1 - weaken the failing assertion

Weaken this particular assertion. Not a full fix, but a necessary first step.

I decided to use AllFramesIter in the debug-only containsSlow(fp) method because StackSegment::contains(fp) isn't tight enough to use in that assert.
Comment 5 Jason Orendorff [:jorendorff] 2012-05-16 11:50:19 PDT
Created attachment 624472 [details] [diff] [review]
v1, part 2 - the fix and tests
Comment 6 Luke Wagner [:luke] 2012-05-16 11:58:28 PDT
Comment on attachment 624472 [details] [diff] [review]
v1, part 2 - the fix and tests

Review of attachment 624472 [details] [diff] [review]:
-----------------------------------------------------------------

Well that was easy ;)

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