Predator and CL did not find any possible suspects.
Using Code Search for the file, "handles.h" assigning to the concern owner.
Suspecting Commit#
https://chromium.googlesource.com/v8/v8.git/+/f2bab459677a1b2fd0e31a17d86684c6b45602ac

@clemensh -- Could you please look into the issue, kindly re-assign if this is not related to your changes.
Thank You.

This is a missing asm.js source mapping for the stack check in the start function. The initial stack check is always associated with the wasm offset 0, and for all other functions we add a mapping from wasm offset 0 to the start position of the asm.js function.
For the start function, this was missing.

CL coming.

https://chromium-review.googlesource.com/458437

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

commit a2807f2a2a7fa44e9c46783b05c23a3025e2a766
Author: Clemens Hammacher <clemensh@chromium.org>
Date: Wed Mar 22 17:02:16 2017

[wasm] [asm.js] Store function start position also for init function

The stack check at the beginning of each function maps to the wasm byte
offset 0. For asm.js functions, this byte offset is mapped further to an
asm.js source position. For most functions, we explicitly add an entry
to this side table for offset 0. This was missing for the start
function.

R=ahaas@chromium.org
BUG= v8:4203 , chromium:703568 

Change-Id: I05bc4a8cfa666864bb7a0b23f75186abe0be9bee
Reviewed-on: https://chromium-review.googlesource.com/458437
Commit-Queue: Brad Nelson <bradnelson@chromium.org>
Reviewed-by: Brad Nelson <bradnelson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44037}
[modify] https://crrev.com/a2807f2a2a7fa44e9c46783b05c23a3025e2a766/src/asmjs/asm-wasm-builder.cc
[add] https://crrev.com/a2807f2a2a7fa44e9c46783b05c23a3025e2a766/test/mjsunit/regress/wasm/regression-703568.js

Reopening, as the original issue is not fixed yet.

Reassigning to adamk@, who introduced the JSFunction::SetName function here: https://codereview.chromium.org/1626423003

Stacktrace:
#0  V8_Fatal (file=0x7f190ac7df5c "../../src/handles.h", line=210, format=0x7f190ac7dbcf "Check failed: %s.") at ../../src/base/logging.cc:60
#1  0x00007f1909d19ca7 in v8::internal::MaybeHandle<v8::internal::String>::Check (this=0x7ffe5e953138) at ../../src/handles.h:210
#2  0x00007f1909d04399 in v8::internal::MaybeHandle<v8::internal::Object>::ToHandleChecked (this=0x7ffe5e953138) at ../../src/handles.h:213
#3  0x00007f190a63548e in v8::internal::JSFunction::SetName (function=..., name=..., prefix=...) at ../../src/objects.cc:12904
#4  0x00007f190a829229 in v8::internal::__RT_impl_Runtime_DefineDataPropertyInLiteral (args=..., isolate=0x7f190bec3ed0) at ../../src/runtime/runtime-object.cc:680
#5  0x00007f190a828b50 in v8::internal::Runtime_DefineDataPropertyInLiteral (args_length=6, args_object=0x7ffe5e953438, isolate=0x7f190bec3ed0) at ../../src/runtime/runtim
e-object.cc:647
#6  0x000017b92ab04264 in ?? ()
[...]

Though I authored SetName, there's nothing special about this function. The crash is in checking the return value of Name::ToFunctionName, which can only produce an empty handle if it were to try to generate a name greater than the max string length (which it does not do in this case).

Given the narrow regression range, and the fact that this only runs into a crash with --validate-asm, I would rather suspect https://chromium.googlesource.com/v8/v8/+/c69b48adc4cd4c36c44eac8efcac51bdbb1fdc5c (which mentions some interesting weirdness with stack overflows)

Nope, that CL is totally unrelated.

What I found out so far:

Object::SetPropertyWithAccessor exits in objects.cc:1496 with:
RETURN_VALUE_IF_SCHEDULED_EXCEPTION(isolate, Nothing<bool>());

The problem is that the scheduled exception is there right from the beginning of Runtime_DefineDataPropertyInLiteral, which eventually calls SetPropertyWithAccessor.

So I first need to understand the relation between scheduled exceptions and pending exceptions better, and whether it's OK to call a runtime function with a scheduled exception being set.

Assigning to mstarzinger after offline discussion.

ClusterFuzz has detected this issue as fixed in range 468258:468264.

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

Fuzzer: mbarbella_js_mutation
Job Type: linux_ubsan_vptr_d8
Platform Id: linux

Crash Type: CHECK failure
Crash Address: 
Crash State:
  (location_) != nullptr in handles.h
  
Sanitizer: undefined (UBSAN)

Regressed: https://clusterfuzz.com/revisions?job=linux_ubsan_vptr_d8&range=437986:438063
Fixed: https://clusterfuzz.com/revisions?job=linux_ubsan_vptr_d8&range=468258:468264

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


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

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