Steam client leaking shared memory

[acuifex]

Your system information

• Steam client version: Feb 22 2023 at 20:36:05
• Distribution: arch linux 6.1.12-arch1-1
• Opted into Steam client beta?: Yes
• Have you checked for system updates?: Yes

Please describe your issue in as much detail as possible:

this is mostly a copy of https://steamcommunity.com/groups/SteamClientBeta/discussions/0/3775742652420260102/ i'm making an issue here too because i'm not sure if the forum is used, and because i like feedback.

Steam is leaking memory when launching and exiting. Around 100 MiB per launch. This happens both on stable and beta. i don't know for sure what process is leaking memory, since ipcs and other commands don't really give any useful output. i've ran sudo pacman -Syu and rebooted the system, but the issue persists.

Steps for reproducing this issue:

1. ls -1 /dev/shm | wc -l
2. df -hl -t"tmpfs"
3. take note of the counts
4. launch steam client
5. exit steam client with steam->exit
6. repeat 4 and 5 a few times for noticeable impact
7. repeat 1 and 2, and compare them to 3

[acuifex]

i've just checked, it also happens when launching and exiting team fortress 2. i assume it has something to do with the embedded browser.

[acuifex]

okay it also happens with and without steam overlay enabled, and it happens in tf2 and JBMod both on beta and stable. Some uncleared game cache i assume?

[b3noist]

Arch 6.2.1-arch1-1, non-beta here and seeing similar things happening. Also, RAM usage for Steam just seems to be growing in general over time for little reason.

[holyjoespb]

Each start CSGO increases the size of /dev/shm by ~60MB Stable steam, Ubuntu 22.04 6.1.15-tkg-cfs https://gist.github.com/holyjoespb/71baf2b68849635ff6866014569b92a8

[dakrk]

I have my computer on for such an amount of time that earlier today I noticed I had over 6GB used by files in /dev/shm. This wasn't immediately noticeable either as it's not in an actual process by a user and as such isn't visible in a usual system monitor program. I imagine this could cause quite a bit of pain for other users that won't suspect to check the usage of a tmpfs and they just reluctantly resort to rebooting.

This doesn't seem to be a new issue either, with #3378 dating all the way back to 2014 (almost a decade ago!)

[h1z1]

It's not quite a traditional memory leak, more like a temporary file on a ramdisk being used as a pipe. You can lsof /dev/shm/fileglob to confirm they are infact left over in which case you can remove them without rebooting. It's a bit more complicated if they are still in use. If it's clearly something related to a game or steam and you have neither running then it's a bigger bug.

[tomjaguarpaw]

Wow, I've just hit this. It's appalling behaviour. I was rapidly running out of memory and confused about why. But I'm glad to know I can safely delete those files.

[lemmi]

Same issue on voidlinux.

[143mailliw]

Same issue on Arch. Still a problem.

[cwrau]

Same issue here, I just cleaned ~10G of files in /dev/shm which were created by steam, which still existed after I stopped Steam

[grinapo]

Intersting. Indeed, Steam Electron UI secretes a huge amount of very large files in /dev/shm/, which is a horrible behaviour in itself, since /dev/shm/ is not for "normal" temporary file storage for various reasons already readable throughout the net.

Lots of u1111-Shm_b8fe91eb files (uid 1111), 26 MB in size for me, here and now. Steam client was not even crashing, it was Quit'ed nicely, the files still left behind. (Well, originally anyway.)

Let me tell you what it does, though. When /dev/shm/ gets full (and eventually it does), and one do not notice, everything based on electron will segfault. No error message, no console message, no nothing: crash. It may crash in various libs, but for me most often it was the infamous sandbox lib aka. libcef.so, which already causes some grief for the UI developers, judging by some console messages.

You may say, hey, who uses Electron? I don't even know what it is! - Oh well, you'll see. A lot. Start with everything chrome based, then everything web based having a local desktop client. I can't even try listing the damn beasts.

So, obviously, Steam client instantly crash, with no messages apart from the crashdump, which contains no pointers to the real cause whatsoever.

Debugging that problem is close to impossible. If you don't notice /dev/shm is full you can pull your body hair out. I was lucky to start a different program with nicely told me that cannot write /dev/shm, no space left on device. Deleting the extreme amount of crap immediately fixed the systemwide issue (after spending half a day on it).

So yeah, this is no good, and it is possibly related to electron, but I cannot possess enough info to specify.

[tomjaguarpaw]

I'm glad people keep posting to this thread because it's a good reminder for me to clear out what Steam left in /dev/shm. I've just regained 1.3GB of memory!

[grinapo]

3378 is from 2014. Looks promising.

[RodoMa92]

I'm also affected by this. Open from 2014, this doesn't bode well :S

[tomjaguarpaw]

Just regained 353M of memory.

[sobrus]

Not only starting steam client, but starting a game also creates additional files in shm. I've just reclaimed 5.5GiB of memory locked by playing Back4Blood a couple of times. System uptime was around 30h only (including time in suspended state).

[pftbest]

I have the same issue on Steam Deck, each time I switch to the Desktop mode my /dev/shm gets bigger, one time I saw 2GB in /dev/shm, and the swap partition by default is only 1GB in size, so I was wasting at least 1GB of RAM for nothing.

[tomjaguarpaw]

Just regained 775M of memory.

[grappas]

In my case memory leak appears after waking up from sleep while steam is hidden in tray. It goes away after opening client window

[tomjaguarpaw]

Just regained 100M.

[kolAflash]

@kisak-valve
My Debian-12 system is also affected.
And Void-Linux seems to be affected too -> https://github.com/ValveSoftware/steam-for-linux/issues/9233#issuecomment-1467414426

Has someone found a nice workaround? A script for launching Steam and cleaning up /dev/shm/ afterwards would be ideal. But it should not delete files which have been created by other programs than Steam.

 

---

 

P.S.

 

"little" safe workaround

Most of the files seem to be mainly empty (zeros). So you can safely free space by making them sparse files. Just run this command after closing Steam or periodically while running Steam.

/usr/bin/find /dev/shm/ -maxdepth 1 -type f -readable -writable \
    -regextype egrep -regex "/dev/shm/u"${UID}"-Shm_[0-9a-f]{8}" \
    -exec /usr/bin/fallocate --dig-holes '{}' \;

Programs (including Steam) using sparse files won't see a difference. Sparse files simply don't allocate real memory for the parts of the file which only contain zeros.

 

Additionally I found out, that Steam actually deletes some /dev/shm/u*-Shm_* files when it's being closed. But some files are not deleted.

 

 

"big" unsafe workaround

USE AT OWN RISK!!!
This permanently deletes data!
But in most cases this data shouldn't be in use any more.

Create text file /home/YOUR_USER/scripts/steam-clean-memleak.bash

#!/bin/bash

# https://github.com/ValveSoftware/steam-for-linux/issues/9233
# Example: /dev/shm/u1000-Shm_0a1b2c3d

for i in /dev/shm/u1000-Shm_*; do
    # Ignore find error if no u1000-Shm_* exists.
    file="$(find "${i}" -type f -mmin +"$((2*24*60))" 2>/dev/null)"
    if [ -n "${file}" ]; then
        fallocate --dig-holes "${file}"
        used_kb="$(du "${file}" | grep -Eo '^[0-9]+')"
        if [ "${used_kb}" -gt 4 ]; then
            rm -Iv "${file}"
        fi
    fi
done

Run: chmod +x "${HOME}"/Scripts/Linux-Scripts/steam-clean-memleak.bash

 

Run: systemctl --user edit --force --full steam-clean-memleak.service
Insert:

[Unit]
Description=See https://github.com/ValveSoftware/steam-for-linux/issues/9233

[Service]
Type=oneshot
# %h is /home/YOUR_USER
ExecStartPre=-%h/scripts/steam-clean-memleak.bash
ExecStart=%h/scripts/steam-clean-memleak.bash

[Install]
WantedBy=default.target

 

Run: systemctl --user edit --force --full steam-clean-memleak.timer
Insert:

[Unit]
Description=See https://github.com/ValveSoftware/steam-for-linux/issues/9233

[Timer]
OnCalendar=daily
RandomizedDelaySec=5m
Persistent=true

[Install]
WantedBy=timers.target

 

Run:

systemctl --user enable --now steam-clean-memleak.timer
systemctl --user --no-pager list-timers --all

[mAd-DaWg]

I confirm this is also happening for me on Ubuntu 23.10 (kernel 6.5 and kernel 6.7). Steam seems to make more that dont close everytime games are opened

[Anvil]

This is not distro-specific. Happens on fedora too. This is a long standing issue. And the more you start/stop the steam client, the more memory it leaks. Took me a while to realise.

[Anvil]

A very basic solution, to me, would be to include an 'exit' trap, either in the bin_steam.sh script or in the steam.sh script. (probably the latter)

clean_shm() {
    find /dev/shm -name "u$(id -u)"\* -type f -exec rm -vf {} \;
}

# Or, alternatively, a non-find version
clean_shm() (
    shopt -u failglob
    shopt -s nullglob
    rm -vf "/dev/shm/u$(id -u)"*
)

trap clean_shm EXIT

[cyro666]

Just want to say this is a problem on Gentoo as well.

I have been perplexed by a memory leak for a few weeks now. Due to my workflow, I have not been restarting this particular machine for a few days, because it also acts as a firewall/router (there's a VM running on it that has a few NICs forwarded to it). I play games on this machines. The leak wasn't very obvious, due to the machine having 64GB of RAM, but every night, I close all the processes and leave only a console/tty login running (+ the VMs). By chance, I checked the memory usage on this machine through SSH. It was 10GB, which made no sense, since almost all processes were killed.

Lo and behold, after finding 6GB of random crap in /dev/shm, I realized it was Steam not cleaning up. And this lead me to this thread. There's hundreds of u{uid}-Shm_{random_hash} files in /dev/shm.

I'm surprised more people haven't reported this, seems like it's been an issue for a long time. But I guess people tend to restart their machines more often.

[cwrau]

I've added a postExec in my systemd unit for steam; https://github.com/cwrau/linux-config/commit/28ab4b53d5f9e6d40c306c80f3f344a0fbee0675

Just in case someone would like to make their life easier as well 👍

[sphaerophoria]

TL;DR Disable the in game overlay if possible

I was seeing memory usage of /dev/shm climb a lot with a lot of 26M files getting leaked. Note that if I monitor /dev/shm, I see maybe 50 new files while the game is open, but after the game is closed all except 4 are cleaned up

If I look at one of the new files after opening and closing apex, I do see that it is in use by a steamwebhelper process. Note that all files are still opened by some process, but the number of files and memory usage is definitely growing. 4 new 26M files per launch

└> fuser -v u1000-Shm_ea041209
                     USER        PID ACCESS COMMAND
/dev/shm/u1000-Shm_ea041209:
                     mick      4008640 F...m steamwebhelper

This is a clue, what happens if we just disable the in game overlay?

Okay now way more than 4 files are leaked, from 1 run of apex I go from 22 -> 58 files in /dev/shm. HOWEVER, we can now inspect them to see if they're open

#!/usr/bin/env bash

for f in /dev/shm/u1000-*; do
        if fuser "$f" >/dev/null 2>/dev/null; then
                continue
        fi
        rm "$f"
done;

Remember that with the overlay on, 4 files were leaked and all were in use, if I run the above script after running apex with the overlay disabled there are ZERO new persistent files. This is somewhat of a downgrade, and somewhat of an upgrade. On the one hand, this results in more garbage leaked files, however they are now identifiable and we can clean them up ourselves manually. If you are willing to wait until the next run of a game, steam seems to clean up these unopened files by itself when launching, so I suspect that the underlying bug here is related to the fact that steamwebhelper doesn't release the new files when a game is closed

While testing I had a bunch of confusing results, I believe that if I delete all steam related files in /dev/shm, the overlay stops working, and we essentially end up in state 2 while thinking we are in state 1.

Hope this is helpful to others stumbling upon this in the future

[sphaerophoria]

An addendum to my previous comment, there are still leaked files by steam itself. If you close and open steam often you may still need to go do some manual cleanup. Coincidentally (just kidding, probably not), steam tends to clean up all except for the 4 problematic 26M files on shutdown