Fix bad access to detached ArrayBuffer in $growMemory.

[juj]

Consider:

var m = new WebAssembly.Memory({initial: 64});
var b = m.buffer;
m.grow(64);
console.log(b.byteLength);

This will print 0 instead of the old memory size before growing (or the new memory size after grow), because b got detached by the grow.

This caused bad assertions error print, and incorrect profiling.

To fix, avoid referencing a detached buffer.

[RReverser]

Can we add a regression test that would catch this issue?

[sbc100]

Maybe we lack testing for the onMemoryResize callback? Perhaps we could add a test to test_other.py that exercises -sMEMORYPROFILER? (I assume its this callback that is getting the wrong data in this case?)

[juj]

We recently had a "hackweek" at Unity, where we worked on rewriting the built-in --memoryprofiler, to replace it with a more robust pluggable one. I don't have much excitement to improve the old one, but I'm hoping to propose the new memory profiler as a replacement at some point.

[sbc100]

Fair enough, this seems like a fairly obvious change.

Does your new profiler use the same callback system?

[juj]

Does your new profiler use the same callback system?

Yes, effectively. It additionally adds two new JavaScript side tracing functions to enable tracking JS side object lifetimes, and revamps the visualization.