Closed Bug 849778 Opened 11 years ago Closed 8 years ago

IonMonkey: Assertion failure: !frame.asStackFrame()->runningInIon(), at vm/ArgumentsObject.cpp:28

Categories

(Core :: JavaScript Engine, defect)

x86
Linux
defect
Not set
critical

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: decoder, Unassigned)

References

Details

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

The following testcase asserts on mozilla-central revision eccf45749400 (run with --ion-eager):


function g() {}
var max = 400; 
function f(b) {
    if (b) {
        f(b - 1);
        g = {
            apply:toString
        };
    }
    g.apply(null, arguments);
}
f(max - 1);
Blocks: IonFuzz
Whiteboard: [jsbugmon:update,bisect]
Whiteboard: [jsbugmon:update,bisect] → [jsbugmon:update]
JSBugMon: Bisection requested, result:
autoBisect shows this is probably related to the following changeset:

The first bad revision is:
changeset:   121232:979de88d617d
user:        Nicolas B. Pierron
date:        Thu Feb 07 14:35:05 2013 -0800
summary:     Bug 835499 - Remove the runningInIon flag at the end of convertFrame. r=dvander

This iteration took 102.325 seconds to run.
Nicolas, can you take a look based on comment 1? Thanks.
Flags: needinfo?(nicolas.b.pierron)
Whiteboard: [jsbugmon:update] → [jsbugmon:]
JSBugMon: Cannot process bug: Unknown exception (check manually)
Whiteboard: [jsbugmon:] → [jsbugmon:update]
Whiteboard: [jsbugmon:update] → [jsbugmon:update,ignore]
JSBugMon: The testcase found in this bug no longer reproduces (tried revision f20b0ce9e528).
Whiteboard: [jsbugmon:update,ignore] → [jsbugmon:bisectfix]
Whiteboard: [jsbugmon:bisectfix] → [jsbugmon:]
JSBugMon: Fix Bisection requested, result:
autoBisect shows this is probably related to the following changeset:

The first good revision is:
changeset:   127409:b942f88d95c5
parent:      127408:73009fa09525
parent:      124325:eccf45749400
user:        Jan de Mooij
date:        Mon Mar 11 15:18:12 2013 +0100
summary:     Merge from mozilla-central.

Not all ancestors of this changeset have been checked.
Use bisect --extend to continue the bisection from
the common ancestor, cb432984d5ce.

This iteration took 152.636 seconds to run.

Oops! We didn't test rev 73009fa09525, a parent of the blamed revision! Let's do that now.
We did not test rev 73009fa09525 because it is not a descendant of either eccf45749400 or 475dc5f51bdb.
Rev 73009fa09525: Updating... Compiling... Testing... [Uninteresting] It didn't crash. (0.056 seconds)
good (not interesting) 
Bisect lied to us! Parent rev 73009fa09525 was also good!

Perhaps we should expand the search to include the common ancestor of the blamed changeset's parents.
The common ancestor of 73009fa09525 and eccf45749400 is cb432984d5ce.
Rev cb432984d5ce: Updating... Compiling... Testing... Exit status: CRASHED signal 11 (SIGSEGV) (0.056 seconds)
bad (interesting) 
The following line is still under testing:
Try setting -s to cb432984d5ce, and -e to 475dc5f51bdb, and re-run autoBisect.
This probably got fixed by the BaselineCompiler landing, but bisection all the branches has gotten `hg bisect` confused.
I meant "bisection of all the merges".
Bug 835499 was a problem in the bailout of self-hosted JS functions, I did not investigated this issue yet, but the introduction of the baseline compiler made the bailouts go from Ion->Interpreter to Ion->Baseline instead.

This is what the merge appear as fixing this issue.  I would bet that this issue would still be reproducible when baseline is disabled.  Hopefully, Jan is going to remove this option (see Bug 868431) as he removes the ability to bailout to the interpreter from IonMonkey.  Which mean that this bug would not exists any more, as the baseline compiler shares the same stack layout as the interpreter.

Does this bug might still affect people who disable the baseline compiler without disabling IonMonkey?
Flags: needinfo?(nicolas.b.pierron)
Assignee: general → nobody
Comment 8 was probably correct. Test case WFM now with various flags.
Status: NEW → RESOLVED
Closed: 8 years ago
Comment 8 is private: false
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.