The bug here is very subtle, as is the mitigation.
Quick background on WASM memory, there is an object
called wasmMemory (which might be hoisted into scope for
CanvasKit's pre-js functions), of type WebAssembly.Memory
which is a resizable ArrayBuffer. Emscripten provides the
JS code to initialize this and handle size increases.
Emscripten also provides TypedArray "views" into this buffer.
These are called CanvasKit.HEAPU8, CanvasKit.HEAPF32, etc.
When there is a call to CanvasKit._malloc, wasmMemory may
be resized. If that happens, the previous TypedArray views
become invalid. However, in the same call to _malloc,
emscripten will refresh the views [1]. So, dealing with
CanvasKit.HEAPU8 directly (quick aside, we never expect clients
to mess with these views, only us in our glue JS code
[e.g. interface.js]), should always be safe because if they
were to be invalidated in a call to _malloc, the views would
be refreshed before _malloc continues.
The problem that existed before was when we were passing
CanvasKit.HEAP* as a parameter to a function, in which the
function would call _malloc before using the typed array
parameter:
//... let us suppose wasmMemory is backed by ArrayBuffer D
copy1dArray(arr, HEAPU32);
// The HEAPU32 TypedArray (backed by ArrayBuffer D) is stored
// to a function parameter "dest"
function copy1dArray(arr, dest, ptr) {
// ...
if (!ptr) {
ptr = CanvasKit._malloc(arr.length * dest.BYTES_PER_ELEMENT);
// Suppose _malloc needs to resize wasmMemory and is
// now backed by ArrayBuffer E.
// Note: The field CanvasKit.HEAPU32 is correctly backed
// by ArrayBuffer E, but variable dest still points to a
// TypedArray backed by ArrayBuffer D.
}
// dest.set will fail with a "neutered ArrayBuffer" error
// because ArrayBuffer D is effectively gone (replaced by E).
dest.set(arr, ptr / dest.BYTES_PER_ELEMENT);
The fix here is to pass in the field name indicating the TypedArray
view we want to write our data into instead of using the
view itself as the parameter.
[1] e427159553/src/preamble.js (L344)
Change-Id: I46cfb98f8bdf928b61690a5ced034a5961356398
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/294516
Reviewed-by: Nathaniel Nifong <nifong@google.com>
At startup, we allocate a few scratch arrays and then use those
instead of having to malloc and free a bunch of arrays during
runtime.
The benchmark that was added is a bit noisy (probably because
of the garbage collection going on from the created Float32Arrays),
but a few percent faster.
We also don't set the paragraph background/foreground colors to
transparent because we check them being falsey before sending them
over the wire. I noticed that if foreground was transparent black,
no text shows up at all, which was unexpected.
Change-Id: I9f3a590a122d7de222cb5f58ea40e86b2d261c96
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/292685
Reviewed-by: Nathaniel Nifong <nifong@google.com>
If ever CanvasKit accepts an array as a parameter, if the array
provided was produced by Malloc, CanvasKit will use the pointer
of that array and not free it after.
Change-Id: I4806a48e5e030edd787944f652984ea3516b3022
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/292561
Reviewed-by: Nathaniel Nifong <nifong@google.com>
Currently just for image drawable, but going to use this for
references to other kinds of data in bindings, too.
Change-Id: Ic6673530013337bbaadd2d3f1c040626ec24ffb8
Bug: skia:9513
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/256776
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Kevin Lubick <kjlubick@google.com>
