New issue
Advanced search Search tips

Issue 881764 link

Starred by 2 users

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 2
Type: Bug



Sign in to add a comment

V8 correctness failure in configs: x64,ignition:x64,slow_path

Project Member Reported by ClusterFuzz, Sep 7

Issue description

Detailed report: https://clusterfuzz.com/testcase?key=6230639735734272

Fuzzer: foozzie_js_mutation
Job Type: v8_foozzie
Platform Id: linux

Crash Type: V8 correctness failure
Crash Address: 
Crash State:
  configs: x64,ignition:x64,slow_path
  sources: 290
  
Sanitizer: address (ASAN)

Regressed: https://clusterfuzz.com/revisions?job=v8_foozzie&range=50381:50382

Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=6230639735734272

Issue filed automatically.

See https://github.com/google/clusterfuzz-tools for more information.
 
Project Member

Comment 1 by ClusterFuzz, Sep 7

Labels: Test-Predator-Auto-Owner
Owner: machenb...@chromium.org
Status: Assigned (was: Untriaged)
Automatically assigning owner based on suspected regression changelist https://chromium.googlesource.com/v8/v8/+/0ac7a48ae8c6dbfd1dd4c9e6d5cd4b1a8bd72fe1 ([foozzie] Add slow-path correctness fuzzing variants).

If this is incorrect, please let us know why and apply the Test-Predator-Wrong-CLs label. If you aren't the correct owner for this issue, please unassign yourself as soon as possible so it can be re-triaged.
Components: -Blink>JavaScript Blink>JavaScript>Compiler
Labels: -Pri-1 Pri-2
Owner: ----
Status: Available (was: Assigned)
Some turbofan/ignition error message difference. PTAL compiler folks.

// My minimized repro:
v = {};
v.__proto__ = String.prototype.split;
function foo(func, ...args) {
  try {
    func.apply(undefined, args);
  } catch (e) {
    return "!" + e;
  }
}

print(JSON.stringify(foo(v)));
%OptimizeFunctionOnNextCall(foo);
print(JSON.stringify(foo(v)));


// foozzie output:
# Compared x64,ignition with x64,ignition_turbo
#
# Flags of x64,ignition:
--abort_on_stack_or_string_length_overflow --expose-gc --allow-natives-syntax --invoke-weak-callbacks --omit-quit --es-staging --wasm-num-compilation-tasks=0 --suppress-asm-messages --random-seed 1743351996 --turbo-filter=~ --noopt --liftoff --no-wasm-tier-up
# Flags of x64,ignition_turbo:
--abort_on_stack_or_string_length_overflow --expose-gc --allow-natives-syntax --invoke-weak-callbacks --omit-quit --es-staging --wasm-num-compilation-tasks=0 --suppress-asm-messages --random-seed 1743351996
#
# Difference:
- "!TypeError: Function.prototype.apply was called on [object Object], which is a object and not a function"
+ "!TypeError: func.apply is not a function"
#
# Source file:
none
#
### Start of configuration x64,ignition:
"!TypeError: Function.prototype.apply was called on [object Object], which is a object and not a function"
"!TypeError: Function.prototype.apply was called on [object Object], which is a object and not a function"

### End of configuration x64,ignition
#
### Start of configuration x64,ignition_turbo:
"!TypeError: Function.prototype.apply was called on [object Object], which is a object and not a function"
"!TypeError: func.apply is not a function"

### End of configuration x64,ignition_turbo


Cc: jarin@chromium.org
Owner: bmeu...@chromium.org
Status: Assigned (was: Available)
TurboFan lowers this whole Function.prototype.apply() invocation to a CallWithArrayLike, which essentially boils down to an invocation of the CallFunction builtin. This produces the generic message "func.apply is not a function". The Function.prototype.apply builtin however produces a more sophisticated error message.

The fix here is to probably only do the TurboFan optimization if we know that the receiver is actually callable (which we can get from the preceeding LOAD_IC).

The same problem also affects the Function.prototype.call() inlining I guess.

Sign in to add a comment