Closed Bug 489836 Opened 12 years ago Closed 12 years ago

TM: chiptune causes "Assertion failure: !ti->typeMap.matches(ti_other->typeMap)"

Categories

(Core :: JavaScript Engine, defect, P2)

defect

Tracking

()

VERIFIED FIXED
mozilla1.9.2a1

People

(Reporter: jruderman, Assigned: gal)

References

()

Details

(4 keywords, Whiteboard: fixed-in-tracemonkey)

Attachments

(2 files, 2 obsolete files)

1. Load http://www.chiptune.com/
2. Focus the address bar
3. Press enter (reloading the page)

Result:

Assertion failure: !ti->typeMap.matches(ti_other->typeMap), at /Users/jruderman/tracemonkey/js/src/jstracer.cpp:3562
This is a bad bug. Can you capture the page? Its important that we don't lose the test case.

I don't think we have to hold the beta for this. This should not have catastrophic consequences in OPT builds (maybe a slowdown, but no crash or correctness errors).
Flags: blocking1.9.1?
Priority: -- → P2
Target Milestone: --- → mozilla1.9.1
Attached file captured as zip (obsolete) —
"Not your momma's AJAX" indeed.  Had to hack its XHR function and convince it not to run in "debug" mode despite being loaded from a URL it didn't expect.

Note sure this is complete.  Will try to reduce with Lithium.
Attachment #374368 - Attachment is obsolete: true
Attachment #374415 - Attachment is obsolete: true
Jesse, you are a rock star! ;-)

/be
autoBisect (now working in Linux) shows this is probably related to bug 481793 :

The first bad revision is:
changeset:   25778:ec90dd58f1da
user:        Andreas Gal
date:        Fri Mar 06 17:25:04 2009 -0800
summary:     Better coordination of nested tree recording (481793, r=dmandelin).
Blocks: 481793
Keywords: regression
OS: Mac OS X → All
Hardware: x86 → All
I think #6 is a red herring. It makes us succeed compiling the case earlier. With some modifications the bug would very likely exist earlier too.
The bug is here:

checking nested types 0x30dc70: callee0=O/F this0=O/O argv0=I/I argv1=I/I vars0=I/I global0=B/B global1=I/D  (demotes 1)
checking nested types 0x30ded0: callee0=O/F this0=O/O argv0=I/I argv1=I/D vars0=I/I global0=B/B global1=I/I  (demotes 1)

Trace #1 expects argv1=I and global1=D.
Trace #2 expects argv1=D and global1=I.

A new trace is recorded with argv1=I and global1=I. argv1 is undemotable, so it tries to record argv1=D, global1=I, which already exists. The problem is that findNestedCompatiblePeer isn't realizing that global1=D somewhere else. Or the problem is that global1 was never marked as undemotable in the first place.

I won't be able to attempt a patch until Wednesday in case someone else wants to try.
Yeah, I think the problem is that we start re-recording due to an argc mismatch (bug found by graydon, we can't call an inner tree if argc mismatches), but we already have a tree wih a different argc. The assert is agnostic to that. I will try to provide this with some additional debug output.
argc isn't changing, it's purely types I think
Flags: blocking1.9.1? → blocking1.9.1+
Assignee: general → jim
This is potentially a dup of 2 pending bugs. cc'ing dmandelin.
Actually this doesn't crash for me any more with tip. Might need to bisect.
dmandelin ran into a similar one. We think we know whats going on. I am stealing this. Please steal back if you made progress yourself.
Assignee: jim → gal
Blocks: 491973
Attached patch patchSplinter Review
Attachment #376522 - Flags: review?(dmandelin)
Attachment #376522 - Flags: review?(dvander)
Comment on attachment 376522 [details] [diff] [review]
patch

No longer try to call the tree with the fewest demotes. The better fix for that is to avoid the floating point math in the outer tree, which the new oracle demote patch does.
Duplicate of this bug: 491973
Attachment #376522 - Flags: review?(dvander) → review+
Whiteboard: checkin-needed
http://hg.mozilla.org/tracemonkey/rev/df0f692ad0c9
Whiteboard: checkin-needed → fixed-in-tracemonkey
Attachment #376522 - Flags: review?(dmandelin) → review+
Comment on attachment 376522 [details] [diff] [review]
patch

Yes, I didn't expect to see this change simplify the code, so that's great.
It seems that our correctness depends on the oracle never giving false negatives.  That is, if the JIT marks a given slot as undemotable, then if the oracle doesn't always call that slot undemotable, then we assert.  (Naturally, false positives are benign.)

So the oracle isn't just an optimization: it must give certain answers in some circumstances.
http://hg.mozilla.org/mozilla-central/rev/df0f692ad0c9
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Verified fixed with testcase in comment 0 with the following debug builds:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre)
Gecko/20090522 Minefield/3.6a1pre ID:20090522133810

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1pre)
Gecko/20090522 Shiretoko/3.5pre ID:20090522153422
Status: RESOLVED → VERIFIED
Target Milestone: mozilla1.9.1 → mozilla1.9.2a1
Depends on: 496482
Automatically extracted testcase for this bug was committed:

https://hg.mozilla.org/mozilla-central/rev/efaf8960a929
Flags: in-testsuite+
You need to log in before you can comment on or make changes to this bug.