// PTAL. Order of properties in global object between x64/ia32.

try {
  function __f_2() {}
  function __f_1() {}
} catch(e) {; }

for (var i in this) {
  if (i == "__f_1" || i == "__f_2") {
    print(i);
  }
}

// Output:

# Compared x64,ignition with ia32,ignition
#
# Flags of x64,ignition:
--abort_on_stack_overflow --expose-gc --allow-natives-syntax --invoke-weak-callbacks --omit-quit --es-staging --random-seed 1234 --ignition --turbo-filter=~ --hydrogen-filter=~ --validate-asm --nocrankshaft
# Flags of ia32,ignition:
--abort_on_stack_overflow --expose-gc --allow-natives-syntax --invoke-weak-callbacks --omit-quit --es-staging --random-seed 1234 --ignition --turbo-filter=~ --hydrogen-filter=~ --validate-asm --nocrankshaft
#
# Difference:
- __f_2
+ __f_1
#
# Source file:
none
#
### Start of configuration x64,ignition:
__f_2
__f_1

### End of configuration x64,ignition
#
### Start of configuration ia32,ignition:
__f_1
__f_2

### End of configuration ia32,ignition

 Issue 689386  has been merged into this issue.

 Issue 691255  has been merged into this issue.

PTAL

Will start looking into this next week.
Most probably this is a bug in the KeyAccumulator somewhere.

 Issue 694439  has been merged into this issue.

Is there a simple way to suppress this until we have a fix? The duplicates of this are all a bit cumbersome and obscure, e.g. the last one.

I could e.g. mock out getOwnPropertyNames like this, but I have no idea if something similar could be done for accessing "for (i in this)".

(function() {
  var old = Object.getOwnPropertyNames;
  Object.getOwnPropertyNames = function(obj) {var names = old(obj); names.sort(); return names;}
})();

The only way to suppress this on for-in is to use a proxy :/.
I'll fix this first thing next week though.

 Issue 695728  has been merged into this issue.

This seems to be a parser issue since the sorting works as intended once the try-catch is removed.

We hoist and insert declarations based on the function map, which isn't ordered. We can detect this when the declarations en up on the global object.

Is the priority correct on this? That is, is this causing crashes or just correctness fuzzer failures?

That's definitely up for discussion.
So far only fuzzer bugs and probably the spec violation (arguebly not urgent).

For Machenbach this currently means lots of manual deduping of issues.

Manual deduping seems bad, this shouldn't be hard (mostly just have to find the right data structure).

It'd be ok to downgrade the prio for an actual fix.

But because of the way we dedupe correctness fuzzing cases, potentially every non-fixed issue could hide other problems. Unless we find a way to suppress or mock out the symptoms of the issue. In other example we e.g. use Proxies for intercepting array buffers, date, math.pow, etc. But I don't see a simple way how we could mock this?

Proposed fix up for review at https://chromium-review.googlesource.com/c/448701/

 Issue 697841  has been merged into this issue.

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

commit fb1658317941bd2e2f5aa980a64706cecc4420e6
Author: Adam Klein <adamk@chromium.org>
Date: Thu Mar 02 21:06:00 2017

Retain source order when hoisting sloppy block functions

This involved adding a count_ member to SloppyBlockFunctionMap, so
to avoid making DeclarationScope larger, this patch makes the
creation of the map lazy, thus reducing the size of DeclarationScope
by several words in the process.

BUG= chromium:688567 

Change-Id: If9a9eb2ccc01690fe10edadb3aa9625454ff4a19
Reviewed-on: https://chromium-review.googlesource.com/448701
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Daniel Ehrenberg <littledan@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43558}
[modify] https://crrev.com/fb1658317941bd2e2f5aa980a64706cecc4420e6/src/ast/scopes.cc
[modify] https://crrev.com/fb1658317941bd2e2f5aa980a64706cecc4420e6/src/ast/scopes.h
[add] https://crrev.com/fb1658317941bd2e2f5aa980a64706cecc4420e6/test/mjsunit/regress/regress-crbug-688567.js

This should be fixed, let me know if you run into something like this again.

ClusterFuzz has detected this issue as fixed in range 43557:43558.

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

Fuzzer: foozzie_js_mutation
Job Type: foozzie_ignition_x64_ia32
Platform Id: linux

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

Fixed: V8: 43557:43558

Reproducer Testcase: https://cluster-fuzz.appspot.com/download/AMIfv97dnW31_ApbYKC2ABP0MTsmxUB-FWyCVz2jsBIFCBc-o-qe-ihEpgu-DQ87wWeJ6i0YnbUeYWKaFRXJ3nuT51cMcRH0u70h5mGoV0dY9QhqNsmxNfJm0gAxBlmIRm2pJD62w7YG-AY3STUrzOgBQ1SbD_28u7aDtrthBhn9T7GXD1ktUtoiqIzyyZ5dAvcRBApoV-VmWCMlhzvIBmwzwtgsQmefwpS861mCBlIcRfTUWCS0fl8rj9X3Q1W3qQm0-vludr03UAUaqAcyVOpieJ4FQHO-V7o3Of2bcnWPJVQS85Z84wuLMxn24vo3HYT-8IEQML_OZNfUXEXVZmf6seL86nIPAhdpmgmMRQg8BF-6RG3TNjIckFcgyYptTkmodrie3Qq4WELnfumLLxyhT5Z4WK0UVw?testcase_id=5867064146526208


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.

Awesome, thanks for the fix! This should close a lot of reports and give room for some new...