Marja, bisect points to your CL.

This is weird!

The CL in question is this:

commit 8cbe27e7aeaf27688612540938032851931224e2
Author: Marja Hölttä <marja@chromium.org>
Date:   Wed Feb 8 11:10:51 2017 +0100

    [parser] Turn off FLAG_lazy_inner_functions.
    
    (Minimal change to support easy backmerging.)
    
    BUG= v8:5938 
    
    Change-Id: Icad35c90d9c2451cd63a4ab7e495d9b5252da693
    Reviewed-on: https://chromium-review.googlesource.com/439170
    Reviewed-by: Jochen Eisinger <jochen@chromium.org>
    Commit-Queue: Marja Hölttä <marja@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#43031}


I've already turned the FLAG_lazy_inner_functions back on though.

But it makes no sense that this would crash like that... investigating!

Tried to repro it like this:

$ ASAN_OPTIONS=redzone=128:symbolize=0:detect_stack_use_after_return=1:alloc_dealloc_mismatch=0:print_scariness=1:check_malloc_usable_size=0:max_uar_stack_size_log=16:use_sigaltstack=1:strict_memcmp=0:detect_container_overflow=1:coverage=0:detect_odr_violation=0:allocator_may_return_null=1:handle_segv=1:fast_unwind_on_fatal=1 out/Debug/d8 --random-seed=1805867326 --expose-gc --allow-natives-syntax --gc-interval=324 --no-inline-new --stress-compaction --validate-asm ~/Downloads/clusterfuzz-testcase-5636770818686976.js


But it hangs in:

#0  sem_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/sem_wait.S:85
#1  0x00007f5a92236e64 in Wait () at ../../src/base/platform/semaphore.cc:100
#2  0x00007f5a8ff10b40 in Run<(lambda at ../../src/heap/mark-compact.cc:3309:29)> ()
    at ../../src/heap/page-parallel-job.h:108
#3  EvacuatePagesInParallel () at ../../src/heap/mark-compact.cc:3309
#4  0x00007f5a8fef0ede in EvacuateNewSpaceAndCandidates () at ../../src/heap/mark-compact.cc:3574
#5  0x00007f5a8fee8e96 in CollectGarbage () at ../../src/heap/mark-compact.cc:316
#6  0x00007f5a8fe58f07 in MarkCompact () at ../../src/heap/heap.cc:1464
#7  0x00007f5a8fe52fb8 in PerformGarbageCollection () at ../../src/heap/heap.cc:1335
#8  0x00007f5a8fe500ee in CollectGarbage () at ../../src/heap/heap.cc:1016
#9  0x00007f5a8fe4bffe in CollectGarbage () at ../../src/heap/heap-inl.h:685
#10 CollectAllGarbage () at ../../src/heap/heap.cc:856
#11 0x00007f5a8edd6c2a in RequestGarbageCollectionForTesting () at ../../src/api.cc:8097
#12 0x00007f5a8ecbf55d in Call () at ../../src/api-arguments.cc:25
#13 0x00007f5a8effb6e3 in HandleApiCallHelper<false> () at ../../src/builtins/builtins-api.cc:106
#14 0x00007f5a8eff527e in Builtin_Impl_HandleApiCall () at ../../src/builtins/builtins-api.cc:135
#15 0x00007f5a8eff4259 in Builtin_HandleApiCall () at ../../src/builtins/builtins-api.cc:123

.. the same hang happens when I use the build I downloaded from the report.

Not surprisingly, when I don't pass --expose-gc, the hang goes away but I still cannot repro the actual problem.

Assigning to ahaas@, this looks like some --validate-asm problem (if any); it should work with both FLAG_lazy_inner_functions and without.

This issue is a security regression. If you are not able to fix this quickly, please revert the change that introduced it.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

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

commit db558210d8e47059b97c827b55f33d5b90a6a8cb
Author: Andreas Haas <ahaas@chromium.org>
Date: Tue Feb 14 07:42:56 2017

[wasm] Do not unhandlify WasmInstanceWrapper during initialization.

Within the initialization of a WasmInstanceWrapper a WeakCell is
allocated for the wrapped instance. This allocation of the WeakCell can
cause a garbage collection. The bug happened because a pointer to the
WasmInstanceWrapper was stored in the unhandlified this pointer, which
was invalidated by the garbage collection.

R=clemensh@chromium.org
CC=gdeepti@chromium.org
BUG= chromium:691538 

Change-Id: I7001ab7ad3ee30f4c87a13c42e2fd16c0c86027a
Reviewed-on: https://chromium-review.googlesource.com/441766
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43177}
[modify] https://crrev.com/db558210d8e47059b97c827b55f33d5b90a6a8cb/src/wasm/wasm-objects.cc
[modify] https://crrev.com/db558210d8e47059b97c827b55f33d5b90a6a8cb/src/wasm/wasm-objects.h

ClusterFuzz has detected this issue as fixed in range 43141:43142.

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

Fuzzer: mbarbella_js_mutation
Job Type: linux_asan_d8_v8_mipsel_dbg
Platform Id: linux

Crash Type: UNKNOWN READ
Crash Address: 0xd9a0001c
Crash State:
  v8::internal::FixedArray::set
  v8::internal::WasmInstanceWrapper::New
  v8::internal::WasmInstanceObject::New
  
Sanitizer: address (ASAN)

Recommended Security Severity: Medium

Regressed: V8: 43030:43031
Fixed: V8: 43141:43142

Reproducer Testcase: https://cluster-fuzz.appspot.com/download/AMIfv96Gy-GmYLCJjoy-NizB2eGDSafC_vbg3Nic8QRDj60tKc-tlZT4eZBh9usvJnfmZR4ycr6kI60qYYnnRjnGR1CvVYH0e9lGlLVud5FAnkf21nRa8I6_8b41yaaxxB4RNPJTNmaO0Adwq-ab-kLmJi8TqPat3RC9YAZ6OcwGRUNrXplChQmfKL_1BXWK4RFKKaBc2PkX-IpMddDAhRjMzSptQyZgk2LMW5RbYxBRW4vCpRzLWE6sJ_4y9GnmWOWrBwTDMY27CjFgo3XGcxF9Ua06bFQmHG3sw7Dl7TqW9SR-oD8Kj3mIUOB75OKIttkDTf-K0UMUlx6Ri0Q_jxqrVN7tlMPgyi_BIixZdgAW2aspTY_lExO96cmnxtzj6CK3Lfd5LCOedpkNCJ-SmYovX3N3DjmGog?testcase_id=5636770818686976


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

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

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot