This crashes in Runtime_InitializeVarGlobal (the language mode isn't a Smi). Might be related to recent scope changes. Toon, can you please triage further?

The bug is, afaict, that we'll crankshaft/OSR which will merge the constant 0 for a with the constant 0 for the language mode passed into the runtime call. a expects to be in double representation, so it'll make the language mode also double 0. Here's a reduced repro:


// Make a double 0
var o = {a:1.5};
o.a = 0;
var a = o.a;

// Force OSR
for (var i = 0; i < 80000; i++) {
    a.hasOwnProperty(5);
}

// Runtime call to initializeVarGlobal
var K3 = 0;


I see 2 options: either split initializeVarGlobal into initializeVarGlobal_Sloppy/_Strict, or make it accept any int32 encoding (also double).

Is this specific to this case? Wouldn't this be a problem for any runtime call that does CHECK(args[i]->IsSmi())?

Anything where the incoming value comes from an ast node NumberLiteral, and crankshaft knows about it. Previously many calls were manually constructed in handwritten assembler...

As for the options, then, it seems it's more like one of:

1. Stop taking integer arguments in runtime calls.
2. Replace all Smi -> int converstion with Number -> int conversion (maybe with validation of integer-ness in the double case) in runtime calls that take integers.
3. Never do such runtime calls from the AST or from JS builtins

(2) seems like the most scalable change. (3) seems brittle. No idea how tractable (1) is, my guess is it would be a lot of work.

Unassigning from myself for now, as I'm not sure I'm the right person to fix this in general.

ClusterFuzz has detected this issue as fixed in range 40591:40592.

Detailed report: https://cluster-fuzz.appspot.com/testcase?key=6388204683132928

Fuzzer: decoder_langfuzz
Job Type: linux_asan_d8
Platform Id: linux

Crash Type: CHECK failure
Crash Address: 
Crash State:
  args[1]->IsSmi() in runtime-scopes.cc
  
Regressed: V8: r37703:37704
Fixed: V8: r40591:40592

Minimized Testcase (6.73 Kb): https://cluster-fuzz.appspot.com/download/AMIfv9411K1j0U9MUn8JJ_8FeLdL1UK_JSx4vJ_wTbyakpvPbeeMO6wMooPNN-NNDKzOEuoyN7_DtOLpjPefdTb1Mgi8rAHZOdxakCTMTo84sltbZSHcKfAJYaVKlpmZ8kU2GjdCRA60ae4lMafgoCPfBj1RwgFeWw?testcase_id=6388204683132928

See https://dev.chromium.org/Home/chromium-security/bugs/reproducing-clusterfuzz-bugs for more information.

If you suspect that the result above is incorrect, try re-doing that job on the test case report page.

ClusterFuzz testcase is verified as fixed, closing issue.

If this is incorrect, please add ClusterFuzz-Wrong label and re-open the issue.

Pretty sure this is still a bug.

Removing EditIssue view restrictions from ClusterFuzz filed bugs. If you believe that this issue should still be restricted, please reapply the label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Re #5: Yes, I agree, (2) is the most scalable approach and there already are helpers like {CONVERT_INT32_ARG_CHECKED} that do exactly that.

Re #9: Nah, I am pretty sure ClusterFuzz was right about this particular issue being fixed. The change referenced by ClusterFuzz contains a hunk that modifies the {CONVERT_LANGUAGE_MODE_ARG_CHECKED} to no longer assume values being {IsSmi} but instead being {IsNumber}, see here:

https://chromium.googlesource.com/v8/v8/+/2bd7464ec1efc9eb24a38f7400119a5f2257f6e6%5E%21/#F3

If we want to track a broader issue (e.g. "all runtime functions should be made SMI/HeapNumber resilient") then please file a new issue that is not linked with ClusterFuzz reports and hence will not show up on the ClusterFuzz sheriff queue. Marking this one as fixed.

We have made a bunch of changes on ClusterFuzz side, so resetting ClusterFuzz-Wrong label.