Automatically assigning owner based on suspected regression changelist https://chromium.googlesource.com/v8/v8/+/52b3b491a55f5f3233ca78e0c22c37384b92670e ([errors] Use FATAL macro where possible).

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.

We crash in the FastNewObject builtin since we get undefined as a new_target:

#0  v8::base::OS::Abort () at ../../src/base/platform/platform-posix.cc:381
#1  0x00007ffff75d035e in v8::internal::__RT_impl_Runtime_AbortJS (args=..., isolate=0x555555607f60) at ../../src/runtime/runtime-test.cc:664
#2  0x00007ffff75cfd17 in v8::internal::Runtime_AbortJS (args_length=0x1, args_object=0x7fffffffbb08, isolate=0x555555607f60) at ../../src/runtime/runtime-test.cc:654
#3  0x00000cef5f7052d2 in Stub:CEntryStub ()
#4  0x00000cef5f714c49 in Builtin:FastNewObject ()
#5  0x00000cef5f808ae3 in BytecodeHandler:Construct ()
#6  0x00000cef5f71d699 in Builtin:InterpreterEntryTrampoline ()
#7  0x00000176f7ba6048 in ?? ()
#8  0x00007fffffffbc30 in ?? ()
#9  0x00000176f7ba6048 in ?? ()
#10 0x000017f6847022e1 in ?? ()
#11 0x000000000000000c in ?? ()
#12 0x00007fffffffbc50 in ?? ()
#13 0x00000cef5f81bd7d in Stub:js-to-wasm#0 ()

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

commit fc976f8e23e5389bf161256a559da23058bc89ac
Author: Andreas Haas <ahaas@chromium.org>
Date: Thu Mar 29 11:48:32 2018

[wasm] Don't call constructors directly from wasm2js wrappers

For the wasm2js wrappers we have an optimization to call a JavaScript
function directly if the signature of the JavaScript function matches
the signature of the WebAssembly import. However, we are not supposed
to do this optimization if the imported function is a constructor,
because constructors can only be called with `new`. With this CL we
do not apply this optimization when the imported function is a
constructor.

R=titzer@chromium.org

Bug:  chromium:824859 
Change-Id: I1722367bd865d0b129eadf7d4849182410447179
Reviewed-on: https://chromium-review.googlesource.com/985974
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52296}
[modify] https://crrev.com/fc976f8e23e5389bf161256a559da23058bc89ac/src/compiler/wasm-compiler.cc
[modify] https://crrev.com/fc976f8e23e5389bf161256a559da23058bc89ac/test/mjsunit/wasm/ffi.js

ClusterFuzz has detected this issue as fixed in range 52295:52296.

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

Fuzzer: ochang_js_fuzzer
Job Type: linux_ubsan_vptr_d8
Platform Id: linux

Crash Type: Ill
Crash Address: 0x55ecdbfa47ae
Crash State:
  v8::internal::Runtime_NewObject
  
Sanitizer: undefined (UBSAN)

Regressed: https://clusterfuzz.com/revisions?job=linux_ubsan_vptr_d8&range=51276:51277
Fixed: https://clusterfuzz.com/revisions?job=linux_ubsan_vptr_d8&range=52295:52296

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

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

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

This bug requires manual review: We are only 12 days from stable.
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), josafat@(ChromeOS), abdulsyed@(Desktop)

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

Please add the rational regarding this merge.

I discussed the issue with cbruni and bmeurer now. This issue does not seem to have security implications. In the worst case we call a JavaScript constructor with undefined as the receiver instead of a newly allocated object. The crash happened in a release CHECK in a runtime function, so this check would also protect shipped code.

I guess it would be fine not to merge this CL.

Thanks!