770332 - IonMonkey: Assertion failure: obj->unknownProperties(), at jsinfer.cpp:1635

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Christian Holler (:decoder)]

The following testcase asserts on ionmonkey revision 6688ede89a36 (run with --ion -n -m):


function TestCase(n, d, e, a) {}
function reportCompare (expected, actual, description) {
  var testcase = new TestCase("unknown-test-name", description, expected, actual);
}
var status = 'Testing scope after changing obj.__proto__';
function test() {
  let ( actual = [ ]  ) TestCase   .__proto__ = null;
  reportCompare (expect, actual, status);
}
var actual = 'error';
var expect = 'error';
for (i = 0; i < 100000; i++)  {
  test();
}

Comment 1

[David Anderson [:dvander] - inactive, e-mail if emergency]

Brian, it looks like IonMonkey calls TypeSet::WatchObjectStateChange on the callee when inlining a function. The comment just says it's to "trigger invalidation of the caller".

I don't see a similar call in JM+TI, and the call is failing assert that the callee doesn't have unknown properties.

What's the right fix here? Should we just drop the call to WatchObjectStateChange?

Comment 2

[Brian Hackett [Laid off!]]

When inlining one function into another the caller needs to be sensitive to changes in type information in the callee which are not explicitly associated with freeze constraints.  e.g., if a type barrier suddenly appears at an opcode then both the script containing that opcode and any other scripts it was inlined into will need to be recompiled.

JM does this using HasObjectFlags(..., OBJECT_FLAG_UNINLINEABLE), which will trigger recompilation both on one of the changes above and in changes to the UNINLINEABLE flag.  IM doesn't care about the UNINLINEABLE flag, but using WatchObjectStateChange will still catch the above cases, and it will need to be called for each inlined callee.  I think that the fix should be to just not inline callees whose properties are totally unknown.  This will almost never happen with scripted functions, and does so in this case because of the assignment to __proto__.

Comment 3

[David Anderson [:dvander] - inactive, e-mail if emergency]

Attachment: fix

Okay, thanks for the explanation.

Comment 4

[David Anderson [:dvander] - inactive, e-mail if emergency]

http://hg.mozilla.org/projects/ionmonkey/rev/243f0d95967e

Comment 5

[Christian Holler (:decoder)]

A testcase for this bug was automatically identified at js/src/jit-test/tests/ion/bug770332.js.

Comment 6

[Intermittent Failures Robot]

1 failures in 3888 pushes (0.0 failures/push) were associated with this bug in the last 7 days.

Repository breakdown:

• mozilla-beta: 1

Platform and build breakdown:

• linux1804-64-qr: 1
  • debug: 1

For more details, see:
https://treeherder.mozilla.org/intermittent-failures/bugdetails?bug=770332&startday=2022-11-21&endday=2022-11-27&tree=all