Stack trace unminify throws "memory access out of bounds" in wasm code

[Justin Ridgewell]

RuntimeError: memory access out of bounds
    at wasm-function[18]:5277
    at wasm-function[27]:66
    at BasicSourceMapConsumer._parseMappings (/app/node_modules/source-map/lib/source-map-consumer.js:329:47)
    at BasicSourceMapConsumer._getMappingsPtr (/app/node_modules/source-map/lib/source-map-consumer.js:315:12)
    at _wasm.withMappingCallback (/app/node_modules/source-map/lib/source-map-consumer.js:510:14)
    at Object.withMappingCallback (/app/node_modules/source-map/lib/wasm.js:95:11)
    at BasicSourceMapConsumer.originalPositionFor (/app/node_modules/source-map/lib/source-map-consumer.js:508:16)
    at unminifyFrame (/app/utils/unminify.js:79:49)
    at stack.map (/app/utils/unminify.js:153:36)
    at Array.map (<anonymous>)

go/ampe/CLTN18zhofuIDg

From the Oxidizing Source Maps with Rust and WebAssembly article, the author seems aware of this:

With the WebAssembly implementation, Chrome would erroneously throw RuntimeError: memory access out of bounds. Using Chrome’s debugger, the supposed out-of-bounds access was happening in an instruction sequence that does not exist in the .wasm file. All other browser’s WebAssembly implementations successfully ran the benchmark with this input, so I am inclined to believe it is a bug in the Chrome implementation.

We should consider downgrading the source-map dep to see if it'll fix the issue.