Sbox_fatal_memory_exceeded error in Web SDK 1.9.6

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…

Error
sbox_fatal_memory_exceeded

Which Web Client SDK version?
1.9.6

Screenshots

To Reproduce(If applicable)
Join a zoom meeting. Click on Share screen button and share screen with other participants for 20-30 minutes.

Device (please complete the following information):

  • Browser: [Chrome]
  • Browser Version [91.0.4472.124 (Official Build) (64-bit)]

Hey @deepali.necti,

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.

Let me know if that helps.

Thanks,
Max

Hi Max,

I’m getting consistent error on our clients. The chrome task manager shows chrome tab with zoom sdk consume up to 3.2G for 50mins meeting.

  • Only 3 participants
  • 2 participants crashes with the Sbox_fatal_memory_exceeded error
  • Memory usage for chrome tab using zoom web sdk was using 3.2G on my system (i didnt experience crashed)
  • Share screen was happening during the crash
  • Crashes happen twice on one participant and once on the second participant.
  • Were using CDN deployment sample-app-web/CDN at master · zoom/sample-app-web · GitHub

Cheers,
Mark

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)

+1

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.

@markd @vimal @nvivot

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.

Max

@markd @vimal @nvivot

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.

Let me know if that helps.

Thanks,
Max

@MaxM

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.

Today we ran zoom sample app (GitHub - zoom/sample-app-web: Zoom Web SDK Sample App) without any customization or change even it was crashing on Chrome and Edge both when we have screen sharing and video call.

Do you still link this issue with SMID/Origin Trials/ Web Isolation etc?

As per our analysis it seems that there is some memory leak in zoom web sdk after the release of gallery view.

Kindly suggest as it is a blocker for us.

Thank you both for your input here.

@nvivot

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.

Thanks,
Max

@vimal @nvivot

Are you still seeing this issue when testing with 1.9.7 and Origin Trials enabled?

Max

Hi Max,

Yes, This is still happening.

We tested it on following systems along with Zoom v1.9.7 and chrome 92 on Windows 10.

Also, we implemented Web Isolation (as attached) not the Origin Trials with IIS Server referring https://marketplace.zoom.us/docs/sdk/native-sdks/web/advanced/web-isolation

After implementing Web Isolation, we are not seeing SharedArrayBuffer deprecation messages in Console but got below messages in console:

DevTools failed to load source map: Could not load content for https://source.zoom.us/1.9.7/lib/webim.min.js.map: HTTP error: status code 403, net::ERR_HTTP_RESPONSE_CODE_FAILURE

image001.png