Intermittent DeveloperError in Buffer.js When Updating Polylines/PolylineCollections

[shresthaprasun]

I’m encountering an intermittent rendering issue that stops the Cesium viewer with a DeveloperError related to memory allocation when updating polylines. This started occurring after upgrading from v1.119.0 to v1.131.0 (and persists when I revert back to v1.119.0).

The Error

The console error is: DeveloperError: Expected offsetInBytes + arrayView.byteLength to be less than or equal to [sizeInBytes], actual value was [largerValue] (See Screenshot 1).

This error occurs within Buffer.js when attempting to call Buffer.prototype.copyFrom or related functions to upload data to the GPU memory.

Application Context

My application allows users to create guide-lines by clicking on the viewer. These guide-lines are implemented as Cesium Polylines.

• Some guide-lines are single Polyline entities.

• Others are collections of multiple Polyline entities, sometimes with different materials (which might implicitly lead to a PolylineCollection).

The error occurs randomly when updating the positions of these polylines, which I’ve attempted using both ConstantProperty and CallbackProperty for the positions property.

Observations from Debugging

Based on the attached screenshots, I’ve made the following observations about where the error occurs:

1. Location: The error consistently happens inside Buffer.js during a memory update operation (copyFrom or copyFromArrayView), specifically when PolylineCollection.update calls PolylineBucket.writeUpdate (Screenshots 1 & 3).

2. Logic Failure: The error states that:

   offsetInBytes+arrayView.byteLength>sizeInBytes

   • Screenshot 3 shows an example: Expected [...] to be less than or equal to **87364**, actual value was **128448**.

3. Index/Offset Discrepancy: The problem seems related to how the update range is calculated.

   • Screenshot 3 shows the update function calculating index1 and index2.

   • In a failing case (Screenshot 1), index2 is 572 and offset is 87264.

   • My hypothesis is that when index2 is non-zero, the calculation for the offsetInBytes or the byteLength for the update range is incorrect, leading to an attempt to write past the allocated buffer size (sizeInBytes).

4. Implicit Collections:

   • I have a single Polyline that does not use a PolylineCollection and does not throw this error.

   • I have cases where I create a series of polylines, which automatically result in a PolylineCollection. Even when I reduce this to a single polyline entity, the framework still creates a PolylineCollection internally, and this collection sometimes throws the error when its points are updated.

Request for Help

Since I cannot reproduce this in Sandcastle, I suspect this may be due to a specific configuration or an interaction with an older polyline structure or entity management.

Any suggestions on what might cause the discrepancy between the expected buffer size (sizeInBytes) and the calculated update range (offsetInBytes + byteLength) would be greatly appreciated.

Thank you!

[mzschwartz5]

HI @shresthaprasun,

Thanks for the detailed explanation. I wish I could give you the answer, but I think there’s still a lot of unknown details here. I’d like to know what’s going on higher up in the stack when this error occurs, and more about the set up and workflow that leads to this.

Do you think you’d be able to reproduce the error in a minimal sandcastle example? Then I can poke around and generally do more investigation.

Thanks,
Matt

[shresthaprasun]

Hi @mzschwartz5,
I am unable to reproduce error in sandcastle. However I have more information about the code flow.

Even when there is only one polyline and “p=== polyline” is false in line 1741, positionIndex gets increased causing wrong polylinestartIndex.

packages/engine/Source/Scene/PolylineCollection.js

I am unable to figure out yet why this scenario arises, as it seems same references are passed through. But I assume there is some kind of race condition or synchronization error between PolylineCollection and PolylineBucket.