- 30 Jan, 2019 1 commit
-
-
Sven Sauleau authored
We noticed that almost every call site were loading both files, the split isn't necessary anymore. In some message tests, removed the absolute line number to allow future changes. Bug: v8:8726 Change-Id: I8527f0a1ecfa685aa01a5e2f5f47ddf1cb13a545 Reviewed-on: https://chromium-review.googlesource.com/c/1446452 Commit-Queue: Sven Sauleau <ssauleau@igalia.com> Reviewed-by: Ben Titzer <titzer@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#59220}
-
- 09 Apr, 2018 1 commit
-
-
Clemens Hammacher authored
R=eholk@chromium.org Bug: chromium:769637 Change-Id: I347ed1cf6fe567f5a12a8191b224a27336a757d4 Reviewed-on: https://chromium-review.googlesource.com/1000700Reviewed-by: Eric Holk <eholk@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#52493}
-
- 22 Mar, 2018 1 commit
-
-
Eric Holk authored
When using trap handlers, memory references do not get any checks inserted. This means there is no check for a null memory as happens when the memory size is 0. Normally this would be correctly caught as an out of bounds access, since the low memory addresses are not normally mapped. However, if they were mapped for some reason, we would not catch the out of bounds access. The fix is to ensure WebAssembly instances always have a guard region even if the memory is size 0. This is a rewrite of 5e76ff5a Note that this can lead to a large amount of unnecessary address space usage, so we share a single reservation for empty array buffers. Bug: chromium:769637 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng Change-Id: Ia8e84be6d595e347d3d342959f2c374db1a3f683 Reviewed-on: https://chromium-review.googlesource.com/702657Reviewed-by: Deepti Gandluri <gdeepti@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Eric Holk <eholk@chromium.org> Cr-Commit-Position: refs/heads/master@{#52163}
-
- 17 Oct, 2017 1 commit
-
-
Ben L. Titzer authored
R=rossberg@chromium.org Bug: Change-Id: Icac33dc87dd660173e5a45d02b31be46f7d1cb2d Reviewed-on: https://chromium-review.googlesource.com/721550 Commit-Queue: Ben Titzer <titzer@chromium.org> Reviewed-by: Andreas Rossberg <rossberg@chromium.org> Cr-Commit-Position: refs/heads/master@{#48632}
-
- 22 May, 2017 1 commit
-
-
Clemens Hammacher authored
If the maximum number of memory pages is raised using --wasm-max-mem-pages, we might allocate more than kMaxInt bytes for wasm memory. The byte length is stored as int in JSArrayBuffer, hence this can lead to failures. Thus, we now additially check against kMaxInt, and fail instantiation if this check fails. Drive-by: Add/fix more bounds checks. R=ahaas@chromium.org BUG=chromium:724846 Change-Id: Id8e1a1e13e15f4aa355ab9414b4b950510e5e88a Reviewed-on: https://chromium-review.googlesource.com/509255Reviewed-by: Andreas Haas <ahaas@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#45465}
-