Cesium Crash on Chrome Beta

CesiumJS
1

Hi,
This is a Chrome Beta bug, so I didn’t open a github issue on Cesium, but I still thought someone here might want to know. Chrome 84 goes live in about two weeks, and I’m getting an “Aw Snap” crash with Cesium 1.70.1. More details here:
https://bugs.chromium.org/p/chromium/issues/detail?id=1099267

2

Hey @jonathan2,

I’m not able to reproduce this. I’m testing on Windows with Chrome Version 84.0.4147.68 (Official Build) beta (64-bit) with Sandcastle: https://sandcastle.cesium.com/ and I’m not geting any crashes.

And I can’t seem to see the linked Chromium bug - I just see “Permission denied” ?

3

Hi Omar,
I’m Jonathan, one of the web devs from vHive. We spoke before on Cesium Google Groups.

The Chromium bug systems requires a Google login. I’m getting redirected to a login page when I open the link incognito.
I’ll sum up the situation as it stands right now:

  1. On May 20th a WebGL bug was discovered in Chrome by an automated fuzzer (apparently Canary at the time, though I’m not sure)
  2. By the time it was fixed (May 30th), Chrome 84 was branched to beta, and the fix wasn’t merged back to the Chrome 84 version. Chrome 85 contains the fix.
  3. On June 3rd, a crash in Chrome 84 was reported by a user. The crash happens in WebRTC, and causes a tab to show “Aw, Snap!” with the obscure error code " RESULT_CODE_UNINSTALL_USER_CANCEL". At the time there wasn’t any link between the WebRTC crash and the WebGL crash.
  4. On June 25th, as part of testing our app on Chrome Beta, I detected a crash in Cesium 1.57. The crash causes “Aw snap” with the same obscure error code as the WebRTC bug reported on Chrome Beta. Thinking it is caused by the same root cause, I commented on the WebRTC bug with my situation. I was told my crash looks like a different root cause (as it’s WebGL based and not WebRTC based) and was asked to open another issue.
  5. I opened a new issue, which was identified as being caused by the original WebGL bug detected on May 20th. Since its fix wasn’t merged into Chrome 84, I experienced the crash on Chrome Beta 84. One of the Chromium maintainers made the connection between the three issues (the original WebGL, the WebRTC and my reported issue). He/she also confirmed that the fix will not be included in Chrome 84, and that Chrome 85 will be the first version with the fix.
  6. Identifying there might be a potentially serious issue with Cesium and Chrome 84, I created this post. I tested Chrome 84 with Cesium 1.70.1, and our app still crashes. I tested Chrome 85 Canary with Cesium 1.70.1 and there is no crash.
  7. I am not getting any crashes on Chrome Beta 84 with Cesium Sandcastle (I clicked through all the tutorials section one-by-one). Apparently there is a specific Cesium configuration used by our app that causes the crash. I haven’t had the time yet to create a small reproducible testcase that I can share with the public. I can say, however, that we only use documented Cesium API’s, so the crash is very likely to affect more Cesium users.
  8. Our app doesn’t use any other WebGL components, so it’s unlikely the crash is caused by Chrome 84 and a different WebGL call unrelated to Cesium.
  9. I think we should work together to identify the problem and perhaps contact the Chrome/Chromium team with our findings.
  10. Response time is important, Chrome 84 is scheduled to be released in two weeks.

Jonathan

4

Yeah anything you can share here would help narrow it down. Are you sure it’s something in the way you’re using CesiumJS and not something else on the page triggering this? I’m curious if you have another WebGL canvas on the page that’s not managed through CesiumJS if that’ll crash (because if it does then there’s nothing we can do on the CesiumJS side to mitigate).

The Sandcastle examples do cover a pretty wide array of functionality - can you think of anything your app is using that aren’t there? Does the crash happen immediately at startup?

5

Hi Omar,
Thanks for the response.
I was able to identify the Cesium API call that caused the crash.
Here is a sandcastle that crashes Chrome 84 Beta, not Chrome 83 Stable and not Chrome 85 Canary: Link

Simply uncomment line 16 and click Run to provoke the crash.
Here is the code in case the Sandcastle has issues loading:

var viewer = new Cesium.Viewer("cesiumContainer");
Cesium.when(
    Cesium.Resource.fetchImage("../images/Cesium_Logo_overlay.png"),
    function (image) {
      
      if (!(image instanceof HTMLImageElement)) return;
      
      viewer.entities.add({
        position: Cesium.Cartesian3.fromDegrees(-75.59777, 40.03883),
        billboard: {
          image
        },
      });
      
      const emptyImg = document.createElement('img');
      //emptyImg.src = "data:image/png;base64,";
      viewer.entities.add({
        position: Cesium.Cartesian3.fromDegrees(-75.59777, 40.03883),
        billboard: {
          image: emptyImg
        },
      });
    }
  );

I’m happy to say this downgrades the severity, as it happens only when passing an empty ImageElement to the billboard entity.
However, I do believe this shouldn’t result in a complete crash of the Chrome tab. There might even be a security issue here by sending a malformed image.

I will circumvent the issue on my side of the code. We used sending empty images as a generic way to display information on Cesium even if the image wasn’t there, I’ll just make the necessary adjustments.

I’ll update the Chromium issue with this new info as well.

Thanks, take care.
Jonathan

1 Like
6

Chrome will merge the fix into the upcoming version, see the original chromium bug for details.

7

Despite my previous post, Chrome 84 Beta has not been updated beyond 84.0.4147.68, and this crash still happens. 84 Stable is due to be released in a week. I don’t know if the released version will contain the fix.

8

Confirmed fixed on Chrome Beta 84.0.4147.85

1 Like