WebAssembly.Memory(): could not allocate memory

[daker]

I have two graphic cards on my workstation, the one plugged with the monitor is Intel HD 530. While trying the examples Chrome crashes and FF is really slow and complains that page is slowing the browser.

Chrome version: 100.0.4896.60

CornerstoneRender: Using detect-gpu to get the GPU benchmark: {device: undefined, fps: 55, gpu: 'intel mesa intel hd graphics 530', isMobile: false, tier: 2, …}
device: undefined
fps: 55
gpu: "intel mesa intel hd graphics 530"
isMobile: false
tier: 2
type: "BENCHMARK"
[[Prototype]]: Object
12:52:54.544 init.ts:55 CornerstoneRender: using GPU rendering
12:52:54.545 dicomweb-client.es.js:1086 retrieve metadata of series 1.3.6.1.4.1.14519.5.2.1.7009.2403.226151125820845824875394858561
12:52:54.823 dicomweb-client.es.js:1086 retrieve metadata of series 1.3.6.1.4.1.14519.5.2.1.7009.2403.879445243400782656317561081015
12:52:57.905 RenderingEngine.ts:103 [Violation] 'requestAnimationFrame' handler took 1818ms
12:52:59.093 index.worker.min.worker.js:1 Uncaught RangeError: WebAssembly.Memory(): could not allocate memory
    at o (index.worker.min.worker.js:1:81364)
    at I (index.worker.min.worker.js:1:154829)
    at ke (index.worker.min.worker.js:1:168400)
    at Object.initialize (index.worker.min.worker.js:1:169326)
    at index.worker.min.worker.js:1:153529
    at Array.forEach (<anonymous>)
    at index.worker.min.worker.js:1:153503
    at self.onmessage (index.worker.min.worker.js:1:153665)

is it supposed to fallback to CPU?

[swederik]

I think this isn't a GPU issue exactly, but more likely the example is spinning up too many web workers which are consuming too much memory on your system and crashing chrome. How many cores does your computer have? (navigator.hardwareConcurrency)?

This PR should hopefully fix it (https://github.com/cornerstonejs/cornerstone3D-beta/pull/47). The docs will be updated shortly, it's still building, and then maybe you could re-test it?

Firefox slowness is a known issue, I think. I believe it's this: https://bugzilla.mozilla.org/show_bug.cgi?id=1602299 It's an issue with the copy from the off-screen to on-screen canvases being slow on Firefox.

[daker]

I think this isn't a GPU issue exactly, but more likely the example is spinning up too many web workers which are consuming too much memory on your system and crashing chrome. How many cores does your computer have? (navigator.hardwareConcurrency)?

navigator.hardwareConcurrency
> 8

[swederik]

The live example should be updated now. If that didn't fix it, I'm not sure what the problem is.

Are you on Windows?

[JamesAPetts]

We are investigating this, seems to be a ram spike.

[daker]

The live example should be updated now. If that didn't fix it, I'm not sure what the problem is.

Some works, some not, for ex this one snaps : https://www.cornerstonejs.org/live-examples/multivolumeapi

Are you on Windows?

Yes Win 10 20H2

[daker]

We are investigatin this, seems to be examples on all Windows machines.

For those examples make Chrome snap with error code: SBOX_FATAL_MEMORY_EXCEEDED https://www.cornerstonejs.org/live-examples/multivolumeapi https://www.cornerstonejs.org/live-examples/multivolumecanvastoworld https://www.cornerstonejs.org/live-examples/stackcanvastoworld

[jpambrun]

I have the same issue. I have 16 core and all example attempt to load 7 workers, each consuming 2 GB of RAM presumably for wasm heap. Even the trivial one image sample[1] crashed about 50% of the time.

[1] https://www.cornerstonejs.org/live-examples/stackbasic

[sedghi]

@jpambrun windows?

[daker]

To confirm what @jpambrun said, the tab is consuming 14GB.

[jpambrun]

Windows, yes. The issue is that codecs were compiled with pre-allocated large heaps and too many worker are spawned. I think the maximum of allocable typedarray per chrome process is 14GB on windows[1]. Main renderer and dedicated workers all share the same process/memory pool.

[1] https://bugs.chromium.org/p/chromium/issues/detail?id=1243314

[swederik]

Can you try this link?

https://6246f5ad453f451f7bc3aa19--cs3d-docs.netlify.app/live-examples/petct

It disables the codec initialization on startup for now.

We had tested on windows before and never had these issues. I wonder if the OpenJPEG codec initialization's high memory usage is related to this commit: https://github.com/cornerstonejs/codecs/commit/c71c3584273497e859737c5db9f008490d77c845

[jpambrun]

It is working with a more reasonable 350MB or memory usage across the renderer and workers.

[jpambrun]

The 1GB heap is defined here for j2k https://github.com/cornerstonejs/codecs/blob/main/packages/openjpeg/src/CMakeLists.txt#L35

[jpambrun]

The other part of the issue is here: https://github.com/cornerstonejs/cornerstone3D-beta/blob/a0eefdc34e171ac35375fe58c5da75575ed6d46e/utils/demo/helpers/initCornerstoneWADOImageLoader.js#L18

You allow up to 7 workers (if number of cores allows) and each take 2GB of memory (OpegJpeg + another codec?). On the other hand, chrome 100 on windows allows only for ~14GB or memory to be used in typed array (used to be 8GB in chrome 99-). So it crashed very often.

[JamesAPetts]

Yeah we've used 7 max in old cornerstone since time immemorial, it seems recent changes to the codecs have blew up RAM usage on initialisation.

[toropok]

Hi,

We have same issue on Samsung Galaxy Tab A SM-T515 Android (11) Chrome (105.0.5195.136):

Uncaught RangeError: WebAssembly.Memory(): could not allocate memory
    at B (1fee6cb6-8d13-4e2d-9908-ca27015f5a78:formatted:4505:52)
    at H (1fee6cb6-8d13-4e2d-9908-ca27015f5a78:formatted:9397:24)
    at LA (1fee6cb6-8d13-4e2d-9908-ca27015f5a78:formatted:10136:56)
    at Object.initialize (1fee6cb6-8d13-4e2d-9908-ca27015f5a78:formatted:10163:17)
    at 1fee6cb6-8d13-4e2d-9908-ca27015f5a78:formatted:9293:38
    at Array.forEach (<anonymous>)
    at 1fee6cb6-8d13-4e2d-9908-ca27015f5a78:formatted:9292:36
    at self.onmessage (1fee6cb6-8d13-4e2d-9908-ca27015f5a78:formatted:9304:22)

is there any workarounds for mobile devices?