Periodic Random Crashes in Linux Mint

[redyoshi49q]

Your system information

• Steam client version (build number or date): built on May 14, 2022 at 00:03:20
• Distribution (e.g. Ubuntu): Linux Mint 20.3 Cinnamon
• Opted into Steam client beta?: [Yes]
• Have you checked for system updates?: [Yes]

Please describe your issue in as much detail as possible:

On my system, for a long time (at least a year, if not since the initial install of Steam), I have experienced periodic and seemingly random crashes of the Steam client. Crashes can occur as quickly as a handful of hours, but Steam can sometimes run overnight without crashing; it's highly unusual, if not unprecedented, for Steam to achieve an uptime greater than 24 hours. These crashes have occurred with no apparent relation to system uptime, available CPU/RAM/disk, specific kernel version, specific game running (or lack of a running game), presence of other running software, time of day, network availability, or any other obvious factors that might potentially correlate with a crash.

This gist is from a recent Proton issue report, and should still be closely representative of what my system is currently like (and fully representative of a state in which this issue occurs). I'm aware that what I've provided so far is not likely to be sufficient to diagnose this issue (or to determine whether or not it's a duplicate of one of the already reported issues describing seemingly random crashes), but I'm willing to provide terminal output, additional logs, or other diagnostic info upon direction regarding what would be helpful in narrowing this issue down.

Steps for reproducing this issue:

(Unknown; see above.)

[kisak-valve]

Possible duplicate of #6318.

[redyoshi49q]

In light of what those in other related threads have done, I'm uploading a tarball of the /tmp/dumps files that, according to grep, contain "steam". If the crash dumps look similar enough to those of the main issue, feel free to close this one.

steam_crash_dumps.tar.gz

[kisak-valve]

For reference, most of the crash_*.dmp files are SIGSEGV in libnm.so.0.1.0.

It might be interesting to check if 32 bit libnm0 is installed with something like apt policy libnm0 libnm0:i386 and if installing it with something like sudo apt install libnm0:i386 has any effect on your issue.

If it wasn't installed system wide, and installing the distro-variant does have an effect, that means we'll want a dev to ponder if your issue is with the Steam runtime variant of this library.

[redyoshi49q]

394/64287 MB RAM 12.8% 16.1% 16.5% Wed, May 18, 2022 1:08:40 pm [0 jobs]
[ethan@firetail: +2] /tmp/dumps $ apt policy libnm0 libnm0:i386
libnm0:
  Installed: 1.22.10-1ubuntu2.3
  Candidate: 1.22.10-1ubuntu2.3
  Version table:
 *** 1.22.10-1ubuntu2.3 500
        500 http://archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages
        100 /var/lib/dpkg/status
     1.22.10-1ubuntu1 500
        500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages
libnm0:i386:
  Installed: (none)
  Candidate: 1.22.10-1ubuntu2.3
  Version table:
     1.22.10-1ubuntu2.3 500
        500 http://archive.ubuntu.com/ubuntu focal-updates/main i386 Packages
     1.22.10-1ubuntu1 500
        500 http://archive.ubuntu.com/ubuntu focal/main i386 Packages

libnm0:i386 was /not/ previously installed. I have just now installed it (version 1.22.10-1ubuntu2.3), and will report back if I get another random crash (or don't get one for a few days).

[redyoshi49q]

I've been running the Steam client since my last post (four days ago) without experiencing any crashes whatsoever; it does indeed appear that installing libnm0:i386 on my system turned out to be the fix. Is there any other diagnostic info that might be useful for me to provide from my end for the purpose of resolving the issue for other Steam client users?

[smcv]

For reference, most of the crash_*.dmp files are SIGSEGV in libnm.so.0.1.0.

If a Steam developer with access to the crash dump system can clarify what the backtrace for this segfault looks like, then it might be possible to backport a fix into the Steam Runtime's libnm0.

[TTimo]

actual crash may be in libglib, but none of the steam minidumps in OP's archive have usable backtrace, they are all just corrupted above the crashed frame (or our tool failed to capture).

code address 0xee396a3b matched to module: libglib-2.0.so.0.6400.6
{'breakpad_id': 'c2ecc29f0e7d7c28c7b8947ccc6069180',
 'build_id_prefix': '9fc2ecc27d0e287cc7b8947ccc606918',
 'load_address': '0xee32b000'}
next module up: libgio-2.0.so.0.6400.6
{'breakpad_id': '0791756a064307aa154f17d49088ecf90',
 'build_id_prefix': '6a7591074306aa07154f17d49088ecf9',
 'load_address': '0xee46d000'}

looks like that libglib is from the host also, we use libglib-2.0.so.0.3200.4 in LD_* scout

[redyoshi49q]

looks like that libglib is from the host also, we use libglib-2.0.so.0.3200.4 in LD_* scout

In case it's helpful, my version of libglib2.0-0 and its related packages is 2.64.6-1~ubuntu20.04.4 . If it's possible to run Steam with arguments to tell it to use its internal version of libglib2.0 and/or libmn0 (x64 and/or i386 packages) instead of the system version for the sake of trying to reproduce the crash, I'm willing to give that a shot; just let me know what arguments/shell variables are needed.

[smcv]

If any of the GLib-dependent libraries Steam is using (libnm, GTK, that sort of thing) are provided by the system, then we have to use the system version of GLib as well: the included version will be too old for the other system libraries, and if we tried to force it, they'd just crash. The only time we can use the included version if there is no :i386 system version of a library at all (or if it's strictly older, but that can only happen for libraries that have been backported in the Steam Runtime, and GLib isn't one of those).

So, the only safe way to use Steam's included version of libglib2.0-0 is to remove the libglib2.0-0:i386 package.

Similarly, the only safe way to use Steam's included version of libnm0 is to remove the libnm0:i386 package.

[TTimo]

@smcv - I think that means if Steam sees a host libglib2.0-0, it may need to require a host libnm0 as well, or abort? (libnm0 and a few other libraries possibly).

I don't know if we have any mechanisms to easily enforce this in a data driven way.

It may also not be worth it if the official steam_latest.deb package installs the right sets to begin with - this situation would happen due to inadequate distro repackaging, or if the user later removed those packages.

[smcv]

I think that means if Steam sees a host libglib2.0-0, it may need to require a host libnm0 as well, or abort?

If that's the case, then there has been a backwards-compat break somewhere, which generally shouldn't happen.

Do we have evidence that it's the combination of old bundled libnm0:i386 with newer host libglib2.0-0:i386 that is triggering this, as opposed to the combination of old bundled libnm0:i386 with new network-manager service?

[smcv]

It may also not be worth it if the official steam_latest.deb package installs the right sets to begin with

At the moment I don't think that pulls in libnm0:i386; but it easily could, and given the number of crashes we've had involving that library, perhaps it should.

[TTimo]

Do we have evidence that it's the combination of old bundled libnm0:i386 with newer host libglib2.0-0:i386 that is triggering this, as opposed to the combination of old bundled libnm0:i386 with new network-manager service?

My Manjaro uses host provided /usr/lib32/libglib-2.0.so.0.7200.1 and scout's steam-runtime/usr/lib/i386-linux-gnu/libnm.so.0.1.0 and I don't think I'm seeing this. So just this is at least not sufficient to cause a problem.

My baseline ubuntu 22 install uses both libglib and libnm from scout. So we don't install those via steam_latest.deb, it's possible a lot of systems are running this way (and presumably they have no problem).

[smcv]

Another possible root cause is if scout's libnm has a bug that makes it crash on some specific piece of configuration or state in network-manager. If your network doesn't have that state but the issue reporter's does, then you'll never see the crash but the issue reporter will - I think we had this happen in the past for a specific WPA mode or something like that?

[TTimo]

Speaking of which - @redyoshi49q do you use iwd (iNet wireless daemon) on your system by any chance?

[redyoshi49q]

Speaking of which - @redyoshi49q do you use iwd (iNet wireless daemon) on your system by any chance?

No, I do not have the iwd package installed. I use the OS's default program for managing wifi networks (network-manager, currently version 1.22.10-1ubuntu2.3).

[Firminator]

FWIW I never experienced a Steam Client crash on my Mint box ever. Do you have a secondary device where you can reproduce this?

[redyoshi49q]

FWIW I never experienced a Steam Client crash on my Mint box ever. Do you have a secondary device where you can reproduce this?

I don't have additional suitable hardware available, but my laptop's more than suitable enough to run an instance of Linux Mint in Virtualbox. I've made a new, clean install of Linux Mint in a VM, and I've installed packages corresponding to my current system's packages (not including libnm0:i386), or at least as close as I've been able to do (apparently, package mesa-opencl-icd:amd64 's requirement of libclc-12 conflicts with libclc-amdgcn, libclc-dev, and libclc-r600, so I couldn't install those three packages specifically alongside mesa-opencl-icd:amd64), for the sake of trying to reproduce the bug.

For privacy/security reasons, I installed fresh packages onto a clean OS (rather than try to migrate my current system's filesystem onto a VM) so that I could safely share the reproducing system if I was successful, and as a side effect of that, if the bug stems from something that isn't reflected in the list of installed packages, I won't be able to reproduce it this way. Similarly, if the bug occurs due to an interaction with hardware (such as an interplay with drivers for AMD hardware), this method will not produce the bug, and I've abstained from installing any Steam games within the VM's copy of Steam (I assume that sharing the VM after having done so would likely violate game licensing agreements).

[Andre8900]

Same issue. Steam closes itself and running games without a warning frequently. Any fix available yet?

[redyoshi49q]

You might want to read the rest of this issue report if you haven't already; on my end, installing the libnm0:i386 package prevented the issue entirely (see https://github.com/ValveSoftware/steam-for-linux/issues/8595#issuecomment-1130364429 for the command that checks for the missing package and for the command that installs it if it's missing).

If it's not that, the cause of your bug might be something different even if the manifestation is entirely the same (there are a few other Github issues about random Steam client crashes that occur in various environments). It would be helpful to post a compressed archive of the files in your /tmp/dumps directory that contain "steam" (as I did earlier in this issue's thread); I'm not sure whether the project maintainers would prefer that archive to be posted to this issue or to a new issue, though.

...And on a different note, I had meant to post my own update to this issue thread. I have not experienced this issue at all since the fix of installing libnm0:i386. I did try to reproduce the issue on a fresh Virtualbox VM containing the same packages that my system had before the libnm0:i386 installation (or as close to that as I could get; I remember there being some issue with a package conflict while doing so), but I wasn't able to reproduce the issue (I let Steam run in the VM for roughly a week, which admittedly wasn't very long, but it should have been long enough to reproduce the issue in theory).

[Andre8900]

Hi @redyoshi49q the package was not installed, but crashes are still happening even with the package installed :( Thank you for your help and the hint that steam is capturing crash dumps in /tmp/dumps I have opened a new bug report #8762

[Nocty1501]

I've been having the same issue, running Linux Mint 21.1 Vera, Cinnamon (though I replaced the DE with KDE Plasma).

Steam loads, updates, and runs fine for a few minutes (10-20) before quietly crashing, generating a crash file in /tmp/dumps. Whatever game was running at the time freezes/lags for a few seconds before also crashing.

No Steam client beta, installing/uninstalling libnm0:i386 didn't make a difference. I'm using an NVIDIA GTX 970 with nvidia-driver-525.

Edit: nvidia-driver-530 and entering the Steam client beta did not change anything, still crashes at regular intervals.

Edit 2: Finally caught a crash running from terminal, here are the last few lines:

Maximum number of clients reachedsrc/clientdll/inputgenerator_linux.cpp (336) : m_pDisplay
src/clientdll/inputgenerator_linux.cpp (336) : m_pDisplay
assert_20230501062906_35.dmp[23697]: Uploading dump (out-of-process)
/tmp/dumps/assert_20230501062906_35.dmp
crash_20230501062906_36.dmp[23700]: Uploading dump (out-of-process)
/tmp/dumps/crash_20230501062906_36.dmp
assert_20230501062906_35.dmp[23697]: Finished uploading minidump (out-of-process): success = yes
assert_20230501062906_35.dmp[23697]: response: CrashID=bp-7e42426d-375e-42cf-8c32-b71ca2230430
assert_20230501062906_35.dmp[23697]: file ''/tmp/dumps/assert_20230501062906_35.dmp'', upload yes: ''CrashID=bp-7e42426d-375e-42cf-8c32-b71ca2230430''
crash_20230501062906_36.dmp[23700]: Finished uploading minidump (out-of-process): success = yes
crash_20230501062906_36.dmp[23700]: response: CrashID=bp-e910535c-a2ef-4a35-9c6d-c7ee62230430
crash_20230501062906_36.dmp[23700]: file ''/tmp/dumps/crash_20230501062906_36.dmp'', upload yes: ''CrashID=bp-e910535c-a2ef-4a35-9c6d-c7ee62230430''
/home/nocty1501/.local/share/Steam/steam.sh: line 798: 14965 Segmentation fault      (core dumped) "$STEAMROOT/$STEAMEXEPATH" "$@"