Closed Bug 1019612 Opened 5 years ago Closed 5 years ago

Assertion failure: data, at shell/js.cpp:359 with setInterruptCallback

Categories

(Core :: JavaScript Engine, defect, critical)

x86
Linux
defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla32
Tracking Status
firefox32 --- affected

People

(Reporter: decoder, Assigned: shu)

References

(Blocks 1 open bug)

Details

(Keywords: assertion, testcase, Whiteboard: [jsbugmon:update])

Attachments

(1 file)

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});
Depending on the timing, it seems that this can also cause crashes on the heap.
Whiteboard: [jsbugmon:update,bisect]
Whiteboard: [jsbugmon:update,bisect] → [jsbugmon:update]
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
Bisect is bogus, probably intermittent. Jason, this involves jsdbg2, can you tell who should look at this?
Flags: needinfo?(jorendorff)
That'll be me. Is there a stack?
Flags: needinfo?(jorendorff)
NI myself as a reminder.
Flags: needinfo?(shu)
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)
Status: NEW → ASSIGNED
Flags: needinfo?(shu)
QA Contact: shu
Goddammit they should move the QA contact slot somewhere else.
Assignee: nobody → shu
QA Contact: shu
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+
https://hg.mozilla.org/mozilla-central/rev/0869b8d56014
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla32
Depends on: 1123394
You need to log in before you can comment on or make changes to this bug.