[Linux] Game Freezes up completely if I switch loadouts too quickly

[vidhanio]

If I click the loadout switch binds successively too quickly, the game completely freezes and I have to restart.

[jooonior]

Can't replicate this with my setup (Windows 10, fast NVMe SSD). I can spam the binds 50+ times as fast as I can and nothing happens.

With every loadout switch TF2 opens, appends to, and closes a file. Theoretically, this could create too much IO, but it does not seem likely to me.

1. How many times and how fast (approximately) do you have to switch loadouts for this to happen?
2. What drive do you have TF2 installed on (HDD or SSD)?

[vidhanio]

nvm, doesn't even require spamming. i just single clicked and it froze up the game completely as well. it seems completely random.

It is installed on an HDD.

[jooonior]

That is strange. Have you used the script before the Summer 2024 update (any similar issues?) or did you install it just now?

Can you check if it still happens when the save logs are not actually written to disk? You can do this by mounting ramfs over your tf/cfg directory.

cd "Team Fortress 2/tf" 
mv cfg cfg.old
sudo mount ramfs -t ramfs cfg
sudo chown $USER:$USER cfg  # should be same as other `tf/*` subfolders
cp -r cfg.old/* cfg

Then launch TF2 and see if it still happens.

When done, restore your tf/cfg directory.

cd "Team Fortress 2/tf"
sudo umount cfg
mv cfg.old cfg

[vidhanio]

Yep, I've been using this script for a while now (it's super good btw, thank you for making it!). I'll try the ramfs thing and let you know what happens.

[vidhanio]

can confirm that it does crash with ramfs.

[vidhanio]

v3.1 seems to cut down on writes if switching back to the same loadout, i'll test it tonight @jooonior. i don't think it will change much though in terms of the random crashes. i might just have to try debugging where exactly the game crashes. it doesn't seem to be binding it to a key, because i can just type "loadouts.A" into the console and then up arrow + enter spam a bunch and it crashed too. it really just seems to be luck, sometimes i've just gone in spawn to change a loadout, press my change key once and it crashes.

another weird thing i've found: it's not just tf2 that freezes up completely. steam itself becomes completely uninteractable BUT it still responds. if i right click on the tray icon and click "library", the library pops up. animations play on the store page background. it's just that whenever i hover my mouse cursor over the window, it dissapears and i can't do anything. same with tf2. they never end up as "not responding", just frozen and uninteractable. however, tf2 does completely freeze rather than just being unresponsive to mouse movement. super weird

[jooonior]

v3.1

Nothing in v3.1 is related to this issue.

steam frozen too

Perhaps its a bug in Valve's stdlib? No idea how to debug that (not to mention fixing it).

[jooonior]

I've installed TF2 in a Mint (what distro are you on btw?) VM, but even there I can't replicate this — I can ABABABABABA spam the loadout switch and it works just fine. I'm running out of ideas.

If you want to debug this, I would recommend cloning this repo into your tf/custom/ and tinkering with the script to see if you can find what is causing the freeze. If you do this, don't forget to delete the loadouts.vpk archive or it will override the loose files.

The only somewhat unusual things this script does is using con_logfile to write config files. I would focus on that.

• con_logfile cfg/file.txt to write console into a file under tf/cfg/ (maybe writing into subdirectories is bugged somehow)
• con_logfile . to disable console logging (. appears to be an invalid log file name, maybe it does something weird instead)
• con_logfile file.txt; echo message; con_logfile . to append message to file.txt (maybe changing logfile too quicky can break something)

Also it is probably not a bad idea to try changing the loadouts.save.X aliases (here) to do nothing and seeing if you can still make the game freeze when nothing is being saved.

[jooonior]

One more idea: What does happen when you run alias loop loop; loop (your game should freeze and crash, but is it the same kind of freeze or something different?).

[vidhanio]

sorry for the late response, wanted to compile all my findings and reply at once. i really appreciate your help debugging this issue btw :)

what distro are you on btw?

nobara 40 (kde plasma + nvidia, on a laptop), based on fedora. i have completely reset my tf2 with -autoconfig and a completely blank custom folder except for the latest loadouts.vpk. when i opened tf2, i just ran exec loadouts/init, loadouts.scout, and bound loadouts.A/loadouts.B to two keys and spammed them in a casual lobby, and it crashed as expected.

I can ABABABABABA spam the loadout switch and it works just fine.

btw, i've found for some reason it crashes much faster during spam if in a real server (i just join valve casual) rather than my local tr_walkway, if you want to try there as well.

If you want to debug this, I would recommend cloning this repo into your tf/custom/ and tinkering with the script to see if you can find what is causing the freeze. If you do this, don't forget to delete the loadouts.vpk archive or it will override the loose files.If you want to debug this, I would recommend cloning this repo into your tf/custom/ and tinkering with the script to see if you can find what is causing the freeze. If you do this, don't forget to delete the loadouts.vpk archive or it will override the loose files.

yep, i've been doing that while debugging so i can edit and re-exec whenever needed

Also it is probably not a bad idea to try changing the loadouts.save.X aliases

removing the echo part prevents crashing, so it just seems to be somewhere in the process of switch-echo-switch where it crashes.

One more idea: What does happen when you run alias loop loop; loop

game freezes/crashes, steam itself is fine, so it seems like a different type of crash.

[vidhanio]

new finding lol, vesktop (a discord client for linux) also has the same behaviour as steam, with window interaction completely broken but moving elements already on-screen still working as usual. this may be a little deeper than a tf2 bug, it might be some specific form of crash on an app which also affects my DE. I also tested that this crash (and related freezes in steam/discord) happens whether tf2 is in windowed or fullscreen. opening system monitor and force quitting tf2 returns steam and vesktop back to normal.

[vidhanio]

alright, this is 100% not related to this script. a minimal reproducible example of literally just

bind ins "con_logfile a.txt; echo a; con_logfile ."

being spammed in a casual lobby does the same crash.

[jooonior]

I finally managed to reproduce this. It looks like you have to be in a semi-full server.

1. main menu: can't reproduce
2. empty listenserver: can't reproduce
3. listenserver with bots: can reproduce
4. offline practice with bots (same case as 3 I think): can reproduce
5. empty (or near-empty) real server: can't reproduce
6. real server with 20+ people: can reproduce

On Windows, no matter what I do, no freeze. Also got a friend who has TF2 an HDD to try it — same story.

A minimal exaple is spamming con_logfile a.txt; echo a; con_logfile "" in one of the situations listed above (meaning con_logfile . was not the problem).

[jooonior]

It seems that versions before v3.0 are not affected by this (or its much less likely to happen), as they write to the save file only when the game is being closed. I don't think there's a way to fix this without resorting to manual saving.

Your best option is to use v2.1 and run exec loadouts/save manually before you close the game. You can define an alias for this or maybe edit your HUD to run it when you click the quit button (not sure if that's possible for every HUD).

[vidhanio]

I finally managed to reproduce this. It looks like you have to be in a semi-full server.

yep, i should've mentioned that

On Windows, no matter what I do, no freeze. Also got a friend who has TF2 an HDD to try it — same story.

very weird. one of my friends also could reproduce it on their steam deck, seems to be a global linux issue.

A minimal exaple is spamming con_logfile a.txt; echo a; con_logfile "" in one of the situations listed above (meaning con_logfile . was not the problem).

peering through the actual tf2 source code for con_logfile, literally anything passed to con_logfile which does not end with .txt or .log and is not a "valid log filename" will just set be set to console.log. this means con_logfile "" and con_logfile . will just set it to con_logfile console.log. we tested it with a.txt and b.txt and it crashed just like normal.

[vidhanio]

Your best option is to use v2.1 and run exec loadouts/save manually before you close the game. You can define an alias for this or maybe edit your HUD to run it when you click the quit button (not sure if that's possible for every HUD).

i might just alias q to save and quit. i might just be able to monkey patch my hud too, and change the quit button to engine q, but 99% of the time i just type quit in console lol.