TypedArray creation crashes Chrome 31

Question

I've chased a crash lazily for some time, but now it should be found: Chrome dies with its "Snap!" message after some time on a WebGL page, while Firefox runs without problems.

After about 27 thousand iterations through the following fragment, it snaps when creating the Float32Array:

webglContext.bindBuffer (webglContext.ARRAY_BUFFER, buffer.webglBuffer);
typedArray = new Float32Array (buffer); <- SNAP!
//typedArray = new Float32Array (buffer); (1)
webglContext.bufferData (webglContext.ARRAY_BUFFER, typedArray, webglContext.STATIC_DRAW);
//typedArray = null; (2)
webglContext.vertexAttribPointer (attribute, buffer.itemSize, webglContext.FLOAT, false, 0, 0);

As you can see, I'm binding a previouly created (once) webgl buffer, turn a native array into a typed one, pass the typed array to webgl, and finish by telling webgl which attribute to use for it.

Now the strange facts around this:

• Firefox runs the page for hours without interruption, Chrome crashes after a few minutes - after ca. 27 thousand iterations (wide variation in the number of successful iterations)
• I have different buffers for vertex positions, colors, textures, texture coordinates. Chrome always crashes on the positions buffer, which I pass to webgl first in a drawing cycle.
• The buffers are really large, ca. 150.000 Numbers in the positions buffer
• In DevTools I see nothing suspicious (I am new to this tool, though)
  • Timeline>Memory raises from 10 to 18 MB in 1.5 secs, falls back to 10 MB, and the crash occurs when it has risen to ca. 14 MB again
  • Heap>Snapshots>Comparison shows a few Numbers have added/removed (equal counts)
• Clearing typedArray after use by uncommenting (2) does not help
• Doubling the work by uncommenting (1) remedies the problem

I stumbled across the last fact only by chance, since I wanted to reduce the time to wait for the crash - but I've never seen a crash when creating the typed array twice.

Using Chrome 31.0.1650.63 m, and adding webgl tag since I think this might be related to the amount of data...

Thanks for any thinking...