Intermittent CesiumJS Rendering Crash – WebGL2 shaderSource Error

[Efraim-Benezra_GLOBA]

Hello Cesium Support Team,

I am reaching out for assistance regarding an intermittent rendering crash in our CesiumJS-based application. We see this issue during map initialization or when loading entities, and it occurs unpredictably in production.

We consistently receive the following runtime error:

An error occurred while rendering. Rendering has stopped.

TypeError: Failed to execute ‘shaderSource’ on ‘WebGL2RenderingContext’:

parameter 1 is not of type ‘WebGLShader’.

We also see Chrome DevTools reporting that the render process unexpectedly terminates:

Debugging connection was closed. Reason: Render process gone.

Environment Details

• Browser: Google Chrome 114.0.5

• CesiumJS Version: (114)

• GPU: Hardware supports 3D + WebGL

• Context: WebGL2

• Environment: Production

• Features: Using Cesium Custom Shaders + multiple 3D entities

Observed Behavior

• The crash is random, not tied to specific user actions.

• It typically occurs during scene load (“Initializing entities”).

• When the error appears, Cesium stops rendering entirely.

• The issue seems related to shader creation or WebGL2 context loss.

Screenshots

Below are screenshots showing the crash, error dialogs, and DevTools output:

Screenshot 1 – Rendering crash message

Screenshot 2 – DevTools showing WebGL shaderSource error

Screenshot 3 – Full stack trace and error screen

Questions for Support

1. Is this a known CesiumJS issue with WebGL2 or custom shader handling?

2. Are there recommended mitigation steps (memory settings, context options, shader limits, etc.)?

3. What is the recommended approach for handling WebGL context loss in Cesium?

4. Could this be caused by custom shaders combined with 3D Tiles?

5. Are there fixes for this issue in more recent Cesium releases?

Any guidance would be greatly appreciated. The issue is affecting production stability, and we would like to understand the root cause and recommended remediation.

Thank you very much.

Best regards,

Efi Ben Ezra

Efi.BenEzra@elbitsystems.com

[jjhembd]

Hi @Efraim-Benezra_GLOBA, I’m only seeing the first screenshot. Can you please post the other two images? I’m especially interested in the stack trace for the shaderSource error.

[Efi_Ben_Ezra]

Hi,

Attach is more pictures.

Thanks.

Efi.

[Marco13]

Just judging from the error messages, the “normalized result is not a number” and the “Failed to execute ‘shaderSource’” errors look like they might be unrelated - but it’s not impossible that one of them causes the other.

Custom shaders have nearly no “security nets”. They are very powerful, but the user is responsible to ensure their correctness.

Beyond that, the (photos of) stack traces may not be so helpful for analyzing (and solving) the issue. Things that could be worth trying:

• If possible, running this using a non-minimized version of CesiumJS could make the stack traces clearer. (Instead of at tR.execute, it would then say the actual class name - for example, at CustomShader.execute or so).
• You could try to run the application without custom shaders (just leaving the default shaders). If this is possible then it could help to narrow down the reason for the error. For example, when the “normalized result is not a number” error then still appears, it’s clear that this is caused by the entitiy creation itself, and not by the shaders
• Ideally, if it is possible to post a minimal Sandcastle where the error can be obserted (maybe only creating a single entity, and only a “dummy” Custom Shader), then people could more dedicatedly analyze this issue