WebAssembly.Memory(): could not allocate memory about cornerstone3d HOT 18 CLOSED

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

from cornerstone3d.

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

from cornerstone3d.

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.

from cornerstone3d.

@jpambrun windows?

from cornerstone3d.

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: cornerstonejs/codecs@c71c358

from cornerstone3d.

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?

from cornerstone3d.

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 (#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.

from cornerstone3d.

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

from cornerstone3d.

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?

from cornerstone3d.

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

from cornerstone3d.

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

from cornerstone3d.

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

from cornerstone3d.

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

from cornerstone3d.

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

from cornerstone3d.

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

from cornerstone3d.

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.

from cornerstone3d.

Can you try again on the latest main branch and let us know if this is still an issue?

from cornerstone3d.

I don't see the issue anymore 👍🏼

from cornerstone3d.