5

I only have Soldier installed. What if you remove Steam Runtime Sniper?

6

When I click “uninstall,” I get the following error message:

Failed to uninstall Steam Linux Runtime - Sniper due to:

Uninstall error - missing shared content

7

OK so probably it is required by something, either a whitelisted game, or a Proton version used for one of your game.

Maybe you could try Proton 8 as it released with a Sniper update recently (also reset the Proton prefix if you know what you’re doing).

8

I have tried Proton 8, 7, 6, experimental, and latest GE.

I don’t.

9

Switching between Proton version can lead to issues in the prefix.

To reset the prefix for your game (the prefix is the ‘virtual Windows’ hard drive, kinda) you can (on default installation path) delete the folder /.local/share/Steam/steamapps/compatdata/XXX/ where XXX is the Steam AppID of your game. Be careful doing so, as some games do NOT save to the cloud so you can lose a savegame deleting the folder. For safe keeping, just rename XXX to XXX_old and you can bring savegames back if needed then.

Deep Rock Galactic AppID = 548430
Demon Turf Neon Splash AppID = 1747890

After folder is deleted or renamed, start the game and it will recreate it from the Proton version you selected.

Verifying game files from game properties before starting the game could also be a good thing.

Also, can you reproduce the issue without using bluetooth at all?

3 Likes
10

That would make sense, I did play both of these games on Proton 7 and then on Proton 8 when it came out.

If the prefixes are different, can I be certain that they will go back in at the same location without issues?

11

You just bring the save file to the newly created prefix. DRG has Steam cloud save so you don’t need that. I don’t know the other game.

12

The other game does as well. Having now tested for about an hour, I am fairly certain your solution works.

13

So it was not a bluetooth issue, but a messed up game/prefix? Let see play more and if the issue doesn’t come back it may be that.

14

I am fairly certain the bluetooth issue was a symptom and not the cause. DRG is bugged on Proton 8 it seems (unrelated to this thread), so after I fixed it I had to revert to 7 and forgot to remake the prefixes again, triggering the crash. My headphones weren’t connected, and I was unable to find anything in the journal at the time of the crash.

1 Like
15

LOL nevermind DRG just crashed again. I gleaned some new info from it though: the mouse also works and can move around the screen, it was just hidden all the other times this happened. Also, it seems that this time Discord crashed alongside the game? The bluetooth crash log didn’t show up this time, even though the headphones were connected, but that issue may have been fixed in the latest testing update.

Apr 26 19:35:24 xps15 plasmashell[8757]: [0426/193524.381846:ERROR:elf_dynamic_array_reader.h(64)] tag not found
Apr 26 19:35:24 xps15 plasmashell[8757]: [0426/193524.387703:ERROR:directory_reader_posix.cc(42)] opendir /home/fasto/.config/discord/Crashpad/attachments/5ba68b32-7fde-4790-b635-e973b02a7895: No such file or directory (2)
16

Can you show more information about this? Links, possibly? I’d like to know exactly what in the prefix is affected if so.

17

No. This is how it is. Switching Proton version forces the prefix to be "updated’ with the new Proton version files, and different version have sometimes different structures especially the GE versions. The “update” process of the prefix can lead to issues then.

This is all experience, if you are around long enough with Proton games it will happen to you, resetting the prefix will instantly fix unexplainable issue (most likely game not starting anymore).

19

https://www.reddit.com/r/SteamDeck/comments/zr44yj/psa_geproton_43_can_corrupt_your_previous_wine/

Here, some evidence for people that like actual facts and not stupid hearsay.

But sure, let’s just assume and than make technical decisions based on assumptions. That would get me fired at my job if I worked that way.

20

No need to be butthurt… because… why by the way?

22

Well I tried getting a log of one of the crashes with PROTON_LOG=1 and ended up with a 23GB file of incomprehensible assembly stacktraces.

23

That seems abnormally huge to me. Maybe this is a good lead to the issue. How much time did you play to generate this large of a log? Maybe you have a video card/driver issue? Did you set launch parameters in the game properties?

24

I played for under 20 minutes before crashing. There are no timestamps so I can’t say whether it all happened at once or over the course of those 20 minutes. However, my computer did take a veeery long time doing REISUB (like 30 seconds compared to near instantly) so I lean towards all at once at the end. Though, I did notice minor lag spikes throughout, so it could have been the whole time.

I am using Optimus, tried on my iGPU and got the crash as well.

Yes. I have tried with and without gamemoderun.

PROTON_LOG=1 gamemoderun %command%
25

I just tried playing for around 1-2 minutes, ended up with a 760MB file of similar logs. Here’s a sample:

2028.027:0124:0128:trace:unwind:dump_unwind_info unwind info at 00000001816E9F40 flags 0 prolog 0x19 bytes function 000000018078F1E0-000000018078F1F9
2028.027:0124:0128:trace:unwind:dump_unwind_info     0x19: subq $0x98,%rsp
2028.027:0124:0128:trace:unwind:dump_unwind_info     0xe: pushq %rbx
2028.027:0124:0128:trace:unwind:dump_unwind_info     0xd: pushq %rbp
2028.027:0124:0128:trace:unwind:RtlVirtualUnwind type 0 rip 18078f1d4 rsp 10ea40
2028.027:0124:0128:trace:unwind:dump_unwind_info **** func 78f1b0-78f1df
2028.027:0124:0128:trace:unwind:dump_unwind_info unwind info at 0000000181683B58 flags 0 prolog 0xa bytes function 000000018078F1B0-000000018078F1DF
2028.027:0124:0128:trace:unwind:dump_unwind_info     0xa: movq %rbx,0x30(%rsp)
2028.027:0124:0128:trace:unwind:dump_unwind_info     0xa: subq $0x20,%rsp
2028.027:0124:0128:trace:unwind:dump_unwind_info     0x6: pushq %rdi
2028.027:0124:0128:trace:unwind:RtlVirtualUnwind type 0 rip 18079736b rsp 10ea70
2028.027:0124:0128:trace:unwind:dump_unwind_info **** func 797140-79796a
2028.027:0124:0128:trace:unwind:dump_unwind_info unwind info at 00000001816EA764 flags 0 prolog 0x29 bytes function 0000000180797140-000000018079796A
2028.027:0124:0128:trace:unwind:dump_unwind_info     0x29: movq %rdi,0x10c8(%rsp)
2028.027:0124:0128:trace:unwind:dump_unwind_info     0x29: movq %rsi,0x10c0(%rsp)
2028.027:0124:0128:trace:unwind:dump_unwind_info     0x29: movq %rbx,0x10b8(%rsp)
2028.027:0124:0128:trace:unwind:dump_unwind_info     0x29: subq $0x1090,%rsp
2028.027:0124:0128:trace:unwind:dump_unwind_info     0x14: pushq %r15
2028.027:0124:0128:trace:unwind:dump_unwind_info     0x12: pushq %r14
2028.027:0124:0128:trace:unwind:dump_unwind_info     0x10: pushq %rbp
26

The log should not big that big, that indicates something is flooding it. At this point if the log is not shareable only you can look at it. What you posted is not relevant I think.