Android 10: "CONTEXT_LOST_WEBGL: loseContext: context lost"

[jwoodwardtfx]

We have a few Samsung A7 (2018) devices which have recently (in the last week) updated to Android 10 (from Android 9).

We have a custom web app using MapBox which displays a detailed map (built on the Android WebView component). If the map is left on screen for a long period of time (several hours) the map vanishes (and replaced by a tiny sad face) and we get an error reported when we attach the Chrome Debugger: "CONTEXT_LOST_WEBGL: loseContext: context lost"

At this point if we try to destroy and recreate the map we get an error saying WebGL cannot be initialised.

If we try and get a working WebGL context we get NULL returned, i.e.: var tempcanvas = document.createElement('canvas'); tempcanvas.getContext('webgl');

So it looks like WebGL has "died" for the WebView page. If we reload the page it springs back in to life.

This problem was never seen on the same device on Android 9.

Any ideas or pointers where to look for an issue? We've tried the same app on various other phones running Android 10 and as of yet have not hit the same problem. With a Samsung A7 (2018) running Android 10 it is repeatable (and has occurred on several phones).

I understand this may end up being a device-specific GPU firmware or Android 10 issue, but any pointers or tips would be greatly appreciated.

(apologies, I previously added this comment to another issue without realising it had already been closed)

[karimnaaji]

This type of context loss issue is being tracked this in https://github.com/mapbox/mapbox-gl-js/issues/9516 which has useful information on easy reproduction steps. We'll close this to remove duplication, feel free to add information on that issue.

[jwoodwardtfx]

Apologies, but I don't think this relates to #9516.

That issue is about losing and restoring a context (and adding support to MapBox to do this).

My issue seems to be that when the context is lost it is impossible to restore/create a new one until the browser is restarted. I feels more like a crash inside some bit of browser/WebGL/GPU driver code triggered by the map.

Is there any logging/debug info available inside MapBox that may help identified what is triggering this?

[karimnaaji]

You pointed to #9615 which is a very different issue than https://github.com/mapbox/mapbox-gl-js/issues/9516. Are you sure https://github.com/mapbox/mapbox-gl-js/issues/9516 isn't related to your case?

[jwoodwardtfx]

Sorry, typo on my part. It should have read #9516 (edited previous post to fix).

That post is talking about a normal loss/restore of a context (and the desire for MapBox GL JS to support it).

I'm talking about what looks like a full crash of WebGL (after which no new context can be created/restored).

If I follow the steps in #9516 I get the behavior described, but this does not match my case.

I'm interested to see if it's a series of commands queued to the GPU from MapBox that is causing the crash (although it could just be a Chrome/Android 10 GPU driver issue). I'm just after any pointers to help me debug further...

Many thanks.

[jwoodwardtfx]

I'm been progressing this issue with the Chromium developers (https://bugs.chromium.org/p/chromium/issues/detail?id=1090325) and have been able to get a dump showing the crash in Chrome.

In essence, it's looking like it's either a driver bug on these phones or it's run out of memory (see https://bugs.chromium.org/p/chromium/issues/detail?id=1090325#c18).

I've been asked to instrument MapBox to track the memory usage (https://bugs.chromium.org/p/chromium/issues/detail?id=1090325#c20), as advised in https://developer.mozilla.org/en-US/docs/Web/API/WebGL_API/WebGL_best_practices#General_Topics - Estimate a per-pixel VRAM Budget).

Are there any flags/hooks in MapBox to enable/help me to do this?

[karimnaaji]

Reopening to make sure something isn't leaking from the library.

Are there any flags/hooks in MapBox to enable/help me to do this?

I don't believe we have such flags for vram, there are a lot of different type of resources being allocated, the hooks would have to be put right before any gl creation calls and right after gl deletion calls for textures/buffers/framebuffers and then accounting for main framebuffer. Most are under https://github.com/mapbox/mapbox-gl-js/tree/main/src/gl.

Control+Shift+P + show frames in chrome dev tools also gives some quick information about that if they only need a rough estimate.

[kk12837]

Hi,

I have upgraded my ipad air 2 to ios 14 beta 3.

It shows "CONTEXT_LOST_WEBGL: loseContext: context lost" as well.

And the map is just a blank page.

[AntonERG]

got the same issue, any updates?

[krapnikkk]

more and more Android10 devices got the same problem, even I use other webgl libs, any good news for this?

[luukdv]

Also encountering this from time to time on page load (Chrome 94 on macOS 10.15 Catalina), which results in an empty map. Warnings like these come up:

WebGL: CONTEXT_LOST_WEBGL: loseContext: context lost

WebGL: INVALID_OPERATION: bindBuffer: object does not belong to this context

WebGL: INVALID_OPERATION: bindTexture: object does not belong to this context

GL ERROR: GL_INVALID_OPERATION: glDrawElements: bound to target 0x8893: no buffer

[wawa2016]

got the same issue. Is there a solution to this?

[lstiz]

same problem...

[josuelmm]

Any solution?

[toknpp]

Same problem for me in Chrome on Windows 10 (desktop). For me the trigger seems to be time, i.e. the tab has been running/inactive for too long. At a certain point context gets lost and all Mapbox GL JS stuff just dies. Requires a full browser restart to fix.

[loicparent]

Hello, I have an application based on IONIC that used the library mapbox-gl (with angular). When the map is created, sometime, there is a freezing/glitching bug that appears and I get the same error. So:

WebGL: CONTEXT_LOST_WEBGL: loseContext: context lost

This bug appears mainly with Xiaomi devices (ex: Xiaomi Redmi Note 11). It seems to be related to the method .flyTo(). Once it is called, the error appears.

Is there a way to fix this?

Thanks for your help, Loïc

[urschrei]

I can reliably trigger this issue on iPadOS 16.6.1 and iOS 17 Release Candidate when calling flyTo(). The issue is present in Mapbox GL JS using v3.0.0-beta.2

[stepankuzmin]

Hi @urschrei. Could you please share a minimal demonstration of the issue to help the maintainers and community address the problem? We recommend using https://jsbin.com/. Please include information about the browser version used.

[urschrei]

@stepankuzmin Here you go: https://jsbin.com/cozoyesome/edit?html,output (this is the actual Mapbox "Animate the camera along a path" demo from https://docs.mapbox.com/mapbox-gl-js/example/free-camera-path/, but using the latest beta)

It will first of all fail to run on iOS17 until you "reduce protections". If you do that and reload the page you'll immediately see thousands of WebGL: context lost. messages piling up.

Browser is "Mobile Safari 17.0", using the latest iOS 17 public beta.

[tristan-morris]

Thank for your comment @urschrei, this has helped me narrow down the trigger for the "context lost" issue in my app (Mapbox GL JS in CapacitorJS, only problematic on iOS). As a workaround-ish, I've set flyTo with a duration of 0.

To the broader issue, I've done a bit of digging this afternoon. This might not be entirely on the right track as I couldn't get it to reliably crash in the same "context lost" way on macOS as on iOS - but this behaviour seems very related.

Some of the conditions it seems to require and easiest to replicate:

• Safari on macOS (iOS with WkWebView and Capacitor, but I also presume Safari on iOS is impacted too).
• It seems to only trigger when terrain is being loaded.
• It seems to only trigger when moving around a bit. I assume with XHR requests being aborted, slowed or partial.
• Safari caching errors in console seem to happen pretty quickly, but these don't seem to do anything. I do wonder if greater cache misses do contribute to resources being slowed and then the map would have moved on while zooming, and the requests aborted.
• Safari console errors for 'could not load an image because of An error occurred reading the blob argument to createImageBitmap. After this happens, my map and context seem to be reset.

This sample is somewhat cursed as it just bounces around random places in the US and Australia. It reliably triggers with this fiddle https://jsfiddle.net/ykxaLh6t/ after a minute or two. The crash is much much faster when you have more data being loaded and I'm assuming being unloaded. When it crashes, you'll see the map being reset to USA East.

Edit - 24 Sept 2023 - From instrumentation, the error output (createImageBitmap) is likely due to excessive memory usage as memory can't be allocated (low memory warnings). The sample code does trigger a context lost. The underlying cause seems to be in something related to gljs and WebKit on macOS/iOS.

[urschrei]

No change using beta 3: https://jsbin.com/fiwevoxeza/1/edit?html,output

[urschrei]

FYI: the Context Lost problem is still present using released 3.0.0 on iOS Safari running 17.1.1 (you can swap in the released version at the URL above).

From looking at other reported iOS Safari WebGL issues, it looks like a bug on Apple's side. Even though they've fixed possibly related bugs (https://bugs.webkit.org/show_bug.cgi?id=261313, https://bugs.webkit.org/show_bug.cgi?id=262628) in 17.1, whatever is triggering this is still present in 17.1.1. I suppose the next stop should be Radar reports. Pinging @stepankuzmin to keep him in the loop. If anyone has ideas for bringing this to someone's attention at Apple that would be great.

[tristan-morris]

This is likely related for iOS/Safari - https://github.com/mapbox/mapbox-gl-js/pull/12924 - are you running out of GL memory? That example can definitely cause the context lost.

If you're running your own app, I'd definitely check GL memory usage as it can get high very quickly when loading textures and DEM/terrain (they're fat bitmaps - so 200MB GL mem very quickly).

For our app we made a few changes to reliably support iOS devices:

• Monitor app memory usage, via Safari tooling (memory snapshots)
• Monitor app GL/GPU memory usage, via GL overlay - See https://greggman.github.io/webgl-memory/, example in https://github.com/disasterscience/mapbox-gl-js/blob/pathological-flyto-memory/debug/pathological-flyto.html.
• Switched from geojson loading (to reduce memory) to vector tiles.
• Fixed some of our own memory leaks, particularly around canvas rendering and drawing strokes.

We have this fork/backport for 2.15 - https://github.com/disasterscience/mapbox-gl-js/tree/ds-main with the change applied. Since deploying this, along with the above we've had no OOM/context lost reports from users.

Unrelated but important for iOS / Safari - I accidently deployed Mapbox GL JS v3 beta with the fix to 1% of our 70k iOS user base, the switch to WebGL v2 did not go well. As there seems to be a disproportionate number of users with older versions of iOS and hardware which doesn't support WebGL v2 - iOS 2020 releases.

[urschrei]

@tristan-morris Fantastic work on the investigation and PR , thank you. I'll wire up GL Overlay and see what it tells me. My application doesn't load much GeoJSON, but it does zoom in to high levels quite a lot. Similarly to you, I deployed v3 yesterday morning and immediately started getting Sentry errors.

[urschrei]

@stepankuzmin Testing with 3.1.1 and on iOS 17.3 on older Apple hardware (iPhone XS) and on iPadOS 17.3 on recent iPad, and I'm no longer seeing WebGL "context lost" crashes – they were still present on 3.1.0. I saw the entry about the iOS Safari crash fix in the 3.1.1 release notes but it wasn't obvious what was fixed from the commits.

[stepankuzmin]

@urschrei, I'm glad to hear it helped! We'll keep this issue open to see if it's still reproducible. Any efforts to replicate this issue with releases after v3.1.1 are appreciated.