Closed
Bug 1004447
Opened 10 years ago
Closed 10 years ago
Assertion failure: is<T>(), at jsobj.h:1130 or Crash [@ settle]
Categories
(Core :: JavaScript Engine, defect)
Tracking
()
RESOLVED
FIXED
mozilla32
Tracking | Status | |
---|---|---|
firefox32 | --- | affected |
People
(Reporter: decoder, Assigned: shu)
Details
(Keywords: assertion, crash, testcase, Whiteboard: [fuzzblocker] [jsbugmon:update])
Attachments
(2 files)
999 bytes,
text/plain
|
Details | |
4.78 KB,
patch
|
jandem
:
review+
|
Details | Diff | Splinter Review |
The following testcase asserts on mozilla-central revision b227a707080f (run with --fuzzing-safe --ion-eager): var g = newGlobal(); g.debuggeeGlobal = this; g.eval("(" + function () { dbg = new Debugger(debuggeeGlobal); } + ")();"); var myObj = {p1: 'a', } try { with(myObj){ do{ throw value; } while(false); } } catch(e){} if(!(p1 === 1)){}
Reporter | ||
Comment 1•10 years ago
|
||
Reporter | ||
Comment 2•10 years ago
|
||
Likely another one for shu :) Fuzzblocker because this happens fairly often.
status-firefox31:
--- → affected
Flags: needinfo?(shu)
Keywords: crash
Whiteboard: [jsbugmon:update,bisect][fuzzblocker]
Reporter | ||
Updated•10 years ago
|
status-firefox31:
affected → ---
status-firefox32:
--- → affected
Reporter | ||
Updated•10 years ago
|
Whiteboard: [jsbugmon:update,bisect][fuzzblocker] → [fuzzblocker] [jsbugmon:update]
Reporter | ||
Comment 3•10 years ago
|
||
JSBugMon: Bisection requested, result: === Tinderbox Build Bisection Results by autoBisect === The "good" changeset has the timestamp "20140429215012" and the hash "1fe69cad9713". The "bad" changeset has the timestamp "20140429215811" and the hash "10e37b92e195". Likely regression window: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=1fe69cad9713&tochange=10e37b92e195
Assignee | ||
Comment 4•10 years ago
|
||
So all try notes are processed in order until we hit one that forces a return (like a catch/finally block). We should only override the pc if we after returning from HandleExceptionBaseline, we will *definitely* call DebugEpilogue.
Attachment #8416006 -
Flags: review?(jdemooij)
Assignee | ||
Updated•10 years ago
|
Assignee: nobody → shu
Flags: needinfo?(shu)
Comment 5•10 years ago
|
||
Comment on attachment 8416006 [details] [diff] [review] Fix unwound scope override pc logic to only override pc if we need to call the debug epilogue. Review of attachment 8416006 [details] [diff] [review]: ----------------------------------------------------------------- ::: js/src/jit/IonFrames.cpp @@ +660,5 @@ > } else if (iter.isBaselineJS()) { > // It's invalid to call DebugEpilogue twice for the same frame. > bool calledDebugEpilogue = false; > > + // Remember to pc we unwound the scope to. s/to pc/the pc
Attachment #8416006 -
Flags: review?(jdemooij) → review+
Assignee | ||
Comment 6•10 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/2194f49fce4f
Comment 7•10 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/2194f49fce4f
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla32
You need to log in
before you can comment on or make changes to this bug.
Description
•