Closed
Bug 1019612
Opened 7 years ago
Closed 7 years ago
Assertion failure: data, at shell/js.cpp:359 with setInterruptCallback
Categories
(Core :: JavaScript Engine, defect)
Tracking
()
RESOLVED
FIXED
mozilla32
Tracking | Status | |
---|---|---|
firefox32 | --- | affected |
People
(Reporter: decoder, Assigned: shu)
References
Details
(Keywords: assertion, testcase, Whiteboard: [jsbugmon:update])
Attachments
(1 file)
2.25 KB,
patch
|
jorendorff
:
review+
|
Details | Diff | Splinter Review |
The following testcase asserts on mozilla-central revision f28005b84ed0 (run with --fuzzing-safe): try { var g = newGlobal(); g.eval("" + function f(d) { g(d); }); g.eval("" + function g(d) { h(d); }); g.eval("" + function h(d) { var i = (0); while (d) interruptIf(d && i++ == 4000); }); setInterruptCallback(function () { dbg.addDebuggee(g); }); g.eval("(" + function () { f(true); } + ")();"); } catch(exc0) {} evaluate("function gamma() { stack = Error().stack; }; gamma();", {newContext: true});
Reporter | ||
Comment 1•7 years ago
|
||
Depending on the timing, it seems that this can also cause crashes on the heap.
status-firefox32:
--- → affected
Whiteboard: [jsbugmon:update,bisect]
Reporter | ||
Updated•7 years ago
|
Whiteboard: [jsbugmon:update,bisect] → [jsbugmon:update]
Reporter | ||
Comment 2•7 years ago
|
||
JSBugMon: Bisection requested, result: === Tinderbox Build Bisection Results by autoBisect === The "good" changeset has the timestamp "20140503173936" and the hash "023fbafabe55". The "bad" changeset has the timestamp "20140503183935" and the hash "a939ec127378". Likely regression window: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=023fbafabe55&tochange=a939ec127378
Reporter | ||
Comment 3•7 years ago
|
||
Bisect is bogus, probably intermittent. Jason, this involves jsdbg2, can you tell who should look at this?
Flags: needinfo?(jorendorff)
Assignee | ||
Comment 6•7 years ago
|
||
There are actually 3 bugs here: 1) We try to DestroyContext after inability to allocate a data. DestroyContext then asserts that the cx it's trying to destroy doesn't have a private data. 2) We forbid creation of new context after servicing an interrupt. 3) We don't reset gServiceInterrupt after servicing the interrupt.
Attachment #8433649 -
Flags: review?(jorendorff)
Assignee | ||
Updated•7 years ago
|
Status: NEW → ASSIGNED
Flags: needinfo?(shu)
QA Contact: shu
Assignee | ||
Comment 7•7 years ago
|
||
Goddammit they should move the QA contact slot somewhere else.
Assignee: nobody → shu
QA Contact: shu
Comment 8•7 years ago
|
||
Comment on attachment 8433649 [details] [diff] [review] Fix setting of gServceInterrupt in js shell. Review of attachment 8433649 [details] [diff] [review]: ----------------------------------------------------------------- Thanks.
Attachment #8433649 -
Flags: review?(jorendorff) → review+
Assignee | ||
Comment 9•7 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/0869b8d56014
Comment 10•7 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/0869b8d56014
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla32
You need to log in
before you can comment on or make changes to this bug.
Description
•