Private Shizo

🔥[Issue 1459254]Debug check failed: !object->IsUninitialized(isolate)(Turbofan & Maglev) There is a legitimate race condition here (both in Maglev and Turbofan) between the main thread adding a property to an object (which is a prototype of another object), and the compiler thread looking up the prototype chain. The main thread first transitions the object's map to have the extra property, and only then sets the value of that property, so the race is: 1️⃣Main: Extend object (i.e. assign uninitialized to field), set object map to new map with 1 more property 2️⃣Compiler: Read map 3️⃣Compiler: Read constant field value (reads uninitialized) 4️⃣Main: Write new field value (overwrites uninitialized) Usually a main thread write after a compiler read would invalidate a constness dependency, but in this case this is an initialising write, so the field is still constant after being "overwritten". ⚠️This is hard to repro because the timing between the main thread operations (1 and 4 above) is very tight. PoC (arguments: --maglev --jit-fuzzing --expose-gc):

function foo() {
            const o100 = {
                "foo": 1,
            };

            const obj1 = Object.create(o100);
            obj1.a = obj1;

            const obj2 = Object.create(obj1);
            obj2.a;

            function f112() {
                const v113 = obj2.foo;
                v113 & v113;
                return v113;
                                                }

            for (let j = 0; j < 10; j === j, j++) {
                f112();
            }

            obj1.foo = null;
            gc();
                  //obj1.foo;

}
for(let i=0;i<15; i++)
    foo();

🛡Fixed in commit: a6dd6c9 "[heaprefs] Handle uninitialized value race" Handle a race of the compiler reading an object which is undergoing a transitioning store on the main thread.