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 #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 #9516. Are you sure #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?

[kiprou]

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 - #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.

[shuabrannigan]

FWIW i was suddenly running into this issue when i updated the filter on my layer dynamically, it seemed to be pretty consistent erroring couldn't really work out what was causing it, couldn't see how the filter update would matter. I then by chance got the map to render again but it was borked! the base map styles were all messed up.

It made me think maybe its the style? so i switched the style from 'mapbox://styles/mapbox/standard' to 'mapbox://styles/mapbox/streets-v12' haven't encountered the issue since. weird?

EDIT:
this was mapbox-gl running on macos chrome browser, so not entirely a android 10 problem but same context lost error

[carstonhernke]

@shuabrannigan I'm seeing some similar behavior, also using the new Mapbox Standard style with Chrome on MacOS. The issues are intermittent and hard to reproduce exactly, but they seem to occur more frequently with multiple map windows open and while zooming in/out.

Another interesting side-effect is that if I have a separate tab with Google Maps open, the rendering is messed up after the primary WebGL tab crashes. This seems to suggest some type of browser-level WebGL bug (although I'm by no means a browser GPU expert).

I started noticing this issue after Chrome 128 was released on Aug 14 2024 - I wonder if there's a connection. Here is a related thread: https://support.google.com/chrome/thread/293014995/what-are-the-updates-or-modifications-made-to-webgl-in-the-128th-version-of-chrome?hl=en.

There is also an issue affecting users of Azure Maps in PowerBI, and I wonder if the root cause is the same: https://community.fabric.microsoft.com/t5/Service/Azure-Map-Visuals-Broken/m-p/4155226.

[shuabrannigan]

@carstonhernke I raised another issue #13273 for the problem. I did also get the browser wide GL dying which required restarting the browser to fix.

I could not reproduce my issue with the v3.7.0-beta.1 as instructed.

try that version if you can and see if it resolves the issue, what really stumped me was reverting to a older map style fixed the issue originally,

[lucaswoj]

I encountered an issue while refactoring my map style from Mapbox Streets to Mapbox Standard. After panning around for a few seconds, the map would crash with the error: CONTEXT_LOST_WEBGL: loseContext: context lost.

I believe the root cause was WebGL resource exhaustion. This occurred because my map was attempting to load several large spritesheets simultaneously.

The problem stemmed from my refactoring approach. By using imports, I inadvertently loaded all sprites from Mapbox Streets, Mapbox Standard, and my custom sprites at once. This caused WebGL resource exhaustion, context loss, and a crash.

The solution was straightforward: I removed the Mapbox Streets sprites. Afterwards the crashes ceased completely.

I'm sharing this experience in hopes that it might help other users who encounter similar crashes. It could also be valuable information for the GL JS maintainers.

[david-buck]

I am getting an increasing number of reports for users that maps aren't loading when they previously did. These users tend to be on older Android devices (v10/11) with 1GB of RAM.

The only changes I have made in the interim are updating map styles (no new layers, minimal new assets, removing lots of old assets).

Is there anything that could be happening in the tile data loaded from Mapbox servers that could be causing an uptick in this error?

In my testing, the error can be remedied by force refreshing the view several (between 5 and 10 times) until the map initialises.

I have been able to replicate this on my own maps, as well as others, including the Mapbox examples, and including maps on mapbox-gl v2.

[shuabrannigan]

hey @david-buck
have you tried mapbox-gl v3.7.0? that fixed the issues i was having with context lost;

[david-buck]

Hi @shuabrannigan yes, I have. Most reports started coming in after I pushed an update which included a mapbox-gl bump to 3.7.0.

My testing since makes it seem like this is a broader issue. People who could previously use Mapbox maps on their devices couldn't from roughly the end of last week. I can easily replicate their issues on a simulator.

[stepankuzmin]

Hey @david-buck,

Could you please share a test case that we could use for reproduction?

[david-buck]

The common factor in the reports I've had is an Android device with 1gb of ram. I can emulate this in Android Studio and consistently get the same issue, regardless of Mapbox version. The people reporting are saying that maps had previously worked as expected.

[stepankuzmin]

@david-buck, which combination of GL JS version and style is causing the crash for you? Are you using the latest GL JS with the Standard Style or one of our examples from the docs?

[stepankuzmin]

Hey everyone,

We’ve implemented a fix for PowerVR devices (e.g., Moto G22, Redmi A3x), which will be included in GL JS v3.9.0-beta.1.

[david-buck]

3.9.0-beta.1 fixes this issue for me on low end devices - thanks!