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 adding ccs based on suspected regression changelists:

[cleanup] Replace List with std::vector in cctests and d8. by petermarshall@chromium.org - https://chromium.googlesource.com/v8/v8/+/abaece06d211bc0c4e5fbbda3999a1d1d7736055

[snapshot] Make the API external reference table const. by jbroman@chromium.org - https://chromium.googlesource.com/v8/v8/+/779bb1b1724c02a7b88480db857d8d4c3f5ede74

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

The regression range seems wrong. I can reproduce before that range.
It reproduces also without any flags, especially without --enable-features=V8Future.

It fails in wasm code, where we seems to be missing a bounds check:
--- Code ---
kind = WASM_FUNCTION
name = wasm#0
compiler = turbofan
address = 0x11877ce17ae1
Instructions (size = 47)
0x11877ce17b40     0  488b1e         REX.W movq rbx,[rsi]
0x11877ce17b43     3  8bc0           movl rax,rax
0x11877ce17b45     5  8b0403         movl rax,[rbx+rax*1]
0x11877ce17b48     8  c3             retl
0x11877ce17b49     9  55             push rbp
0x11877ce17b4a     a  4889e5         REX.W movq rbp,rsp
0x11877ce17b4d     d  6a0a           push 0xa
0x11877ce17b4f     f  e80ccff8ff     call 0x11877cda4a60  (ThrowWasmTrapMemOutOfBounds)    ;; code: BUILTIN
0x11877ce17b54    14  90             nop
0x11877ce17b55    15  0f1f00         nop

At 0x11877ce17b45, rax is 0xf4240, but the memory size is 0x10000.

Will investigate further why the bounds check is missing.

Update: The bounds check is skipped because FLAG_wasm_trap_handler is true, but I still fail to find who sets it to true.
My command line is:
out/Debug/chrome --js-flags=--print-wasm-code\ --trace-wasm-decoder\ --no-debug-code --single-process --user-data-dir=/tmp/user-123asdf --no-first-run --use-gl=swiftshader --disable-in-process-stack-traces $HOME/Downloads/data-bundles/ltests/moz_tests/testing/web-platform/mozilla/tests/wasm/fuzz-http-89.html

Including Eric.

Update:
The flag is explicitly being set at
#0  v8::internal::FlagList::SetFlagsFromString (str=0x7f99c0c46170 "--wasm-trap-handler", len=19) at ../../v8/src/flags.cc:523
#1  0x00007f99b884a71b in v8::V8::SetFlagsFromString (str=0x7f99c0c46170 "--wasm-trap-handler", length=19) at ../../v8/src/api.cc:860
#2  0x00007f99c452fd97 in (anonymous namespace)::SetV8FlagIfFeature (feature=..., v8_flag=0x7f99c0c46170 "--wasm-trap-handler") at ../../content/renderer/render_process_impl.cc:48
#3  0x00007f99c452fa04 in content::RenderProcessImpl::RenderProcessImpl (this=0x261a005b3de0, task_scheduler_init_params=...) at ../../content/renderer/render_process_impl.cc:164
#4  0x00007f99c4530433 in content::RenderProcessImpl::Create () at ../../content/renderer/render_process_impl.cc:208
#5  0x00007f99c438486f in content::InProcessRendererThread::Init (this=0x261a01140440) at ../../content/renderer/in_process_renderer_thread.cc:49
#6  0x00007f99c8e82f07 in base::Thread::ThreadMain (this=0x261a01140440) at ../../base/threading/thread.cc:327
#7  0x00007f99c8e68d51 in base::(anonymous namespace)::ThreadFunc (params=0x261a0112c5c0) at ../../base/threading/platform_thread_posix.cc:75
#8  0x00007f99c91b6184 in start_thread (arg=0x7f9988190700) at pthread_create.c:312
#9  0x00007f99ae554ffd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

The "feature" at #2 is
{name = 0x7f99c0ce1d8a "WebAssemblyTrapHandler", default_state = base::FEATURE_DISABLED_BY_DEFAULT}

But somehow, this feature is enabled in my config. Has this something to do with the field trial added in https://crrev.com/c/618148?

Assigning to Eric, who fixed something similar in https://crrev.com/c/617408.

I played around with some command line flags. The crash goes away when either removing the --disable-in-process-stack-traces flag, adding --enable-crash-reporter-for-testing, or adding --disable-features=WebAssemblyTrapHandler.

This makes me think there are two things going on:
1) The Wasm trap handler is being enabled unexpectedly.
2) The Wasm signal handler is not being called.

For 1), my guess is that this if being driven by Finch. We've disabled trap handlers in most places, but we still have it on for Dev at 50%. I'm not sure, by I think Googlers may be opted in to all experiments. I'm surprised if Finch is being applied to a custom built Chrome though. I'll investigate more.

For 2), Wasm has a signal handler that needs to be called by the embedder. We call this from the stack trace handler and Breakpad, but apparently if neither of these is enabled then there is no handler registered. In that case, we should call V8::RegisterDefaultSignalHandler(). I will look for the best place to add this call to make sure we are covered in all cases.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/1384f6dc52e6354701444aaccf61408ed4e5c970

commit 1384f6dc52e6354701444aaccf61408ed4e5c970
Author: Eric Holk <eholk@chromium.org>
Date: Fri Jan 05 02:15:47 2018

Register V8 Signal Handler if none other is installed

To support trap-based bounds checks for WebAssembly, V8 provides a function that
should be called from a signal handler. Chrome provides two signal handlers: the
in-process stack trace handler and the crash reporter. If both of these are
disabled there will no signal handler and V8's handler won't get called, meaning
any Wasm out of bounds accesses will crash the tab. This change registers V8's
default handler in cases where neither of Chrome's other handlers are installed.

Bug:  798150 
Change-Id: I1b8fca2aec7a7bfb919fc394b11eec3783edb7a7
Reviewed-on: https://chromium-review.googlesource.com/851420
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Commit-Queue: Eric Holk <eholk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#527190}
[modify] https://crrev.com/1384f6dc52e6354701444aaccf61408ed4e5c970/content/renderer/render_process_impl.cc

eholk: Uh oh! This issue still open and hasn't been updated in the last 14 days. This is a serious vulnerability, and we want to ensure that there's progress. Could you please leave an update with the current status and any potential blockers?

If you're not the right owner for this issue, could you please remove yourself as soon as possible or help us find the right one?

If the issue is fixed or you can't reproduce it, please close the bug. If you've started working on a fix, please set the status to Started.

Thanks for your time! To disable nags, add the Disable-Nags label.

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

eholk: Uh oh! This issue still open and hasn't been updated in the last 28 days. This is a serious vulnerability, and we want to ensure that there's progress. Could you please leave an update with the current status and any potential blockers?

If you're not the right owner for this issue, could you please remove yourself as soon as possible or help us find the right one?

If the issue is fixed or you can't reproduce it, please close the bug. If you've started working on a fix, please set the status to Started.

Thanks for your time! To disable nags, add the Disable-Nags label.

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

eholk: Is this bug fixed now?

Also, presumably it affects all V8 platforms?

I tried to repro it today and was not able to. The problem doesn't look like anything that was unexpected (the fault appears to be in memory V8 expects to fault), but that the signal handler was not installed. The CL I landed earlier should address the case where the signal handler was not installed and we'll be able to recover from these faults as expected.

Because this is trap handler related, and we currently only have that implemented for Linux, this should not affect other platforms.

I'm going to go ahead and close this.

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