Race condition in Cesium3DTileset / Reconsider `readyPromise` pattern
See original GitHub issue- Paste this into a new file called
aTrivialSpec.js
intopackages/engine/Specs/Scene/
.
import { Cesium3DTileset, DeveloperError } from "../../index.js";
import createScene from "../../../../Specs/createScene.js";
fdescribe("trivialSpec", function () {
let scene;
beforeAll(function () {
scene = createScene();
});
afterAll(function () {
scene.destroyForSpecs();
});
it("a trivial test", function () {
const tileset = new Cesium3DTileset({ url: "test.invalid" });
expect(function () {
throw new DeveloperError();
}).toThrowDeveloperError();
tileset.destroy();
});
});
- Run the unit tests
- Most of the time it will fail/hang with the below error
$ npm -- run test --browsers ChromeHeadless
> cesium@1.99.0 test
> gulp test --browsers ChromeHeadless
[20:29:15] Using gulpfile ~/Git/CesiumGS/cesium/gulpfile.js
[20:29:15] Starting 'test'...
trivialSpec
✓ a trivial test
Chrome Headless 107.0.5304.110 (Linux x86_64) ERROR
An error was thrown in afterAll
Unhandled promise rejection: Request has failed. Status Code: 404 thrown
Chrome Headless 107.0.5304.110 (Linux x86_64) ERROR
An error was thrown in afterAll
Unhandled promise rejection: Request has failed. Status Code: 404 thrown
0.068 secs: trivialSpec a trivial test
0 secs: Renderer/Buffer fails to destroy: WebGL 2
0 secs: Renderer/Buffer fails to copy a large array view: WebGL 2
0 secs: Renderer/Buffer fails to provide an array view: WebGL 2
0 secs: Renderer/Buffer destroys: WebGL 2
0 secs: Renderer/Buffer copyFromBuffer with index buffers: WebGL 2
0 secs: Renderer/Buffer copyFromBuffer with vertex buffers: WebGL 2
0 secs: Renderer/Buffer copyFromBuffer throws when readBuffer is the same buffer and copy range overlaps: WebGL 2
0 secs: Renderer/Buffer copyFromBuffer throws with one index buffer and the other is not an index buffer: WebGL 2
0 secs: Renderer/Buffer copyFromBuffer throws with invalid sizeInBytes: WebGL 2
Chrome Headless 107.0.5304.110 (Linux x86_64): Executed 1 of 13836 (skipped 156) ERROR (0.02 secs / 0.068 secs)
[20:29:18] Finished 'test' after 2.51 s
Chrome Headless 107.0.5304.110 (Linux x86_64) ERROR
Disconnected , because no message in 120000 ms.
Chrome Headless 107.0.5304.110 (Linux x86_64) ERROR
Disconnected , because no message in 120000 ms.
0.068 secs: trivialSpec a trivial test
0 secs: Renderer/BuiltinFunctions has czm_transpose (4x4)
0 secs: Renderer/BuiltinFunctions has czm_transpose (3x3)
0 secs: Renderer/BuiltinFunctions has czm_transpose (2x2)
0 secs: Renderer/AutomaticUniforms can declare automatic uniforms
0 secs: Renderer/AutomaticUniforms has czm_viewport
0 secs: Renderer/AutomaticUniforms has czm_viewportOrthographic
0 secs: Renderer/AutomaticUniforms has czm_viewportTransformation
0 secs: Renderer/AutomaticUniforms has czm_globeDepthTexture
0 secs: Renderer/AutomaticUniforms has czm_model
- It seems to happen more often with
npm -- run test --browsers ChromeHeadless
, but since it’s a race condition it’s hard to say why.
I’m fairly certain what’s happening is that Cesium3DTileset
has an async code path that keeps running, even after destroy
is called (and therefore after the test is finished). In 99.99% of the times I’ve seen this error from karma/jasmine, that’s always been the case in general.
Issue Analytics
- State:
- Created 10 months ago
- Comments:11 (11 by maintainers)
Top Results From Across the Web
Issues · CesiumGS/cesium - GitHub
Race condition in Cesium3DTileset / Reconsider readyPromise pattern category - 3d tiles test failure type - bug. #10909 opened on Nov 16 by...
Read more >Cesium3DTileset - Cesium Documentation
When true , the tileset's root tile is loaded and the tileset is ready to render. This is set to true right before...
Read more >What is a Race Condition? - TechTarget
They occur when two computer program processes, or threads, attempt to access the same resource at the same time and cause problems in...
Read more >1.2 Race Conditions — Parallel Computing for Beginners
This section builds on the simple fork-join and SPMD patterns and introduces the notion of a race condition. By the end of this...
Read more >Race Conditions :: CC 410 Textbook
A race condition occurs when two threads in a program are trying to update the same value at the same time. ... It...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
I do agree that this is a fundamental problem that needs fixing. I think this is alluded to in a few other issues, but does not have its own, so we can use this one to track it.
When reviewing the handling of promise chains and
catch
usage, one might want to have a look at theViewer#updateZoomTarget
function. It has two very similar code blocks for the zoom target being aCesium3DTileset
or aTimeDynamicPointCloud
, with the latter omitting athat is present in the former. (Omitting this may or may not be intentional, but that could be part of the review - maybe the code block could be moved into a method to handle both target types equally…?)