Description sbox_fatal_memory_exceeded error crashing the Zoom component and forcing a page reload, this error is coming after zoom web SDK 1.9.6 upgradation from zoom web SDK 1.8.5…
Thank you for reaching out to the Zoom Developer Forum. With such a large jump in versions, you’ll likely need to heavily update your implementation to adjust for the changes. Please use our Sample Web App as a reference when implementing the Web SDK.
I am also facing the same issue. Chrome memory consumption keeps growing when sharing the screen and reached 3.5 GB out of a total of 8 GB system ram.
Using 1.9.6 Web SDK Client, Integrated with my Angular Web APP
Google Chrome Version 91.0.4472.124 (Official Build) (64-bit) (Windows-10)
We also experienced some days/weeks ago a few of these errors on systems having limited memory (4GB, running on Window 10…) with 2 to 3 participants in the meeting. We were still on 1.9.1 at that time, but i assume this is still happening.
Please submit a ticket for this issue by emailing developersupport@zoom.us so we can set up a time to meet and reproduce the issue. In the meantime, please test on the Sample Web App to see if you’re encountering the same issue on lower memory devices.
Please make sure that you have enabled the SIMD and WebCodecs Origin Trials when using the Chrome Browser and that you have also configured Web Isolation. This will ensure that the Web SDK is using the most up-to-date APIs available to the browser and will likely avoid these out of memory issues.
The problem of asking to setup web isolation is that it’s not that easy if we use 3rd party solution that do not support it yet. I’m currently under discussion with such vendor to ask them to support the CORP headers in their HTTP response but this may takes time.
The vendor is Datadog, for their RUM & Browser log components on web applications (but also probably for mobile SDK)
So to make it simple, the situation for us is:
either we loose our monitoring on our application by setting the web isolation
or we continue to have crap performances & bugs on the Zoom SDK (memory issues, video, shared screen)
To go back to this memory issue topic, activating the web isolation would enable us to continue to use the shared array buffer feature.
But currently the SDK is already using that feature, and we have memory issues. So… ?
The Zoom SDK is per definition relying on the CPU and the Memory. But definitely in the later version it’s using more and more memory. Looks like in term of Memory your doing the same logic as for the CPU : just use how much you can.
I probably simplify a bit, but that’s what we see. So the Zoom SDK definitely has some memory “issue” to work on it. It cannot rely on using more and more until it get kicked by the OS or the Web monitor for OOM reason.
Just based on the work that we’ve done in the past, I expect that you have most of this configuration implemented currently. I would just make sure that you have those same OTs enabled alongside SharedArrayBuffer.
@vimal By default, the Sample Web App doesn’t enable the referenced Origin Trials so you’ll want to follow those steps as well just to see if that helps.
Along those same lines, I’m continuing to work with our engineering team to determine the cause of the issue. These configuration steps were meant as initial steps to see if they would help get back on track.
When we have more information on the exact cause here, I’ll let you know.
Thank you for following up. Please make sure that you enable the WebCodecs and SIMD Origin Trials as well as the Web Isolation. This ensures the most efficient operation.
