Ah, I found the minidump but I still do not know how to upload it and the log indicates it was discarded.
I do have a similar crash from a few days earlier that has CrashID: bp-5304b31d-8ffd-4c93-8573-6fbdb2220202
I'm using steam beta and I have had it crash once, maybe twice, in such a way since installing linux.
Also Ubuntu 20.04
Does not appear to be such; I see no abnormal memory usage looking at either my system or my wife's.
Hrm. No broken pipe stuff and the allocation in this case was quite small but otherwise the behavior is quite similar.
I started to have this problem and manage to solve it.
View->settings->Shader pre-caching
If you can se that it is working on any game (in my case GTA IV), uninstall that game in steam.
This solved my problem.
How I figured it out?
Leaving steam running over the night have solved problems for me before, most likely as pre-cache have been finished. But now I could se that steam crashed and when I started steam again it started over with the same game.
view->settings->Shader Pre-Caching
untick them all then you could play urgame
it fix the problem for me
can confirm this issue with Manjaro Linux:
steam beta client
the log :
[2023-05-14 18:43:17] Background update loop checking for update. . .
[2023-05-14 18:43:17] Checking for available updates...
[2023-05-14 18:43:17] Downloading manifest: https://client-update.akamai.steamstatic.com/steam_client_publicbeta_ubuntu12?t=2829073529
[2023-05-14 18:43:17] Manifest download: send request
[2023-05-14 18:43:17] Manifest download: waiting for download to finish
[2023-05-14 18:43:19] Manifest download: finished
[2023-05-14 18:43:19] Download skipped: /steam_client_publicbeta_ubuntu12?t=2829073529 version 1683944175, installed version 1683944175, existing pending version 0
[2023-05-14 18:43:19] Nothing to do
Fossilize INFO: Setting autogroup scheduling.
Fossilize INFO: Setting autogroup scheduling.
(steam:1826): GLib-GObject-CRITICAL **: 18:50:42.044: g_object_ref: assertion 'G_IS_OBJECT (object)' failed
(steam:1826): GLib-GObject-CRITICAL **: 18:50:42.044: g_object_unref: assertion 'G_IS_OBJECT (object)' failed
(steam:1826): GLib-GObject-CRITICAL **: 18:53:08.551: g_object_ref: assertion 'G_IS_OBJECT (object)' failed
(steam:1826): GLib-GObject-CRITICAL **: 18:53:08.551: g_object_unref: assertion 'G_IS_OBJECT (object)' failed
***** OUT OF MEMORY! attempted allocation size: 1714827331 ****
src/tier0/memstd.cpp (3026) : OUT OF MEMORY
src/tier0/memstd.cpp (3026) : OUT OF MEMORY
src/tier0/memstd.cpp (3026) : Fatal assert; application exiting
src/tier0/memstd.cpp (3026) : Fatal assert; application exiting
assert_20230514185720_51.dmp[3234]: Uploading dump (out-of-process)
/tmp/dumps/assert_20230514185720_51.dmp
_ExitOnFatalAssert
assert_20230514185720_51.dmp[3234]: Finished uploading minidump (out-of-process): success = yes
assert_20230514185720_51.dmp[3234]: response: CrashID=bp-5eef5c0a-8400-4c2b-9a47-a5b3d2230514
assert_20230514185720_51.dmp[3234]: file ''/tmp/dumps/assert_20230514185720_51.dmp'', upload yes: ''CrashID=bp-5eef5c0a-8400-4c2b-9a47-a5b3d2230514''
although there is sufficient ram and space on the disk
I have a similar issue but as far as I can tell its not actually using the ram it claims
assert_20240925074738_66.dmp[10403]: Finished uploading minidump (out-of-process): success = yes
assert_20240925074738_66.dmp[10403]: response: CrashID=bp-e4dc34e8-026b-40e3-a74c-372792240925
assert_20240925074738_66.dmp[10403]: file ''/tmp/dumps/assert_20240925074738_66.dmp'', upload yes: ''CrashID=bp-e4dc34e8-026b-40e3-a74c-372792240925''
Opening the client will crash somewhere between 2 minutes and 40 minutes but only while downloading a game.
This was profile corruption in my case. After completely removing any
trace of the profile data and reinstalling steam the problem went away. It
obviously redownloaded the profile data from their server, but whatever had
been afflicting it for years went away.
So I suspect yours is a different issue. As for memory usage crashes,
there are two ways that can happen in Linux. One is actual OoM causing an
allocation failure for physical memory. Another is address space
exhaustion: a process can run out of room in its virtual memory map even if
it's not using that much physical memory. Libraries, etc all get mapped in
so there's a lot larger virtual memory map than there is physical memory
allocation.
I'd bet you're seeing a virtual memory failure. Steam's still 32bit so
that gives it somewhere around 4GiB minus the space the kernel has to use
within that map.
All that said, it doesn't give you many levers to pull to fix it. Best of
luck, regardless.
-Atma
On Wed, Sep 25, 2024 at 4:49 AM John Turner @.***>
wrote:
I have a similar issue but as far as I can tell its not actually using the
ram it claimsassert_20240925074738_66.dmp[10403]: Finished uploading minidump (out-of-process): success = yes
assert_20240925074738_66.dmp[10403]: response: CrashID=bp-e4dc34e8-026b-40e3-a74c-372792240925
assert_20240925074738_66.dmp[10403]: file ''/tmp/dumps/assert_20240925074738_66.dmp'', upload yes: ''CrashID=bp-e4dc34e8-026b-40e3-a74c-372792240925''Opening the client will crash somewhere between 2 minutes and 40 minutes
but only while downloading a game.—
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/steam-for-linux/issues/8389#issuecomment-2373860703,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AEJSYCN4XN5CCEENJGOWQVTZYKPNXAVCNFSM6AAAAABO2LG4SOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNZTHA3DANZQGM
.
You are receiving this because you authored the thread.Message ID:
@.***>
Oh, wow looking into mine while its not using the memory two of the steamwebhelpers are requesting 48g of virtual memory
Huh! Good news is they're 64bit (the main steam process isn't, because I
guess there are still 32bit games out there) but that is a huge vm
assignment. Sadly it's also something no one but valve can really do
anything about.
On Wed, Sep 25, 2024 at 9:18 AM John Turner @.***>
wrote:
Oh, wow looking into mine while its not using the memory two of the
steamwebhelpers are requesting 48g of virtual memory—
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/steam-for-linux/issues/8389#issuecomment-2374539668,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AEJSYCPU7CBGHXVQUM3SOZDZYLO5JAVCNFSM6AAAAABO2LG4SOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNZUGUZTSNRWHA
.
You are receiving this because you authored the thread.Message ID:
@.***>
I opened https://github.com/ValveSoftware/steam-for-linux/issues/11296 since it seems different.
I had a similar issue recently on my Gentoo machine. Along with the out of memory logs, I also had log lines like:
src/tier0/threadtools.cpp (3736) : Assertion Failed: Failed to create thread (error 0xc)
src/tier0/threadtools.cpp (3736) : Assertion Failed: Failed to create thread (error 0xc)
I had recently tinkered with my stack size ulimits and made both my soft and hard limits excessively large. I ran ulimit -s 8192 to reset the soft limit back to the default and re-ran steam from the same terminal, and it successfully launched as before.
Your system information
Please describe your issue in as much detail as possible:
Steam should run effectively as long as the system is running between boots for updates.
Steam instead crashes periodically. When launched from the terminal, the following is observed:
This issue occurs whether or not it is launched from the terminal, however in the case of launching from the desktop it is harder to gather debug information. In addition steam has historically crashed in a similar manner on previous Ubuntu releases, Gentoo, and even when the user was using Windows.
I have a minidump, how may I attach it?
Steps for reproducing this issue: