The upcoming attached partially reduced (and still reducing) testcase asserts js debug shell on m-c changeset f2ec16a9feea with --ion-eager at Assertion failure: callerObs->hasType(excluded->type), Due to skipped revisions, the first bad revision could be any of: changeset: 122584:b831500ca4be user: David Anderson date: Thu Feb 21 13:52:09 2013 -0800 summary: Prevent GC from occuring during IC linking (bug 837714, r=bhackett). changeset: 122585:437c955ff06d user: Nicolas B. Pierron date: Wed Jan 30 07:41:01 2013 -0800 summary: Bug 796114 - Inline with type-checked arguments. r=h4writer changeset: 122586:5054f997ef77 user: Gregory Szorc date: Thu Feb 21 14:11:54 2013 -0800 summary: Bug 841074 - Statically declare fields on FHR measurements; r=rnewman changeset: 122587:6c126d076b0d user: Phil Ringnalda date: Thu Feb 21 14:26:04 2013 -0800 summary: Back out b831500ca4be (bug 837714) for bustage (it's probably bug 796114 that regressed this) Locking s-s as per nbp, pending his analysis.

The failure happen in addTypeBarrier code, where we assert that the excluded type is included in the caller type set. As Brian mentioned this is supposed to be the case as “the excluded types are the difference of 'callerTypes - calleeTypes'”. As Brian mentioned, one *possible* explanation would be that we have multiple caller type set feeding into the same callee type set. If this assumption is verified, then we should move the assertion condition as a part of the if condition above it. In the worse case, we can just remove this assertion as it only protects against over-guarding the arguments flowing into the inlined callee.

This occurs somewhat frequently on jsfunfuzz, setting as a fuzzblocker.

This assertion happens during the second call to rndElt inside the following function: function makeShapeyValue(d, b) { return rndElt(rndElt([])); } Wrapping one of these call to rndElt (or both) makes the bug go away. The following exclude type appear under gdb: $30 = {next = 0x0, target = 0x1521dd8, type = {data = 5}, singleton = 0x0, singletonId = {asBits = 2}} (gdb) p *callinfo.argsBarrier()->next->next->next->next->next->next->next->next->next $31 = {next = 0x15e8e08, target = 0x1521dd8, type = {data = 140737204485953}, singleton = 0x0, singletonId = {asBits = 2}} (gdb) p *callinfo.argsBarrier()->next->next->next->next->next->next->next->next $32 = {next = 0x15e8e30, target = 0x1521dd8, type = {data = 140737204483585}, singleton = 0x0, singletonId = {asBits = 2}} (gdb) p *callinfo.argsBarrier()->next->next->next->next->next->next->next $33 = {next = 0x15e8e58, target = 0x1521dd8, type = {data = 140737204515585}, singleton = 0x0, singletonId = {asBits = 2}} (gdb) p *callinfo.argsBarrier()->next->next->next->next->next->next $34 = {next = 0x15e8e80, target = 0x1521dd8, type = {data = 140737204482945}, singleton = 0x0, singletonId = {asBits = 2}} (gdb) p *callinfo.argsBarrier()->next->next->next->next->next $35 = {next = 0x15e8ea8, target = 0x1521dd8, type = {data = 140737204516225}, singleton = 0x0, singletonId = {asBits = 2}} (gdb) p *callinfo.argsBarrier()->next->next->next->next $36 = {next = 0x15e8ed0, target = 0x1521dd8, type = {data = 140737204483329}, singleton = 0x0, singletonId = {asBits = 2}} (gdb) p *callinfo.argsBarrier()->next->next->next $37 = {next = 0x15e8ef8, target = 0x1521dd8, type = {data = 140737204515521}, singleton = 0x0, singletonId = {asBits = 2}} (gdb) p *callinfo.argsBarrier()->next->next $38 = {next = 0x15e8f20, target = 0x1521dd8, type = {data = 140737204517569}, singleton = 0x0, singletonId = {asBits = 2}} (gdb) p *callinfo.argsBarrier()->next $39 = {next = 0x15e8f48, target = 0x1521dd8, type = {data = 140737204484673}, singleton = 0x0, singletonId = {asBits = 2}} (gdb) p *callinfo.argsBarrier() $40 = {next = 0x15e8f70, target = 0x1521dd8, type = {data = 7}, singleton = 0x0, singletonId = {asBits = 2}} data == 7 corresponds to AnyObject. data == 5 corresponds to String. Arguments type set expect a String type (?!) (gdb) p /x callerObs->flags $14 = 0x67620 // TYPE_FLAG_PURGED | TYPE_FLAG_CONSTRAINTS_PURGED // 0x76 << TYPE_FLAG_OBJECT_COUNT_SHIFT (?!) // TYPE_FLAG_STRING (gdb) p /x calleeObs->flags $60 = 0x40300 // TYPE_FLAG_CONSTRAINTS_PURGED // 3 << TYPE_FLAG_OBJECT_COUNT_SHIFT

This patch should work assuming TI excluded type might include multiple sources in which case the caller observed type is not the only type contributing to the excluded type. The reason might also come from the fact that the caller observed type and the callee observed type have been rested, but the excluded type are remaining. In which case this patch would be valid too.

FWIW, I get the same failure if I run tests/ecma/Array/15.4.4.4-1.js like this: tests/jstests.py dbg32/js 15.4.4.4-1.js --args="--ion-uses-before-compile=1000" -so (uses-before-compile == 1000 is the default on the IonMonkey branch)

https://hg.mozilla.org/integration/mozilla-inbound/rev/9c97e01125cc Brian, if you fell it is necessary to open another bug to investigate the interaction between the flushing mechanism and the excluded type feel free.

JSBugMon: This bug has been automatically verified fixed.

bug 844452 had the same regression range, will that one be fixed by this as well?