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.

// Reduced repro:
var v = [];
Object.defineProperty(v, "length", {value: 3, writable: false});
function foo(b) { return b.pop(); }
foo(v);

// Output:
# Compared x64,ignition with x64,slow_path
#
# Flags of x64,ignition:
--abort_on_stack_or_string_length_overflow --expose-gc --allow-natives-syntax --invoke-weak-callbacks --omit-quit --es-staging --random-seed 1002378131 --turbo-filter=~ --noopt --suppress-asm-messages
# Flags of x64,slow_path:
--abort_on_stack_or_string_length_overflow --expose-gc --allow-natives-syntax --invoke-weak-callbacks --omit-quit --es-staging --random-seed 1002378131 --force-slow-path --suppress-asm-messages
#
# Difference:
+ /usr/local/google/home/machenbach/v8/v8/repro.js:3: TypeError: Cannot assign to read only property 'length' of object '[object Array]'
#
# Source file:
none
#
### Start of configuration x64,ignition:

### End of configuration x64,ignition
#
### Start of configuration x64,slow_path:
/usr/local/google/home/machenbach/v8/v8/repro.js:3: TypeError: Cannot assign to read only property 'length' of object '[object Array]'
function foo(b) { return b.pop(); }
                           ^



### End of configuration x64,slow_path

The Array.p.pop logic is pretty funky.. It's implemented in CSA, but can fall back to a CPP builtin. The CPP builtin can fall back to JS. In the case triggered above, that's what happens when --force-slow-path is passed. In JS, the attempted write to .length triggers the exception. 

The bug appears to be that 
 
    EnsureArrayLengthWritable(LoadMap(array_receiver), &runtime);

doesn't realize length is non-writable. Or, conversely, that StaNamedProperty throws when it shouldn't, I'm not sure. 

Interestingly, direct writes to length don't throw but ignore the attempted write instead:

 d8> var v = [];
 d8> Object.defineProperty(v, "length", {value: 3, writable: false});
 d8> v.length
 3
 d8> v.length = 42
 d8> v.length
 3

 Issue 830143  has been merged into this issue.

Any news here? Is this a P1?

I'd say P2 since the issue is that the exception is not thrown. No other news.

I'll take a look.

The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/75e04cd22cdf2d65c8baa3535d32ae07ee16f317

commit 75e04cd22cdf2d65c8baa3535d32ae07ee16f317
Author: Igor Sheludko <ishell@chromium.org>
Date: Tue Apr 10 08:51:07 2018

[builtins] Throw on pop()/shift() when JSArray's length is not writable.

Bug:  chromium:823069 
Change-Id: Ie5be40da1e64a11c7a3c6ba5d2bc193bd78ca737
Reviewed-on: https://chromium-review.googlesource.com/1002560
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52508}
[modify] https://crrev.com/75e04cd22cdf2d65c8baa3535d32ae07ee16f317/src/bootstrapper.cc
[modify] https://crrev.com/75e04cd22cdf2d65c8baa3535d32ae07ee16f317/src/code-stub-assembler.cc
[modify] https://crrev.com/75e04cd22cdf2d65c8baa3535d32ae07ee16f317/src/code-stub-assembler.h
[modify] https://crrev.com/75e04cd22cdf2d65c8baa3535d32ae07ee16f317/src/objects/js-array.h
[add] https://crrev.com/75e04cd22cdf2d65c8baa3535d32ae07ee16f317/test/mjsunit/regress/regress-crbug-823069.js

ClusterFuzz has detected this issue as fixed in range 52507:52508.

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

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_opt
  sources: 336
  
Sanitizer: address (ASAN)

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

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

See https://github.com/google/clusterfuzz-tools 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 4719525334089728 is verified as fixed, so closing issue as verified.

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