Looking Glass Client Causes Unreclaimed Host Memory Leak

Hi everyone,
I’m experiencing a persistent host memory leak when using the Looking Glass client, which only resolves after manually dropping caches. I’m hoping someone can help me diagnose the cause.

Here my system and environment

  • Host OS: Nixos unstable
  • Host Kernel: Linux 6.16.1
  • Guest OS: Windows 11
  • CPU: AMD Ryzen 7 9700X
  • RAM: 32GB
  • GPU: Nvidia 5060 Ti 16GB with driver version
    • 580.76.05 on NixOS
    • 581.08 on the Windows 11 VM
  • Looking Glass B7 (both on the host and guest)

The Looking Glass client runs perfectly, but it causes the host’s available memory to steadily decrease without being freed, eventually leading to out-of-memory conditions.

For example, If I watch a full screen youtube video, in about 10 minutes the free memory on the host decreases from ~8GB to ~3GB (similar issue in a gaming session).
If instead I simply keep the VM idle in the desktop (no video/gaming), the memory consumption on the host is much slower.

In order to restore the memory on the host I need to

  • Close the looking glass client
  • Run sync && sudo sysctl vm.drop_caches=3

After the command below I restore my free memory to 8GB (without shutdown the VM).

If instead I use the VM without opening the looking glass client, the free memory on the host remains constant to ~8GB in every scenario (gaming, youtube, …).

Finally, I’ve already tried configuring Looking Glass using IVSHMEM with the KVMFR module and with the stardard shared memory. In both cases I have the same issue

Thank you!

1 Like

same problem

This is very likely a software bug related to looking glass.

I’d file a bug report here: GitHub · Where software is built

1 Like

And it would be shot down because this forum is where issues are discussed before an assement is made on if it’s a bug or not.

This issue is alreday known, it’s caused by the latest release of Mesa, downgrading it resolves the issue. This has already been reported upstream and is not a Looking Glass bug.

4 Likes

Do you have a link to bug report on mesa bugtracker by any chance?

Looks like this bug wasn’t considered major and wasn’t fixed before 25.2 release, hence my arch become unusable for work thanks to that.

2 Likes

I had the same issue. Just moving the mouse around would eat gigabytes. I switched my renderer from EGL to OpenGL and the problem went away.

looking-glass-client app:renderer=OpenGL

or

looking-glass-client -g OpenGL

2 Likes

Unfortunately I personally have not managed to replicate the issue due to hardware issues with my development system. I have new parts on order and should be able to dig into this soon if someone else doesn’t before me.

As for the link, sorry no, at this time all I know is that a member in the LG discord has reported it upstream.

1 Like

Thanks @Legendary-Ghoul that’s working great for me as well!

Has the default value, EGL, some advantages over OpenGL? So far I haven’t notice any difference

I also have this issue.
The openGL fix does fix the memory leak for me which is great.
It seems to cope with HDR worse so is VERY dark but I switch to use an actual display mostly anyway.

Yes, OpenGL is there only for compatibillity with older cards and a workaround when issues like this crop up. It is missing a lot of features including DMABUF that the older API simply does not support.

Also has no ability to perform any post-processing such as HDR tone mapping as @tomahhunt noticed.

2 Likes

It’s weird, I’m seeming to only have this issue using the Looking Glass OBS Plugin. RAM usage goes through the roof with it on, although if I switch it to pipewire window capture it’s fine. Usage outside of OBS is also fine.

Using OpenGL fixes this issue still but can’t hit my 144hz refresh rate for some reason, so it’s a no go for me.

The workaround for now is to downgrade mesa.

Both the LG client and the LG OBS plugin make use of EGL dma buffer transfers, which is likely where the bug is in mesa.

1 Like

Do you know what version? I tried versions from 1_25.1.7-1 to 1_25.1.3-1 but It’s still the same issue.

I’ve downgraded nixos from unstable to 25.05 which uses mesa 25.0.1. Using this version I don’t have the memory leak issue with EGL

The latest reported working version is 25.1.7

3 Likes

Hi, I just registered (before finding this thread) to post about this issue because I was going mad trying to figure out if I had configured something wrong.

After trying multiple host and client versions over the last few days and several different VM settings, I had already resorted to keeping watch free -m open when using the VM, being ready to close Looking Glass and fire off sync && echo 3 > /proc/sys/vm/drop_caches.

Good to know it’s not just me, and many thanks for the workaround using OpenGL!
For my use case this is perfectly fine, as I can’t really tell a huge difference in usage – maybe just a tiny bit of lag now and then. That’s probably just down to my setup, since I only use it for Windows desktop applications with GPU acceleration, not gaming.

I have managed to replicate and bisected the issue, the following commit is the cause:

5 Likes

A bit offtopit, but I just can’t not point it out:

this allows eliminating surface refcounting and objects
which, relatively speaking, don’t serve much purpose

When joke write itself.

And thank you for your work.

2 Likes