Last Comment Bug 770332 - IonMonkey: Assertion failure: obj->unknownProperties(), at jsinfer.cpp:1635
: IonMonkey: Assertion failure: obj->unknownProperties(), at jsinfer.cpp:1635
: assertion, testcase
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: Other Branch
: x86_64 Linux
-- major (vote)
: ---
Assigned To: David Anderson [:dvander]
: Jason Orendorff [:jorendorff]
Depends on:
Blocks: langfuzz IonFuzz
  Show dependency treegraph
Reported: 2012-07-02 14:12 PDT by Christian Holler (:decoder)
Modified: 2013-01-14 08:01 PST (History)
8 users (show)
choller: in‑testsuite+
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

fix (1.50 KB, patch)
2012-07-12 15:44 PDT, David Anderson [:dvander]
bhackett1024: review+
Details | Diff | Splinter Review

Description User image Christian Holler (:decoder) 2012-07-02 14:12:51 PDT
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++)  {
Comment 1 User image David Anderson [:dvander] 2012-07-11 19:07:21 PDT
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 User image Brian Hackett (:bhackett) 2012-07-11 20:13:34 PDT
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 User image David Anderson [:dvander] 2012-07-12 15:44:53 PDT
Created attachment 641634 [details] [diff] [review]

Okay, thanks for the explanation.
Comment 4 User image David Anderson [:dvander] 2012-07-16 14:13:14 PDT
Comment 5 User image Christian Holler (:decoder) 2013-01-14 08:01:58 PST
A testcase for this bug was automatically identified at js/src/jit-test/tests/ion/bug770332.js.

Note You need to log in before you can comment on or make changes to this bug.