// Bisect points to https://chromium.googlesource.com/v8/v8/+/f93b27e639cca6a93ce9b6c535ece9b6cc399a01
// Though, that CL was reverted shortly after, I don't trust the bisect...

// Simple repro:

function foo() {
  "use asm";
  function bar() {
    -v;
  }
  return { bar: bar };
}
v = foo();
v.__defineGetter__("toString", function() { return {}; });
 1 / v.bar();

// Output:
# Compared x64,ignition with x64,ignition_turbo_opt
#
# Flags of x64,ignition:
--abort_on_stack_overflow --expose-gc --allow-natives-syntax --invoke-weak-callbacks --omit-quit --es-staging --random-seed 1824208954 --ignition --turbo-filter=~ --hydrogen-filter=~ --nocrankshaft
# Flags of x64,ignition_turbo_opt:
--abort_on_stack_overflow --expose-gc --allow-natives-syntax --invoke-weak-callbacks --omit-quit --es-staging --random-seed 1824208954 --ignition-staging --turbo --always-opt
#
# Difference:
- /usr/local/google/home/machenbach/v8/v8/repro.js:4: TypeError: Cannot convert object to primitive value
+ /usr/local/google/home/machenbach/v8/v8/repro.js:3: TypeError: Cannot convert object to primitive value
#
# Source file:
none
#
### Start of configuration x64,ignition:
/usr/local/google/home/machenbach/v8/v8/repro.js:4: TypeError: Cannot convert object to primitive value
    -v;
    ^



### End of configuration x64,ignition
#
### Start of configuration x64,ignition_turbo_opt:
/usr/local/google/home/machenbach/v8/v8/repro.js:3: TypeError: Cannot convert object to primitive value
  function bar() {
              ^



### End of configuration x64,ignition_turbo_opt

The actual CL is https://codereview.chromium.org/2725053007

That explains it, then the auto-bisect didn't notice the gap between revert and reland. On who's plate should this issue be? Rather wasm or compiler? No high prio as it's an error message difference only.

The culprit seems to be "--always-opt", tested with node v7.6.0 (V8 5.5).

C:\Users\jie\Downloads\v8>"C:\Program Files\Nodejs\node" --version
v7.6.0

C:\Users\jie\Downloads\v8>"C:\Program Files\Nodejs\node" valueof.js
C:\Users\jie\Downloads\v8\valueof.js:4
    -v;
    ^

TypeError: Cannot convert object to primitive value
    at Object.bar (C:\Users\jie\Downloads\v8\valueof.js:4:5)
    at Object.<anonymous> (C:\Users\jie\Downloads\v8\valueof.js:10:8)
    at Module._compile (module.js:571:32)
    at Object.Module._extensions..js (module.js:580:10)
    at Module.load (module.js:488:32)
    at tryModuleLoad (module.js:447:12)
    at Function.Module._load (module.js:439:3)
    at Module.runMain (module.js:605:10)
    at run (bootstrap_node.js:422:7)
    at startup (bootstrap_node.js:143:9)

C:\Users\jie\Downloads\v8>"C:\Program Files\Nodejs\node" --always-opt valueof.js

C:\Users\jie\Downloads\v8\valueof.js:3
  function bar() {
              ^

TypeError: Cannot convert object to primitive value
    at Object.bar (C:\Users\jie\Downloads\v8\valueof.js:3:15)
    at Object.<anonymous> (C:\Users\jie\Downloads\v8\valueof.js:10:8)
    at Module._compile (module.js:571:32)
    at Object.Module._extensions..js (module.js:580:10)
    at Module.load (module.js:488:32)
    at tryModuleLoad (module.js:447:12)
    at Function.Module._load (module.js:439:3)
    at Module.runMain (module.js:605:10)
    at run (bootstrap_node.js:422:7)
    at startup (bootstrap_node.js:143:9)

C:\Users\jie\Downloads\v8>

Issue 705324 has been merged into this issue.

Does not look wasm-related, as it's invalid asm.js code, hence does not use the wasm pipeline anyway.

Yes - this is fullcode vs. ignition. We'll track this as low prio and probably won't fix.

ClusterFuzz has detected this issue as fixed in range 44658:44659.

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

Fuzzer: foozzie_js_mutation
Job Type: v8_foozzie
Platform Id: linux

Crash Type: V8 correctness failure
Crash Address: 
Crash State:
  configs: x64,ignition:x64,ignition_turbo_opt
  sources: 38d
  
Sanitizer: address (ASAN)

Regressed: V8: 43538:43539
Fixed: V8: 44658:44659

Reproducer Testcase: https://clusterfuzz.com/download/AMIfv97Rq7HkWVraTxY_asOiVpmVe8N1tB4NvaiDEeM4xn_NtAOHOdfdK6NWo9fQxsVff5plWaZnpab-Sg4IFIBCDrHklS0Oy02t2DRM8oAAPntPbr8-Nq5XR2fMaL_36N56KAKKVRDBk1uoI3SoNeZ1BOcOQKBoamRo-pVJkETXodOeKt1mFCGmfqpFoLq3XNyAJzA-3hAXHavolNgbWdHxymK-fVJU9mWLhHYOYRlEOE5QiPW7RMI-AeqgS7pSNZGnFlf4yPItW2BUVTVCq5bthPjws6DuweOuVBhWIlZXc1uQ7H8Pnp90jCM6Gsj7Ftjm1QNnns1yTR6RIbLqQNodPUufbvyLyZrbJO_nc77I4YamWEA-CMo?testcase_id=5304829279993856


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 5304829279993856 is verified as fixed, so closing issue.

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

ClusterFuzz testcase 6223285387001856 is still reproducing on tip-of-tree build (trunk).

Please re-test your fix against this testcase and if the fix was incorrect or incomplete, please re-open the bug. Otherwise, ignore this notification and add ClusterFuzz-Wrong label.