quoted from https://github.com/mapbox/mapbox-gl-js/issues/4695#issuecomment-305221298 I've been digging deeper into this, and it seems like there is a memory leak in Safari on both mobile and desktop for mapbox-gl-js. All mobile debugging have been done with the basic mapbox example https://www.mapbox.com/mapbox-gl-js/examples/ on an iPad Pro 6,3 (2 GB ram) running iOS 10.3.1. Desktop debugging was done on OS X Safari 10.1.
The error message is "A problem occurred with this webpage so it was reloaded" adding it so people can find this bug if looking for it
<rdar://problem/32503598>
There does look to be a WebGL-related leak here. We'd have to check whether the page is entraining the data.
@smfr, we're unable to isolate the issue to a single aspect of mapbox-gl-js. In addition, the same benchmarking tests causes another popular web-gl based map library, Tangram [https://github.com/tangrams/tangram] to crash on iOS devices as well. See https://github.com/mapbox/mapbox-gl-js/issues/4695#issuecomment-323087798 for details. Let me know if you'd like an isolated test case for this issue.
(In reply to Kristian F from comment #4) > @smfr, we're unable to isolate the issue to a single aspect of mapbox-gl-js. > In addition, the same benchmarking tests causes another popular web-gl based > map library, Tangram [https://github.com/tangrams/tangram] to crash on iOS > devices as well. See > https://github.com/mapbox/mapbox-gl-js/issues/4695#issuecomment-323087798 > for details. > > Let me know if you'd like an isolated test case for this issue. The answer to “would you like an isolated reproducible test case?” is almost always *yes* :) Thanks for your help tracking this down!
@brady: Np, let me know if there is anything else I can do to help resolve this! You'll find a test example here: https://kristfal.github.io/mapbox-memory-test/ To reproduce a OOM crash: 1) Open the web page above on an iPad. They make the best test case due to larger screen size. I'd recommend using an iPad A1475 or another model with 1 GB RAM for consistent and quick results 2) Press Start in the top left corner and the map will start animating through a predefined path and load map tiles as it animates 3) Memory usage will continue to increase until the browser tab eventually crashes and reloads with the 'A problem occurred..' message For iPads with 2GB memory, this happens when the com.apple.Webkit process has consumed between 750 and 850 MB of "Real memory". For iPads with 1GB memory, this happens at around 400 - 500 MB. Drop me a line if you have any questions or if you're unable to reproduce the crash.
Any updates on this? The memory leak and Safari crashing is release blocker for our customer and we would like to know what is the status of this bug? As stated earlier in this thread the crashing happens both in desktop and mobile Safari. We’ve also came across this memory leak when mapbox-gl-js map was removed and re-initialised. Currently we’re working on workarounds by removing and re-initialising the map from time to time but this causes map to blink and it is not a viable solution on a long run.
(In reply to Kristian F from comment #6) > @brady: > > Np, let me know if there is anything else I can do to help resolve this! > > > You'll find a test example here: > https://kristfal.github.io/mapbox-memory-test/ This test doesn't work: [Error] Failed to load resource: the server responded with a status of 401 (Unauthorized) (streets-v9, line 0)
Any update on this? +1
I'm having trouble reproducing this with the map box example site on an iPad Pro 6,3 (as originally reported) running iOS 12. If you are still seeing this, please post your SW/HW configuration. Kristian's test seems to be relying on an expired API key.
Kristian has fixed the test https://github.com/mapbox/mapbox-gl-js/issues/4695#issuecomment-399054123
Hello, any update on that? Thanks
I can confirm this is still a problem on iOS 12 on iPad Mini 3
I'm also seeing a similar issue (documented here: https://github.com/mapbox/mapbox-gl-js/issues/7476) under macOS Mojave (10.14) and desktop Safari (Version 12.0 (14606.1.36.1.9). To more easily reproduce the issue in my case I put together an example here: https://measuredweighed.github.io/mapboxgl-js-mem-usage/index.html. Simply click the "Start" button and you'll see Safari begin to report a significant increase of "Page" memory. This usage seems to climb, with only minor collections, until the "Pause" button is pressed. After waiting for a minute or so you should then see "Page" memory usage begin to drop somewhat. If the animation is allowed to continue, at least on my machine, the "Page" memory usage will simply continue to climb.
Is there any update to this? We are also seeing this issue.
I definitely see the memory use increase on the tests.
Hi Dean, That's great (kinda!) news! Is there anything more you need from anyone here or is that case all you need now? Thanks you!
No, thanks Lee. I'll ask if I need anything.
Hi Dean, we're also having the same issue. For us it really is a show stopper. Could you give a rough estimation for when / if the issue might be fixed. We will need to decide very soon either to keep or drop mapbox all together. Thx!
Hi, Any progress on this issue? I experience this issue on mobile safar & UIWebview (Using cordova). Can't release the app to my customers. Please advise on timeline for a fix or a workaround. Best, Ziv
I've been able to run https://measuredweighed.github.io/mapboxgl-js-mem-usage/index.html for > 5 minutes on iPhones ranging from iOS 10.3 to iOS 12, and have not seen any high memory crashes, suggesting that MapBox-gl may have fixed some issues? DT and Ziv, can you please provide a URL for which you can reproduce this crash?
We are experiencing the same memory leak issue with Mapbox on iOS 10. Not quite sure what to do about it. Can you give any guidance as to when this bug will be fixed?
(In reply to Marc A. Donis from comment #22) > We are experiencing the same memory leak issue with Mapbox on iOS 10. Not > quite sure what to do about it. Do you have a reproducible case you can share?
I've also had https://measuredweighed.github.io/mapboxgl-js-mem-usage/index.html running for 10 minutes on various iPads without having the page restart due to lack of memory. Marc, have you tried iOS 11? DT, Ziv, what happens with that test for you?
I notice the page is pulling the script from mapbox.com. Has mapbox made a change to either fix or work around this issue?
Commented in the github issue - hopefully more people are watching that.
Hello, We also have the same deliberation about using cordova/mapbox in our product, joining the request for estimated timeline... Thank's ahead :) ariel hasidim
Hi Dean, we just realized that we're actually not seeing this issue at all. Our test case included loading and unloading mapbox maps repeatedly in a cordova application. The symptoms we saw were similar to what is being described here. But in our case the solution was as simple as calling map.remove() on destruction of the corresponding dom element. We also noticed that connecting safari dev tools to our cordova webview increased the memory pressure significantly and made the issue even more elusive. Sorry for the confusion. Maybe this insight helps somebody else as well.
I am still able to reproduce this bug when extrusions (i.e. hillshade https://www.mapbox.com/mapbox-gl-js/example/hillshade/) are enabled after just a few minutes of usage, in particular intense zooming and jumping between locations. I was never able to reproduce it via https://measuredweighed.github.io/mapboxgl-js-mem-usage/index.html.
@DT. I can reproduce this on the hillshade example. I note that after a lot of zooming and panning, the JS heap snapshot shows a lot of un-collected ArrayBuffers. The biggest handful are all 4MB, and don't increase in number. However there are thousands of smaller buffers, from approx 200k to 0 that are never garbage collected. They are all marked as root objects, in that they are hanging off the window. Using the heap profiler/snapshot, it looks like the buffers come from: - GridIndex - Placement.retainedQueryData - Map.style - image.data and a few other places. The same thing happens in Google Chrome - which suggests it's probably an issue in MapBox.
Yeah, it seems window.map has references to all the ArrayBuffers that have been used.
The Google tools are a bit more helpful - suggesting window.map.style.sourceCaches is holding a lot of the buffers.
Closing this since it looks like it is a MapBox thing.