// Problem with Realm. Bisects back before the inception of correctness fuzzing. Repro:

this.__defineGetter__('y', function() { return 0; });
function foo(a) {
  y = y + a;
  return y;
}
print(foo());
print(foo());
Realm.eval(Realm.current(), "let y");
%OptimizeFunctionOnNextCall(foo);
print(foo());

// 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 --random-seed 123 --turbo-filter=~ --noopt --suppress-asm-messages
# Flags of x64,ignition_turbo:
--abort_on_stack_or_string_length_overflow --expose-gc --allow-natives-syntax --invoke-weak-callbacks --omit-quit --es-staging --random-seed 123 --suppress-asm-messages
#
# Difference:
- undefined
+ NaN
#
### Start of configuration x64,ignition:
0
0
undefined

### End of configuration x64,ignition
#
### Start of configuration x64,ignition_turbo:
0
0
NaN

### End of configuration x64,ignition_turbo

Automatically applying components based on information from OWNERS files. If this seems incorrect, please apply the Test-Predator-Wrong-Components label.

Automatically assigning owner based on suspected regression changelist https://chromium.googlesource.com/v8/v8/+/a49ff6abb76370114106ca3516850496c96e9c73 ([foozzie] Add better default configs for correctness fuzzing).

If this is incorrect, please remove the owner and apply the Test-Predator-Wrong-CLs label.

Test-Predator-Wrong-CLs

Friendly ping - adding current clusterfuzz sheriff...

Further reduced repro, it all boils down to the semantics of the {StaGlobalSloppy} bytecode ...

this.__defineGetter__('x', function() { return 0; });
function foo() {
  x = 23;
}
assertEquals(0, (foo(), x));
assertEquals(0, (foo(), x));
Realm.eval(Realm.current(), "let x");
%OptimizeFunctionOnNextCall(foo);
assertEquals(23, (foo(), x));

This is actually a bug in the store-IC being used in the interpreted version. The TurboFan version is correct. This can be reproduces without TurboFan by just control the number of warm-up given to a certain store-site before introducing the new global. See the following repro ...

this.__defineGetter__('x', function() { return 0; });
function store_x() {
  x = 23;
}
store_x(); print("x:", x);
store_x(); print("x:", x);
Realm.eval(Realm.current(), "let x = 42");
store_x(); print("x:", x);
this.__defineGetter__('y', function() { return 0; });
function store_y() {
  y = 23;
}
store_y(); print("y:", y);
Realm.eval(Realm.current(), "let y = 42");
store_y(); print("y:", y);

Prodcues the following output ...

x: 0
x: 0
x: 42  // <-- expected 23 here as well
y: 0
y: 23

The fix is on the way: https://chromium-review.googlesource.com/c/v8/v8/+/715802

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

commit 3384a793e0bcb495f5c2695ce3bf9d77be83e89b
Author: Igor Sheludko <ishell@chromium.org>
Date: Thu Oct 12 14:07:41 2017

[ic] Introduce proper slow stub for StoreGlobalIC.

Bug:  chromium:768875 
Change-Id: Ib5b324e90bea846e6cca419f81bf46bd293e83b4
Reviewed-on: https://chromium-review.googlesource.com/715802
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48503}
[modify] https://crrev.com/3384a793e0bcb495f5c2695ce3bf9d77be83e89b/src/builtins/builtins-definitions.h
[modify] https://crrev.com/3384a793e0bcb495f5c2695ce3bf9d77be83e89b/src/builtins/builtins-handler-gen.cc
[modify] https://crrev.com/3384a793e0bcb495f5c2695ce3bf9d77be83e89b/src/ic/ic.cc
[modify] https://crrev.com/3384a793e0bcb495f5c2695ce3bf9d77be83e89b/src/ic/ic.h
[modify] https://crrev.com/3384a793e0bcb495f5c2695ce3bf9d77be83e89b/src/runtime/runtime.h
[add] https://crrev.com/3384a793e0bcb495f5c2695ce3bf9d77be83e89b/test/mjsunit/regress/regress-crbug-768875.js

ClusterFuzz has detected this issue as fixed in range 48502:48503.

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

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
  sources: 02b
  
Sanitizer: address (ASAN)

Regressed: https://clusterfuzz.com/revisions?job=v8_foozzie&range=43348:43349
Fixed: https://clusterfuzz.com/revisions?job=v8_foozzie&range=48502:48503

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

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

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