Memory leak and crash in 3D mode when using roll

[ssokol]

The new camera roll feature appears to have introduced a memory leak which quickly results in degraded performance and a crashes due to resource exhaustion.

Version and Browser

I've been testing with Version 5.0.0-pre 5 running on Safari on Mac, Chrome on Mac, and also in WkWebView containers within a Swift application on iOS. The speed at which the system becomes unstable and crashes depends on available memory and browser memory limitations.

I've tested with and without terrain and the results appear to be similar or identical. The leak appears to occur when the map is in 3D mode (any pitch outside of 0) when the camera roll value is varied.

Steps to Trigger Behavior

1. Launch a browser and instrument to monitor memory consumption
2. Navigate the browser instance to the demo page
3. Wait, observing the memory consumed by the browser instance

Link to Demonstration

http://demo.falkenavionics.com:5173/rollbug.html?ip=demo.falkenavionics.com

I've also attached an Xcode project that allows you to toggle on the pitch and roll variation independently. If run on actual iOS hardware this quickly and dramatically demonstrates the leak and crash (though it is rather more of a challenge to debug while running in a WkWebView container on a separate device).

Expected Behavior

System runs within the memory limits of the browser and underlying hardware.

Actual Behavior

System quickly runs low on free memory, becomes unstable, and either crashes or is terminated by the supervising system (OS or browser management layer).

WebViewMapDemo.zip

[HarelM]

Can you check if

• WebGL matrix performance fix #5072

Solves this issue? It is reported here:

• Performance degradation in render time in 5.0.0 version #5070

You should be able to use patch-package to verify the fix if you can't wait a few days for a new pre-release.

[ssokol]

I'm sure I can, but I do need a bit of a primer on "patch-package" and how to use it.

[HarelM]

Super easy, check out their docs.
You take the code from the branch, build it, copy it into node modules folder, run patch package, and add it to prepare script.

[ssokol]

Ok, done. Unfortunately, I'm still seeing the memory leak and instability with the patch from 5072 applied.

I believe @ibesora was looking into this and had some ideas.

[ssokol]

@HarelM - need anything else from me on this?

[HarelM]

No, sorry, missed your last comment.
If you can narrow the offending PR it might help speed up the process a bit.

[ibesora]

I haven't tested on an actual device, I still need to do that, but on a browser, simulating roll, pitch and position changes, the behaviour seems the expected. I.e. memory keeps increasing until it gets to the max cache value and then it starts overwritting the values in the cache. Forcing a trigger of the garbage collection I saw some minor leaks but nothing that would increase the memory in a visible way.

Can you try setting maxtilecachesize to a fixed amount and see if that fixes your problem?

[ssokol]

Will do.

FYI - @NathanMOlson is also working on this issue. He did some testing and found that he was able to prevent the leak with the maxTileCacheSize set very low - 8 tiles or something like that.

[ssokol]

No luck. I adjusted the maxTileCacheSize to 8 as suggested by @NathanMOlson. Here's the code, just to make sure I'm doing it correctly:

const map = (window.map = new maplibregl.Map({
    container: 'sv_display',
    center: [-121.816332, 37.329872],
    zoom: 17.5,
    hash: false,
    version: 8,
    maxPitch: 180,
    attributionControl: false,
    centerClampedToGround: false,
    maxTileCacheSize: 8,
    antialias: true,
    style: '/sv/sv.json',
}));

On an actual iPad (M4 Pro) I see the same behavior: memory allocations appear stable with or without Pitch enabled, but as soon as I enable Roll it starts consuming memory rather quickly. Seems to cause a crash after about 4 minutes. The timing may be different on other iOS configurations.

[NathanMOlson]

@ssokol I haven't found a "leak", just excessive memory consumption. Reducing the maxTileCacheSize reduced the memory consumption in my demo.

I haven't been able to find any memory that is not being released. Chrome seems to hang onto a lot more memory than the app is actually using.

Maybe you can try reducing the framerate. After reading a bit about Chrome's garbage collector, it tries to run during idle times. If you reduce the framerate you may get more idle time for the garbage collector to run. I'm not sure if that idea translates to iOS.

[ssokol]

In theory the version of the WebKit engine running on iOS is very similar to the WebKit engine running on an Apple Silicon Mac. Unfortunately, there's really no way to verify this as Apple is... Apple. I've tried running my app on the iOS Simulator which is somewhere in between. Unfortunately, it takes a really long time to suck up all the memory on this 24 GB Mac. I do see an immediate drop in free system memory when I enable roll, and I'm able to watch it slowly drop from there as the app runs.

I don't find a "maxFrameRate" parameter - is there some readily accessible way of setting a maximum frame rate?

[NathanMOlson]

I guess what I mean by "framerate" is the rate at which you call map.jumpTo().

[ssokol]

Ah, that's actually handled by @Samarth1696's motion control plug-in in the current version.

[Samarth1696]

If adjusting the framerate could potentially fix the issue, I can implement a timeStep in the motion control plugin to update at a fixed rate, such as 60 Hz.

[ssokol]

That's worth a try. 60 Hz is great for gaming but this application can get away with a much lower refresh rate. We run the current basic attitude indicator at 20 Hz and nobody complains.

On the "jumping" issue in the plug-in - I think part of what we're seeing is that the state model you maintain gets ahead of the updates from time to time and is then yanked back when an update arrives that is "behind" the model. Slowing down the jumpTo() rate might help reduce those jumps.