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

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

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

commit 441e6d4a3ca41922f862e5f2383fec81b9ab8919
Author: Andreas Haas <ahaas@chromium.org>
Date: Fri Apr 27 17:34:05 2018

[wasm] Do an additional IsWasmModuleObject check during instantiation

When WebAssembly.instantiate or WebAssembly.instantiateStreaming is
called in JavaScript, internally we transfrom it into
WebAssembly.compile(buffer).then(WebAssembly.instantiate). However,
modifying the prototype of WebAssembly.Module can change the result of
WebAssembly.compile(buffer). With this CL we make sure that even if the
result of WebAssembly.compile is modified, there is still no type
confusion. In the long term we have to do a refactoring and remove
this internal transformation.

R=mstarzinger@chromium.org

Bug:  chromium:837417 
Change-Id: I376068b8b8b01b991ec450162da6a62ae7030c62
Reviewed-on: https://chromium-review.googlesource.com/1032392
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52859}
[modify] https://crrev.com/441e6d4a3ca41922f862e5f2383fec81b9ab8919/src/wasm/wasm-js.cc
[modify] https://crrev.com/441e6d4a3ca41922f862e5f2383fec81b9ab8919/test/mjsunit/regress/wasm/regress-836141.js
[add] https://crrev.com/441e6d4a3ca41922f862e5f2383fec81b9ab8919/test/mjsunit/regress/wasm/regress-837417.js

ClusterFuzz has detected this issue as fixed in range 554527:554531.

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

Job Type: linux_asan_chrome_mp
Platform Id: linux

Crash Type: Null-dereference READ
Crash Address: 0x000000000000
Crash State:
  v8::internal::wasm::InstantiateToInstanceObject
  v8::WebAssemblyInstantiateImpl
  v8::WebAssemblyInstantiateCallback
  
Sanitizer: address (ASAN)

Regressed: https://clusterfuzz.com/revisions?job=linux_asan_chrome_mp&range=523898:523900
Fixed: https://clusterfuzz.com/revisions?job=linux_asan_chrome_mp&range=554527:554531

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

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 5305166916747264 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: M67 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), kbleicher@(ChromeOS), govind@(Desktop)

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

Approved after discussion with Andreas

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

commit 5f8e5ada42266d64598b56ea624ec72e09a6756f
Author: Andreas Haas <ahaas@chromium.org>
Date: Mon Apr 30 10:48:35 2018

Merged: [wasm] Do an additional IsWasmModuleObject check during instantiation

When WebAssembly.instantiate or WebAssembly.instantiateStreaming is
called in JavaScript, internally we transfrom it into
WebAssembly.compile(buffer).then(WebAssembly.instantiate). However,
modifying the prototype of WebAssembly.Module can change the result of
WebAssembly.compile(buffer). With this CL we make sure that even if the
result of WebAssembly.compile is modified, there is still no type
confusion. In the long term we have to do a refactoring and remove
this internal transformation.

R=​mstarzinger@chromium.org

NOTRY=true
NOPRESUBMIT=true
NOTREECHECK=true

Bug:  chromium:837417 
Change-Id: I376068b8b8b01b991ec450162da6a62ae7030c62
Reviewed-on: https://chromium-review.googlesource.com/1032392
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#52859}(cherry picked from commit 441e6d4a3ca41922f862e5f2383fec81b9ab8919)
Reviewed-on: https://chromium-review.googlesource.com/1034572
Cr-Commit-Position: refs/branch-heads/6.7@{#45}
Cr-Branched-From: 8457e810efd34381448d51d93f50079cf1f6a812-refs/heads/6.7.288@{#2}
Cr-Branched-From: e921be5c4f2c6407936bde750992dedbf47c1016-refs/heads/master@{#52547}
[modify] https://crrev.com/5f8e5ada42266d64598b56ea624ec72e09a6756f/src/wasm/wasm-js.cc
[modify] https://crrev.com/5f8e5ada42266d64598b56ea624ec72e09a6756f/test/mjsunit/regress/wasm/regress-836141.js
[add] https://crrev.com/5f8e5ada42266d64598b56ea624ec72e09a6756f/test/mjsunit/regress/wasm/regress-837417.js

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

commit 1f1bcb73bb7f4057f47d3ba90883d000bbea88db
Author: Andreas Haas <ahaas@chromium.org>
Date: Mon Apr 30 10:50:34 2018

Merged: [wasm] Do an additional IsWasmModuleObject check during instantiation

When WebAssembly.instantiate or WebAssembly.instantiateStreaming is
called in JavaScript, internally we transfrom it into
WebAssembly.compile(buffer).then(WebAssembly.instantiate). However,
modifying the prototype of WebAssembly.Module can change the result of
WebAssembly.compile(buffer). With this CL we make sure that even if the
result of WebAssembly.compile is modified, there is still no type
confusion. In the long term we have to do a refactoring and remove
this internal transformation.

R=​mstarzinger@chromium.org

NOTRY=true
NOPRESUBMIT=true
NOTREECHECK=true

Bug:  chromium:837417 
Change-Id: I376068b8b8b01b991ec450162da6a62ae7030c62
Reviewed-on: https://chromium-review.googlesource.com/1032392
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#52859}(cherry picked from commit 441e6d4a3ca41922f862e5f2383fec81b9ab8919)
Reviewed-on: https://chromium-review.googlesource.com/1034058
Cr-Commit-Position: refs/branch-heads/6.6@{#53}
Cr-Branched-From: d500271571b92cb18dcd7b15885b51e8f437d640-refs/heads/6.6.346@{#1}
Cr-Branched-From: 265ef0b635f8761df7c89eb4e8ec9c1a6ebee184-refs/heads/master@{#51624}
[modify] https://crrev.com/1f1bcb73bb7f4057f47d3ba90883d000bbea88db/src/wasm/wasm-js.cc
[modify] https://crrev.com/1f1bcb73bb7f4057f47d3ba90883d000bbea88db/test/mjsunit/regress/wasm/regress-836141.js
[add] https://crrev.com/1f1bcb73bb7f4057f47d3ba90883d000bbea88db/test/mjsunit/regress/wasm/regress-837417.js

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

commit 8a95da24150bee6b8b5d63e08f21af756bfe24c4
Author: Andreas Haas <ahaas@chromium.org>
Date: Thu May 24 22:15:52 2018

[wasm] Reimplement WebAssembly.instantiate without desugaring

At the moment, WebAssembly.instantiate(bytes) is implemented by
desugaring it to WebAssembly.compile(bytes).then(WebAssembly.instantiate).
The problem is that the {then} in this snippet is observable. With this
CL I introduce a CompilationResultResolver which allows to do the
desugaring internally and thereby make the {then} unobservable.
Unfortunately the result of WebAssembly.instantiate(bytes) is different
than the result of WebAssembly.instantiate(module). Therefore I also
introduced an InstantiationResultResolver for symmetry with
WebAssembly.compile.

R=mstarzinger@chromium.org
Bug:  chromium:837417 

Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: I2d98e03d65f2ada19041d5a9e2df5da91b24ccca
Reviewed-on: https://chromium-review.googlesource.com/1059783
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53347}
[modify] https://crrev.com/8a95da24150bee6b8b5d63e08f21af756bfe24c4/src/api.cc
[modify] https://crrev.com/8a95da24150bee6b8b5d63e08f21af756bfe24c4/src/wasm/module-compiler.cc
[modify] https://crrev.com/8a95da24150bee6b8b5d63e08f21af756bfe24c4/src/wasm/module-compiler.h
[modify] https://crrev.com/8a95da24150bee6b8b5d63e08f21af756bfe24c4/src/wasm/wasm-engine.cc
[modify] https://crrev.com/8a95da24150bee6b8b5d63e08f21af756bfe24c4/src/wasm/wasm-engine.h
[modify] https://crrev.com/8a95da24150bee6b8b5d63e08f21af756bfe24c4/src/wasm/wasm-js.cc
[modify] https://crrev.com/8a95da24150bee6b8b5d63e08f21af756bfe24c4/test/cctest/wasm/test-streaming-compilation.cc
[modify] https://crrev.com/8a95da24150bee6b8b5d63e08f21af756bfe24c4/test/fuzzer/wasm-async.cc
[modify] https://crrev.com/8a95da24150bee6b8b5d63e08f21af756bfe24c4/test/mjsunit/regress/wasm/regress-837417.js

Affects Node 8, so this will need to be floated on the Node.js side.

(reward-topanel as part of considering issue 835887)

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