Cesium 'Invalid array length' error in updateFrustums

We’re having a complex issue with Cesium rendering. It only seems to occur in some applications on some machines with some versions, and we haven’t yet found the common factor.

We use Cesium b25 with a custom render loop which gives the trace, but the same error occurs with the default render loop (it’s just caught and logged differently). Basically, the error is the following:

Uncaught RangeError: Invalid array length       Scene.js:454
updateFrustums                                  Scene.js:454
createPotentiallyVisibleSet                     Scene.js:609
Scene.render                                    Scene.js:911
CesiumWidget.render                             CesiumWidget.js:539
Viewer.render                                   Viewer.js:728
(anonymous function)

I believe the issue doesn’t occur with b19, and the cause seems to be that the horizonDistance is MAX so the Occluder test returns false and the test in updateFrustum falls through to continue instead of setting the near value, thus near ends up equal to far and numFrustums is 0, which is illegal at some point. The render loop runs happily in the background, but fails as soon as we try to actually show the Cesium widget.

I can give you some more information if it helps, but I haven’t been working on this part and its growing like a weed with build systems and submodules and the like. Do you have any pointers that we might investigate?

[shunter]

Most of what you describe is already in place. Throughout Cesium, we check input parameters and throw DeveloperErrors when invalid data is passed into function. In the minified release build, these checks are removed. For that reason, we recommend developing against the unminified file to catch errors early.

In your particular example (passing a Cartographic to a function that expects a Cartesian), however, we don’t have a check for that case. We do check to make sure that the destination is defined, but nothing beyond that.

[aramk]

Thanks for that explanation. Generally we want bad programs to fail early. I suppose one way would be to ensure all public method contracts fail if provided with invalid arguments on construction. The benefit being that users can never feed in bad data. The disadvantage may be very negligible performance loss not worth mentioning, but also taking the time to add and maintain these checks. Another approach could be to use an assertion library and then disable this in production code during the build. I think it would be a huge advantage in cutting down the time taken to find and resolve these bugs, especially in larger codebases.