v8/test/mjsunit/regress/wasm/regress-724846.js

// Copyright 2017 the V8 project authors. All rights reserved.
// Use of this source code is governed by a BSD-style license that can be
// found in the LICENSE file.

d8.file.execute('test/mjsunit/wasm/wasm-module-builder.js');

// Flags: --wasm-max-mem-pages=49151

let builder = new WasmModuleBuilder();
const num_pages = 49152;
builder.addMemory(num_pages, num_pages);
assertThrows(() => builder.instantiate(), RangeError);
[wasm] Stricter max memory check 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/509255 Reviewed-by: Andreas Haas <ahaas@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#45465} 2017-05-22 09:41:02 +00:00			`// Copyright 2017 the V8 project authors. All rights reserved.`
			`// Use of this source code is governed by a BSD-style license that can be`
			`// found in the LICENSE file.`

[d8][mjsunit][tools] Improve d8 file API - Add d8.file.read() and d8.file.execute() helpers - Change tools and tests to use new d8.file helper - Unify error throwing in v8::Shell::ReadFile Change-Id: I5ef4cb27f217508a367106f01e872a4059d5e399 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2928505 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Maya Lekova <mslekova@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#74883} 2021-06-01 12:46:36 +00:00			`d8.file.execute('test/mjsunit/wasm/wasm-module-builder.js');`
[wasm] Stricter max memory check 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/509255 Reviewed-by: Andreas Haas <ahaas@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#45465} 2017-05-22 09:41:02 +00:00
[test][wasm] Allow testing of huge memories This patch maintains the previous default value of the flag controlling the max size of Wasm memories, but allows the limit to be raised on the command line. Bonus content: improve the multi-mapped mock allocator by falling back to regular allocation for small requests. More bonus content: make debug-mode Wasm tests faster. Bug: v8:6306 Change-Id: Idabae5734794b06e65d45b3a6165dbd488847f3f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1981157 Auto-Submit: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#65681} 2020-01-09 17:08:51 +00:00			`// Flags: --wasm-max-mem-pages=49151`
[wasm] Stricter max memory check 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/509255 Reviewed-by: Andreas Haas <ahaas@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#45465} 2017-05-22 09:41:02 +00:00
			`let builder = new WasmModuleBuilder();`
			`const num_pages = 49152;`
			`builder.addMemory(num_pages, num_pages);`
[wasm] Clean up spec'ed max memory vs dynamic max There are two different limits for the maximum memory size in WebAssembly: 1) A 4GB limit which is the same on all platforms, and is observable for JS programs. It is used to limit the allowed declared maximum size of a wasm memory. 2) A potentially lower limit (2GB on 32-bit systems, 4GB otherwise) which can be further limited using a command-line flag. This limit is used whenever actually allocating or growing a wasm memory. This limit is not directly observable, but we make sure that no wasm memory will ever be bigger than this limit. The second limit is the one we should check against when allocating or growing memory, while the first limit should be used when validating a module (or the parameters for WebAssembly.Memory). The compiler can rely on no memory being bigger than the second limit, which again is never bigger than the first limit. This CL adds some more documentation to the two limits, and cleans up all usages. This also makes {kPlatformMaxPages} and {kMaxMemoryPagesAtRuntime} obsolete. R=jkummerow@chromium.org Bug: chromium:1207263 Change-Id: I43541aafd3f497d1c368bd9400e9bc667bdfd3d9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2910787 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#74742} 2021-05-25 10:48:51 +00:00			`assertThrows(() => builder.instantiate(), RangeError);`