High Safari memory usage/possible memory leak

[measuredweighed]

I'm seeing what looks to be a memory leak in Mapbox GL JS on desktop Safari (Version 12.0 (14606.1.36.1.9)) running on macOS Mojave (Version 10.14). I'm able to reproduce the issue on a custom map implementation as well as the simple map example (which I believe is running version 0.50.0).

By simply panning and zooming around on the map for a few minutes I see "Page" memory usage climb consistently in Web Inspector's Memory pane. I've seen Maximum/Current values reach > 2GB (and continue to climb), causing Safari to warn:

This webpage is using significant memory. Closing it may improve the responsiveness of your Mac.

Memory snapshots don't seem to reflect the values reported by the Minimum/Maximum page memory value. But I've included screenshots of them below.

From my testing, it appears that Google Chrome is unaffected. Unfortunately this is all the information I have at the moment. Please let me know if there's anything else that I can include.

[ChrisLoer]

Here's what I see after several minutes of aggressive panning and zooming on the "simple map" example (including loading lots of CJK glyphs), using Safari 12.0 (14606.1.36.1.9) on macOS 10.14 (18A391):

Although I was able to get memory usage to climb to almost a gigabyte, it doesn't look like I was able to reproduce the same pattern you saw, primarily because "Page" would periodically appear to clean up large chunks (and you can see at the time I took the screenshot I was back down to ~500MB, which seemed to be about the steady state).

Page – All other memory. This includes engine memory related to the DOM, styles, rendering data, memory caches, system allocations, etc.

I'm not sure what we'd be contributing here, maybe data we've uploaded to the GPU? My first (lazy?) guess would be that it's mainly resources not directly controlled by gl-js.

Do you see this behavior on any other web pages?

[measuredweighed]

Hi @ChrisLoer, thanks for taking a look at this for me. I don't see this behaviour on other websites. Since my initial ticket I've done a bit of digging to try to narrow this down, and I believe I've come up with a reproducible case. It does appear to be some sort of Mapbox-related memory leak.

Here's what I've found:

• While memory usage on the Mapbox example pages is still fairly high, it actually doesn't exhibit the behaviour I wrote about in my initial report. The Safari Memory timeline doesn't appear to reset itself upon refresh (or perhaps it simply reports memory allocations from previous runs), so that was a bit of a red herring.
• The issue seems to actually be style dependent. I'm using a style from http://maptiler.com and that's where I'm seeing this issue.

To help debug the issue I've put together a reproducible case. If you run my example in Safari you should see memory usage hit ~1GB within about 30 seconds. This value continues to climb with only small garbage collection drops.

I've confirmed this behaviour on another machine, to be sure it wasn't something unique to my workstation.

[ChrisLoer]

Interesting -- thanks for putting together that example. I don't see ~1GB in 30 seconds, but I left it running, went for coffee, and came back and it had slowly climbed up to ~1.2GB. When I stopped the animation, the memory started coming back down. So I think maybe I'm seeing the same behavior as you? It sounds a little different.

Two things grabbed my attention in the console:

• Warnings of the form Geometry exceeds allowed extent, reduce your vector tile buffer size. This is a hint that the tiles from maptiler don't completely conform to the vector tile spec (or in some cases they may fall into the grey area between what's defined in the spec and what we "expect" based on vector tiles provided by Mapbox). This could also easily be a red herring.
• Tons of 429s. When you run this example, are you also rate limited? It shouldn't be a problem, but it is making us go down a different tile loading pathway, so it might be related.

[ChrisLoer]

Here's what happened when I paused the animation (had to use the debugger which required stopping the timeline recording, thus the gap). You can see the "Page" and "Layers" usage both plummeted (although "Layers" was never too large to begin with), whereas JS memory stayed pretty stable (which we'd expect). I have no idea what those brief spikes in "Page" memory are after that.

[measuredweighed]

I can confirm that I do see a fairly large drop in "Page" and "Layers" memory use when the animation is stopped. To make this easier to test I've updated my example so that the Start button can be toggled to pause the animation once in flight.

Here's what my Safari looked like after leaving the animation to play for 60 seconds, hitting the Pause button, and then leaving it for a subsequent 60 seconds.

Warnings of the form Geometry exceeds allowed extent, reduce your vector tile buffer size. This is a hint that the tiles from maptiler don't completely conform to the vector tile spec (or in some cases they may fall into the grey area between what's defined in the spec and what we "expect" based on vector tiles provided by Mapbox). This could also easily be a red herring.

I'm not sure how frequently you're seeing this warning, but I've only come across it once in the console.

Tons of 429s. When you run this example, are you also rate limited? It shouldn't be a problem, but it is making us go down a different tile loading pathway, so it might be related.

I can confirm that I also see a large amount of rate limited tile requests.

[KleggerKoder]

Perhaps related to this: #4695

[ChrisLoer]

Actually this looks like a duplicate to me -- I saw #4695 go by a while back but I had never looked closely at it so I forgot about it. @measuredweighed, do you see anything significantly different in your repro case from the reports there?

[measuredweighed]

I'd seen #4695 and even tried to disable extrusion on our custom style to see if it had any impact. However upon digging into the ticket in a bit more detail it looks like this may very well be the same issue we're seeing. I'll update the WebKit ticket with the test I've put together and possibly also raise a new issue with them.

[ChrisLoer]

Closing as a duplicate of #4695 -- not absolutely sure it's the same issue, but at the least it seems like it makes sense to investigate both reproduction cases together.