Automatically applying components based on crash stacktrace and information from OWNERS files.

If this is incorrect, please apply the Test-Predator-Wrong-Components label.

Automatically assigning owner based on suspected regression changelist https://chromium.googlesource.com/v8/v8/+/4c9919e5f0ef3a7e5447267ff4849f34d963afec (Reland "[heap] Clear from space after garbage collection.").

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.

I can reproduce it with

is_component_build = false
is_debug = true
symbol_level = 2
v8_optimized_debug = false
target_cpu = "x64"
v8_enable_test_features = true
v8_use_multi_snapshots = true

Running:

./out/Crash/d8 --random-seed=804177959 --expose-gc --disable-in-process-stack-traces --future clusterfuzz-testcase-minimized-5569461449654272.js  --trace-gc --trace-incremental-marking --no-concurrent-marking --no-parallel-marking


It bisects to:

commit 80aaa8798171072282bcf38af9456a240af8c588 (HEAD)
Author: Marja Hölttä <marja@chromium.org>
Date:   Mon Jun 4 10:09:12 2018 +0200

    [in-place weak refs] Make the WeakArrayList API more generic.
    
    (Pre-work for adding special-purpose data structures as subclasses.)
    
    BUG=v8:7308
    
    Change-Id: I82a5a96e18c3321e9d5b783642516ff869b45f27
    Reviewed-on: https://chromium-review.googlesource.com/1084474
    Commit-Queue: Marja Hölttä <marja@chromium.org>
    Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#53482}

Marja, can you have a look?

Looking.

Observation: In optdebug, this DCHECK fails:

void MarkCompactCollector::ProcessMarkingWorklist() {
  HeapObject* object;
  MarkCompactMarkingVisitor visitor(this, marking_state());
  while ((object = marking_worklist()->Pop()) != nullptr) {
    DCHECK(!object->IsFiller()); <<<< here


It starts failing with this commit:


Author: Simon Zünd <szuend@google.com>
Date:   Mon Jun 4 08:41:21 2018 +0200

    [array] Implement Array.p.sort in Torque
    
    This CL implements a generic baseline version and 3 fastpaths, for
    various elements kinds, of Array.p.sort in Torque. Details can be found
    in the Design Doc: https://goo.gl/Ge321G.
    
    Performance impact on micro benchmarks depends on the element kind
    and whether the user provides a comparison function.
    For HoleySmi/HoleyElement we have a speedup between 1.5-1.8 across
    the board. For Dictionary we are slower in all micro benchmarks (0.7).
    For PackedSmi it depends on the call site and whether or not a
    comparison function is used.
    
    Detailed numbers: https://goo.gl/mTyPSb
    
    Bug: v8:7382
    Change-Id: I50acabd2032af0bc01d36b0de0f555d66be56a7e
    Reviewed-on: https://chromium-review.googlesource.com/1061523
    Commit-Queue: Simon Zünd <szuend@google.com>
    Reviewed-by: Camillo Bruni <cbruni@chromium.org>
    Reviewed-by: Jakob Gruber <jgruber@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#53481}

(This is the commit just before the one in comment 3 - not sure if the bisect missed this?)

Not saying that commit is guilty, maybe it just exposes a bug in the GC...

ClusterFuzz has detected this issue as fixed in range 54165:54166.

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

Fuzzer: ochang_js_fuzzer
Job Type: linux_cfi_d8
Platform Id: linux

Crash Type: Null-dereference READ
Crash Address: 0x00000000000a
Crash State:
  v8::internal::Map::visitor_id
  Visit
  v8::internal::ConcurrentMarking::Run
  
Sanitizer: cfi (CFI)

Regressed: https://clusterfuzz.com/revisions?job=linux_cfi_d8&range=54111:54112
Fixed: https://clusterfuzz.com/revisions?job=linux_cfi_d8&range=54165:54166

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

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.