-
Notifications
You must be signed in to change notification settings - Fork 3.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PolylineCollection update instanceIndex is out of range #8321
Comments
Hello @tinco, I believe we fixed this issue in a newer version of CesiumJS. Can you try updating to the latest release and see if you still experience the problem? |
hi @hpinkos thanks for the quick reply! I just upgraded to Cesium 1.62, and the error definitely became less reproducible, it takes a couple tries before it breaks now. |
Thanks for trying that out @tinco. Could you put together a code example that reproduces the issue in Sandcastle? That would be a big help for us tracking down the problem. Here are examples of similar crashes we've fixed previously, if it's helpful to see their code examples: #4983 (comment) #7153 (comment) |
Hi, thanks for the examples. We've been trying to reproduce in Sandcastle, but haven't had any luck so far. It seems that disabling the positions callback fixes our problem, but disabling requestRenderMode also does. My colleague is working on a bigger Sandcastle right now to see what else we need from our app to reproduce the problem. |
Thanks for taking the time to put this together @tinco |
I just noticed that it reliably happens when I switch away from the tab for a couple minutes and then switch back. I have no idea what that means. I guess maybe chrome buffers the intervals and then runs a bunch in quick sequence and that makes it more likely for the bug to happen? |
Thanks @tinco . I am able to reproduce this. Were you able to get the same issue using any of the tilesets already on Cesium ion (like this photogrammetry one https://sandcastle.cesium.com/index.html?src=3D%20Tiles%20Photogrammetry.html) ? That way you won't have to have a public link to your dataset if you can't share it. |
No worries @OmarShehata, the data is not really secret or anything. Good to hear you were able to reproduce, did you also trigger it by switching tabs? In our real app there was some sequence of actions that would reliably trigger the exception without switching tabs. I think I'll spend some time this week or the week after improving the sandcastle or maybe digging through the source to find the source of the race condition. |
@tinco yes I was able to trigger it by switching tabs (didn't try leaving it long enough without switching). I have run into a similar behavior where a CesiumJS app will crash if the tab is switched away for too long (although only on Linux, and I haven't been able to consistently reproduce), so creating and digging into a reproducible example here is definitely helpful! |
@tinco sorry for the delay on this. We've been able to reproduce the issue but haven't tracked down exactly what is causing the error yet. We'll keep you posted when we have updates. Thanks |
@tinco I'm pretty positive that requestRenderMode combined with viewer.flyTo is the primary culprit here but haven't been able to track down exactly how. If I change your example to the below, the problem goes away: setInterval(async () => {
testCase.drawElement(element)
viewer.scene.requestRender();
await delay(1000)
testCase.selectPart(element.parts[0], 'first part')
viewer.scene.requestRender();
await delay(1000)
testCase.selectComponentPart(element.parts[0].componentParts[0], 'first component part')
viewer.scene.requestRender();
await delay(1000)
testCase.selectComponentPart(element.parts[0].componentParts[1], 'second component part')
viewer.scene.requestRender();
await delay(1000)
testCase.selectPart(element.parts[1], 'second part')
viewer.scene.requestRender();
}, 5000) In fact, it seems only a single requestRender call may actually be needed. The below change fixes your demo (as far as I cantell). setInterval(async () => {
testCase.drawElement(element)
viewer.scene.requestRender();
await delay(1000)
testCase.selectPart(element.parts[0], 'first part')
await delay(1000)
testCase.selectComponentPart(element.parts[0].componentParts[0], 'first component part')
await delay(1000)
testCase.selectComponentPart(element.parts[0].componentParts[1], 'second component part')
await delay(1000)
testCase.selectPart(element.parts[1], 'second part')
}, 5000) The intent of the above change is to continue to use requestRenderMode, but also inform Cesium after the scene changes so that it will render a single frame and performany bookeeping that the Entity API needs to do. The general idea of requestRender mode is that you call scene.requestRender whenever you change anything about the scene manually. Whileit works without calls to Can you test this change to see if the problem goes away? If so, can you then test that change in your real application and report back? Thanks. |
Thank you @mramato, so your fix is to reduce the amount of request renders, so the scene has some time to naturally go through the rendering? I get that might fix the problem in the test demo, but I don't think that's a feasible fix for us. I make the calls to requestRender because I can't be sure there is other movement going on that will eventually trigger the render. Sometimes the camera doesn't have the move, and cesium is done loading the highest quality, and all the I get the code paths intermingling here are pretty complex, but why is calling requestRender different than just having cesium continuously render? If flyTo was able to go out of sync with render calls, would that problem not be even bigger if requestRenderMode was off? By the way, I also get this error when flyTo is not active, I think it's purely an interaction between |
Here's a reduced test case I got over email. I'm able to pretty consistently reproduce this now, crashes almost immediately when switching out to another tab and back. |
Browser: Chrome
Operating System: MacOS
Cesium version: 1.5.3
Hi, we have an app where we create and destroy a bunch of Polyline's. Basically the user cycles through different polylines, and every time they select a new one we delete the ones they were previously looking at and create the ones they're looking at now using.
The polylines also have a
CallbackProperty
on thepositions
property that updates the positions every frame.We get an error from Cesium originating on this line:
https://github.com/AnalyticalGraphicsInc/cesium/blob/d26ccfea38dcf4623cf5da3faca141913c64cfe1/Source/Scene/PolylineCollection.js#L471
Quite reliably when we delete a set of polylines and then immediately render frames. If we remove the
CallbackProperty
the error does not occur.Are we hitting some race condition bug where callback properties are setting a dirty flag on polylines that already have been deleted?
We're creating the polylines with
viewer.entities.add
and destroying them withviewer.entities.remove
.The text was updated successfully, but these errors were encountered: