Growing a WebAssembly memory detaches the buffer and invalidates every cached typed array view

WebAssembly.Memory.prototype.grow allocates a new backing store and detaches the previous ArrayBuffer. Any Uint8Array or Float64Array created over the old buffer keeps working syntactically but reports a byteLength of 0 and reads nothing, so code that cached a view in a module-level variable starts silently reading zeros after the first growth. In Emscripten builds this is the classic cause of data that becomes empty only for large inputs.

Re-read memory.buffer and rebuild views after anything that can grow memory, which includes every allocation crossing into wasm when the module was built with growth enabled. Emscripten regenerates its own heap views internally, but a JavaScript file that captured one of them once never sees the update. Growth happens in 64 KiB pages, and a grow that cannot be satisfied returns -1 to the module rather than trapping.