ValveSoftware/Source-1-Games

Failure to start with tcmalloc "Attempt to free invalid pointer" and radeonsi built against llvm 16

pukmajster opened this issue ยท 196 comments

NOTE:

No one utilizing the workarounds found in the comments has faced any issues with VAC, so they are most likely safe to use, but do so at your own risk.


ORIGINAL POST:

OS: Fedora 38 Workstation, GNOME (both X11 and Wayland)
CPU: Intel Core i9 10900K
GPU: AMD Radeon RX 6800
RAM: 32GB

no launch parameters used

CSS and TF2 simply refuse to even launch when running Steam from the RPM fusion repos. Running Steam Flatpak however, these problems go away and the games are playable.

Hint for potential fix, posted by user Jennie on protondb for tf2:

I fixed this bug by removing the libtcmalloc_minimal.so.4 library in the bin folder in the tf2 folder and making a symbolic link to the libtcmalloc_minimal.so.4 library from the system. But it is worth installing packages, by command sudo dnf install gperftools gperftools-devel gperftools-libs.i686 Note: create a symlink from /lib/libtcmalloc_minimal.so.4

Previously noted at #5007 (comment)

prismz commented

This issue occurs for me even in the flatpak version of Steam, even after symlinking the system libtcmalloc.

OS: Gentoo on dwm
CPU: Ryzen 7 5800x
GPU: Radeon RX 6600
RAM: 64GB DDR4

any news? OpenSUSE Tumbleweed no longer ships with 32-bit version of libtcmalloc so I can't transplant it

Fedora Workstation 38, steam flatpak, same issue trying to run Elden Ring(When running on Wayland it just works)

OS: Fedora 38 Workstation, GNOME (Issue only on X11)
CPU: AMD Ryzen 5800X
GPU: Nvidia RTX 3070
RAM: 32GB

I was able to launch the game via steam after symlinking (or copying) the 32bit system libtcmalloc on Gentoo LInux.

USE="abi_x86_32" emerge dev-util/google-perftools  # install 32bit version of libtcmalloc
cd ~/.local/share/Steam/steamapps/common/Team\ Fortress\ 2/bin
mv libtcmalloc_minimal.so.4 libtcmalloc_minimal.so.4.bak
ln -s /usr/lib/libtcmalloc_minimal.so.4 libtcmalloc_minimal.so.4  # cp also works

Also the gperftools have basically no dependencies so you should be able to build it yourself.

Build

git clone https://github.com/gperftools/gperftools.git
cd gperftools
./autogen.sh
automake
./configure --build=i686-pc-linux-gnu CFLAGS=-m32 CXXFLAGS=-m32 LDFLAGS=-m32
make

Copy

cd ~/.local/share/Steam/steamapps/common/Team\ Fortress\ 2/bin
mv libtcmalloc_minimal.so.4 libtcmalloc_minimal.so.4.bak  # backup
cp <gperftools-dir>/.libs/libtcmalloc_minimal.so.4.5.13 ~/.local/share/Steam/steamapps/common/Team\ Fortress\ 2/bin/libtcmalloc_minimal.so.4

Today (29.08) archlinux udpated llvm-.libs to 16.0.x and I experienced the same issue.

Possible solution for archlinuxers:

  • Install lib32-gperftools from aur

Start tf2 like this (launch options):
LD_PRELOAD=/usr/lib32/libtcmalloc.so %command%

Today (29.08) archlinux udpated llvm-.libs to 16.0.x and I experienced the same issue.

Possible solution for archlinuxers:

* Install lib32-gperftools from aur

Start tf2 like this (launch options): LD_PRELOAD=/usr/lib32/libtcmalloc.so %command%

Experiencing the same issue.

Arch Linux
AMD Radeon 6900XT
rc/tcmalloc.cc:278] Attempt to free invalid pointer 0x97a9ad0

Confirming @GoTeamAnt's workaround also allows 'Half-Life 2: Deathmatch' to launch properly.
Thank you.

Seconding the confirmation for GoTeamAnt's workaround.

Will add another confirmation for @GoTeamAnt 's workaround.
Just updated Arch the other day and found TF2 wouldn't launch. Workaround works for me. Hope to see it patched soon.

Today (29.08) archlinux udpated llvm-.libs to 16.0.x and I experienced the same issue.

Possible solution for archlinuxers:

  • Install lib32-gperftools from aur

Start tf2 like this (launch options): LD_PRELOAD=/usr/lib32/libtcmalloc.so %command%

confirming also on manjaro (testing), thanks :-)

Today (29.08) archlinux udpated llvm-.libs to 16.0.x and I experienced the same issue.

Possible solution for archlinuxers:

* Install lib32-gperftools from aur

Start tf2 like this (launch options): LD_PRELOAD=/usr/lib32/libtcmalloc.so %command%

Working as well for me, thank you.

However, I am slightly concerned that this could trigger a VAC ban. Is there any such risk in having an LD_PRELOAD relating to C++ code like this?
EDIT @lflo5727 thank you for valiantly testing relating to this, that is good to hear :) I hope this is resolved soon enough upstream.

Longer term: is this something that Valve has to fix, or the Arch maintainers? I would assume it being some sort of llvm library conflict, that it's on Valve's side.

However, I am slightly concerned that this could trigger a VAC ban. Is there any such risk in having an LD_PRELOAD relating to C++ code like this?

Well, I just sat down to play after using that patch and I can't connect to the TF2 game coordinator at all. According to https://steamstat.us/ it seems to be up. Wondering if that could be related? Hard to tell since I can't launch the game without the workaround

EDIT: I take it back, seems to be working fine now
EDIT: @jasonnab played for about 30 min and no VAC ban, so I think that's fine

I also can't connect to the game coordinator. I haven't been able to since i downloaded a 40 MB update; I think the second most recent.

terminal log: https://gist.github.com/LargeOunce/874ccb8178fed03a5218bf783634c05d

screenshot
I'm using an old version of rayshud, but friends aren't showing and the community server browser says "Steam must be running to make use of find servers" Clicking casual crashes the game, with only this as any output.

crash log: https://gist.github.com/LargeOunce/397da2e7b33a9018068b0b7150950fb4

image
Hosting a local server results in this. I tried to load tr_walkway_rc2 and then the training mode. Neither could connect to the internal server.

Hello @LargeOunce, running Team Fortress 2 with Proton is not officially supported and your issue is unrelated to this issue report.

Having written that, unofficial support for running Team Fortress 2 with Proton is being tracked at ValveSoftware/Proton#3150.

I had it unchecked but i think it had downloaded. it's fixed now with the workaround.

Today (29.08) archlinux udpated llvm-.libs to 16.0.x and I experienced the same issue.

Possible solution for archlinuxers:

  • Install lib32-gperftools from aur

Start tf2 like this (launch options): LD_PRELOAD=/usr/lib32/libtcmalloc.so %command%

Same issue. Arch Linux, AMD Radeon 5600H.
./hl2.sh gives src/tcmalloc.cc:278] Attempt to free invalid pointer 0xa6adad0.
After installing lib32-gperftools from the AUR and installing, running LD_PRELOAD=/usr/lib32/libtcmalloc.so ./hl2.sh gives a couple of errors though:

ERROR: ld.so: object '/usr/lib32/libtcmalloc.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
ERROR: ld.so: object '/usr/lib32/libtcmalloc.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.

Anyone know why?
EDIT: I've realised it's because I'm preloading the library into hl2, not the shell script, but I'm not sure how to preload the library within the script.
EDIT, again: Launching through Steam did work. This was after I move the old bin/libtcmalloc_minimal.so.4 file to the parent directory and added a symlink in its place though. I couldn't move the old library back though because it seems to have been deleted somehow? I hope that doesn't bite me later.

eiglow commented

Based on previous comments, this works for me on Fedora 39 trying to play TF2:

  1. Terminal: sudo dnf install gperftools-libs.i686
  2. Launch options: LD_PRELOAD=/lib/libtcmalloc_minimal.so.4 %command%
bbhtt commented

Running Steam Flatpak however, these problems go away and the games are playable.

The upcoming steam flatpak (now in flathub-beta) based on 23.08 freedesktop runtime is also affected as that runtime now ships llvm 16.

gperftools-libs is already included in the Flatpak https://github.com/flathub/com.valvesoftware.Steam/blob/4ff190217bbd6ee51d547671de367ba52dd28221/modules-32bit.yml#L65 but the game doesn't use that because

~/.var/app/com.valvesoftware.Steam/.local/share/Steam/steamapps/common/Team\ Fortress\ 2/hl2.sh
has this part:

elif [ "$UNAME" == "Linux" ]; then
   # prepend our lib path to LD_LIBRARY_PATH
   export LD_LIBRARY_PATH="${GAMEROOT}"/bin:$LD_LIBRARY_PATH
fi

To "fix" it, remove (create backup, move it elsewhere) libtcmalloc_minimal.so.4 from ~/.var/app/com.valvesoftware.Steam/.local/share/Steam/steamapps/common/Team\ Fortress\ 2/bin (change the game name) and run the game as is.

You can also run steam as flatpak run --env=LD_PRELOAD=/app/lib32/libtcmalloc_minimal.so.4 com.valvesoftware.steam

This'll force the game to use the bundled libtcmalloc_minimal.so.4 instead of the game's own one.

(Use with caution, as I have no idea if it triggers anti-cheat mechanisms)

prismz commented

Any updates on this? I've had llvm>=16 masked and that seems to have kept things working on my Gentoo install. I tried all the work arounds and none seemed to work so I just downgraded to LLVM 15. Can we please have confirmation that something is being done to fix this problem?

I am also having this issue.
Arch Linux (moved from Garuda, which had the same issue as well)
RX 6800 XT
Ryzen 9 5950x

EDIT: Flatpak seems to be working with no issues. Team fortress 2 ran just fine after installation and loading into a community server. If there's anything else I could provide to help potentially fix this issue please let me know!

Irets commented

@prismz I am also on Gentoo but have never had any issues. This LLVM issue with source games was brought up to me by an Arch user.

I have been on LLVM 16 since July 3rd.
My current exact version is 16.0.6 and compiled with the following USE-flags:

  • abi_x86_32
  • binutils-plugin
  • libffi
  • ncurses

Haven't done any library overrides for TF2.

Other third-party Source games also seem to be affected by this, such as No More Room in Hell

I am also having this issue. Arch Linux (moved from Garuda, which had the same issue as well) RX 6800 XT Ryzen 9 5950x

EDIT: Flatpak seems to be working with no issues. Team fortress 2 ran just fine after installation and loading into a community server. If there's anything else I could provide to help potentially fix this issue please let me know!

Now Flatpak doesn't seem to work. Same issue.

Yeah the flatpak version was recently updated to include the updated library that breaks the games

bbhtt commented

Yeah the flatpak version was recently updated to include the updated library that breaks the games

The library was always part of the flatpak. The issue is with the copy of the library coming from the game and the game overriding system libraries with LD_PRELOAD/LD_LIBRARY_PATH.

See my comment for a workaround, or downgrade the flatpak https://docs.flatpak.org/en/latest/tips-and-tricks.html#downgrading

Based on previous comments, this works for me on Fedora 39 trying to play TF2:

1. Terminal: `sudo dnf install gperftools-libs.i686`

2. Launch options: `LD_PRELOAD=/lib/libtcmalloc_minimal.so.4 %command%`

This fixed it on Fedora 38 for me, thank you!

Replying to #5043 (comment)

This fixed my issue on Arch Linux, what I did for anyone who's coming from the web in hopes to fix this issue, I removed

libtcmalloc_minimal.so.4

From /bin/ in tf2s directory, then in launch commands in Properties > General > Launch options add the following;

LD_PRELOAD=/usr/lib32/libtcmalloc.so %command%

Please note you will need lib32-gperftools from the AUR.

However, I am slightly concerned that this could trigger a VAC ban. Is there any such risk in having an LD_PRELOAD relating to C++ code like this?

Well, I just sat down to play after using that patch and I can't connect to the TF2 game coordinator at all. According to https://steamstat.us/ it seems to be up. Wondering if that could be related? Hard to tell since I can't launch the game without the workaround

EDIT: I take it back, seems to be working fine now EDIT: @jasonnab played for about 30 min and no VAC ban, so I think that's fine

From what I understand, VAC bans players in waves and not immediately. This doesn't definitively prove that triggering VAC by doing this isn't possible. Because of this, I'm not using this fix, and I'll instead be waiting for Valve and/or LLVM devs to fix it properly.

From what I understand, VAC bans players in waves and not immediately. This doesn't definitively prove that triggering VAC by doing this isn't possible. Because of this, I'm not using this fix, and I'll instead be waiting for Valve and/or LLVM devs to fix it properly.

Any idea what sort of intervals? That was a week ago and I am still VAC clean. Though I haven't played much since, a little hesitant with some of the VAC concern.

As @prismz said, it would be nice to get some sort of confirmation this is being worked on, especially as the new library is included in the Steam flatpak.
@kisak-valve is there any word if this is being worked on?

Yeah the flatpak version was recently updated to include the updated library that breaks the games

The library was always part of the flatpak. The issue is with the copy of the library coming from the game and the game overriding system libraries with LD_PRELOAD/LD_LIBRARY_PATH.

See my comment for a workaround, or downgrade the flatpak https://docs.flatpak.org/en/latest/tips-and-tricks.html#downgrading

Thanks. This workaround works for now.

Based on previous comments, this works for me on Fedora 39 trying to play TF2:

  1. Terminal: sudo dnf install gperftools-libs.i686
  2. Launch options: LD_PRELOAD=/lib/libtcmalloc_minimal.so.4 %command%

Worked for me in Fedora 38 and Black Mesa, but with /usr/lib/libtcmalloc.so.4 as preload

update: but simply deleting ~/.local/share/Steam/steamapps/common/Black Mesa/bin/libtcmalloc_minimal.so.4 also works

dhcpme commented

Based on previous comments, this works for me on Fedora 39 trying to play TF2:

  1. Terminal: sudo dnf install gperftools-libs.i686
  2. Launch options: LD_PRELOAD=/lib/libtcmalloc_minimal.so.4 %command%

Worked for me in Fedora 38 and Black Mesa, but with /usr/lib/libtcmalloc.so.4 as preload

update: but simply deleting ~/.local/share/Steam/steamapps/common/Black Mesa/bin/libtcmalloc_minimal.so.4 also works

libtcmalloc_minimal.so.4 was automatically recreated/downloaded when I did the same for HL2DM but installing gperftools-libs.i686 and then launching the repo version of steam via LD_PRELOAD=/lib/libtcmalloc_minimal.so.4 steam works.

Based on previous comments, this works for me on Fedora 39 trying to play TF2:

  1. Terminal: sudo dnf install gperftools-libs.i686
  2. Launch options: LD_PRELOAD=/lib/libtcmalloc_minimal.so.4 %command%

Worked for me in Fedora 38 and Black Mesa, but with /usr/lib/libtcmalloc.so.4 as preload

update: but simply deleting ~/.local/share/Steam/steamapps/common/Black Mesa/bin/libtcmalloc_minimal.so.4 also works

These worked for about a day but then then stopped working for me in Fedora 38.

Switching to the flatpak version of steam and the launch option for TF2:
LD_PRELOAD=/app/lib32/libtcmalloc.so %command%
seems to work for me. And since that should be the same launch environment for everyone inside the flatpak container it should work cross-distro.

I am having the same exact issues on Arch, tried the fix written above but had no success. Will try more later and let you know if there are any changes!

I am having the same exact issues on Arch, tried the fix written above but had no success. Will try more later and let you know if there are any changes!

Have you tried the fix I posted above? Worked flawlessly on my install. Only thing is it's Flatpak

Oh that might be why then, I am using Steam on the arch repo

Oh that might be why then, I am using Steam on the arch repo

Do let us know if you get it fixed too!

I am experiencing issues with launching portal games as well ublue-os/bazzite#282

I can't seem to find libtcmalloc.so on my TF2 directory, which is obviously a mistake on my end but without I will not be able to make the fix work.

I searched in /SteamLibrary/steamapps/common/Team Fortress 2/bin like showcased before but nothing.

For the sake of the argument I also tried running the game on the Steam Deck and without any special parameter or version of Proton other than experimental it worked smooth as butter immediately. So it seems at least that device is not affected by this bug.

This issue also happens with garry's mod and likewise is fixed by renaming the file "libtcmalloc_minimal.so.4".

I can't seem to find libtcmalloc.so on my TF2 directory, which is obviously a mistake on my end but without I will not be able to make the fix work.

I searched in /SteamLibrary/steamapps/common/Team Fortress 2/bin like showcased before but nothing.

For the sake of the argument I also tried running the game on the Steam Deck and without any special parameter or version of Proton other than experimental it worked smooth as butter immediately. So it seems at least that device is not affected by this bug.

Verify the integrity of the game files and make sure you have the right version of the game. If need be force it to use Proton to downloads the windows files then untick it to get the native variant. Reinstall if need be

@Khrozma I have no idea why other people gave you a thumbs down, but I found your comment very useful. My installation was not corrupted or anything but I had completely forgotten I had left the Proton flag enabled from previous testing and that makes the library files disappear, as said before that's on me.. ehh, sorry.

Anyway, I have tested downloading from the AUR the missing dependency for the game and replacing the launch parameter option to load from that external one instead, I didn't even need to remove the original file from the game folder as I had told it to load the external resource instead. It works smooth as butter that way, but obviously only on native Linux version, the proton one is still dead!

Replying to #5043 (comment)

Interesting that I needed to remove the file in order for the game to even launch for me on that regard, I had to toy around with proton a bit because the update has installed the windows version of the game without even having proton enabled at some point oddly enough, that aside I'm glad it's working for you! I only hope valve can actually fix this now

Yeah.. I am afraid the only viable fix would be for them to patch the games including their requirement. Or we will have to wait for LLVM to take this on them and fix it, but I am doubtful this is an actual possibility.

Based on previous comments, this works for me on Fedora 39 trying to play TF2:

1. Terminal: `sudo dnf install gperftools-libs.i686`

2. Launch options: `LD_PRELOAD=/lib/libtcmalloc_minimal.so.4 %command%`

Worked for me on fedora 38 as well!

@bbhtt per your comment here #5043 (comment)
I tested and found a more elegant way to launch the game without having flatpak steam launch with the environmental variable LD_PRELOAD=/app/lib32/libtcmalloc_minimal.so.4 %command% as a launch option for the affected games works as well.

A more hacky solution of just removing libtcmalloc_minimal.so.4 from the bin files of the affected games that you mentioned works as well but of course that will be reverted during a game verification or future update.

I don't think doing so should trigger VAC but as you mentioned, use at your own risk.

Maybe the needed solution is for valve to remove that file from the source-1 engine. Tho that may necessitate adding it to the steam runtime to make sure the games still run on distros that don't include the file (fedora does not include it by default for example).

Replying to #5043 (comment)

It may work but still beware, we don't know how this affects anti-cheat

@pukmajster what you say is correct, but despite this being absolutely not a promise that everything will be alright in the end I suppose if we do get flagged by VAC we can appeal it and show Valve this issue.

I have no idea which data they get when an account gets flagged but hopefully they see it's specifically for game file modifications and if it marks this specific library and it's the same as the one we are talking about in here they might just delete the ban.

I'd rather not risk my good VAC standing of 19 years lol

It's completely understandable, I made a quick test once and I am now waiting for Valve to fix it also. But that is a possibility, despite being an uncertain one.

Please , if anyone at Valve can give us any insight on the VAC situation that would be more than welcome, we are all waiting to know if we are going to get punished for testing your builds with this fix or not.

@pukmajster @Plarpoon I have played ~20 hours over the past two weeks with this work around and have not been VAC'd. I am almost 100% confident there are no issues with this, so I encourage you to do this if you have no other way of playing TF2.

@pukmajster @Plarpoon I have played ~20 hours over the past two weeks with this work around and have not been VAC'd. I am almost 100% confident there are no issues with this, so I encourage you to do this if you have no other way of playing TF2.

The problem, I believe, is that VAC bans come in waves... so it could be that an account is flagged and gets banned much later. S
omeone please correct me otherwise but that's what I've observed in news releases and previous notices of major VAC bans (like big ones for CSGO and DOTA 2 and such).

I personally am quietly still waiting for an official fix just to avoid any possible issue for this.

@jasonnab I am aware of that being the case as-well. That's why I want someone from Valve to actually confirm we are not going to get banned for this issue.

@jasonnab I am aware of that being the case as-well. That's why I want someone from Valve to actually confirm we are not going to get banned for this issue.

I would suggest, instead of waiting for someone from Valve to confirm it here, I think it would be better to contact them via Steam Support regarding this. So you would get a much quicker response from them, that you can share here.

And also make sure, to explain everything at the Steam Support, with a link to this issue.

@NULLYUKI I took your advice, a ticket has been opened, now we wait.

using ld_preload to point to my system's version of tcmalloc did not work so my solution was to just delete the copy of tcmalloc in the game's bin folder. game seems to work so far. hope this helps anyone who's struggling

update: turns out i didnt need to do this. i instead used LD_PRELOAD=/app/lib32/libtcmalloc_minimal.so.4 to point the game to flatpak's version of tcmalloc instead of my systems (which steam doesnt have read access to ๐Ÿคฆโ€โ™€๏ธ)

Steam's Flatpak runtime has been updated and this issue now affects Flatpak installations as well.

I am still waiting on Valve's reply in case anyone is wondering

I got a reply:

Thank you for reaching out to us about this. 

I have forwarded the information you provided onto the appropriate team so they're aware but please note that we cannot provide a timeline in regard to when the issue in question will be resolved. 

If you have an unrelated issue please reply here and I'll be happy to help.

Steam Support
Nicolas

I am glad @DrunkenToast you managed to get something, I am still left on read....

We'll just have to wait for the devs right now. Hopefully they were made aware so it's on their radar.
It just seems pretty bad to me since this even happens on flatpak (where they can cherrypick libraries). It might eventually transfer over to the steam deck as well.
The workarounds aren't user friendly or fun either for most users.

I actually got a reply too 6 hours ago (just noticed), I think this one is for you @kisak-valve

Are we risking for a VAC ban using this fix that was mentioned before or can we proceed on using it until one day Source 1 games are patched on Linux perhaps? I don't want to seem ingrate or wanting to rush anyone, just really curious if we are putting at risk our account or not ๐Ÿ™‚

Screenshot from 2023-09-23 03-49-37

Hello @Plarpoon, friendly reminder that I'm a Valve-affiliated moderator for Valve's issue trackers on Github, and not a Valve developer myself. I have no insight into VAC on my own without direct instruction from a developer, and due to the nature of anti-cheat in general, that's not really a public topic which I could request further insight anyway.

For the time being, I've put LLVM updates on hold in the mesa PPA I provide for Ubuntu users, and there's not much more I can do to help progress this issue towards a resolution.

We'll need to hear from a Source 1 dev when there's some change worth retesting.

That's great to know @kisak-valve and I am sorry I disturbed you for something that is not your assigned task then, is there something you could recommend me to do in order to get the attention of a Valve developer (like a proper communication channel) or is this something that will be dealt with by them in full autonomy?

naoliv commented

It's not only related to the AMD/ATI driver.
I play it with an Intel HD 3000, and I am experiencing exactly the same issue here.

Don't worry @naoliv, I have talked with Steam's customer service and thanks to an extremely kind person I have talked with this issue has been presented to Valve developers. I know that now they are aware of the issue, the rest is in their hands.

Just a hunch, since I am dealing with the same issue on Arch, would this all be fixed if Valve implemented Vulkan for TF2?
I had the same issue with other Source 1 games (L4D2, P2), but when entering -vulkan into the launch option it fixed all of my issues. That includes my 32:9 screen issue, when the game did decide to open and let me play.

@taulantxhakli I have good news for you, I also have a 32:9 monitor and I also use Arch (at least for now, I am migrating everything to NixOS).

The good news is that with the both of us in here 100% of the sold super ultra wide monitor users are present but also that I know exactly what you are talking about ๐Ÿ˜. And no, I don't really think it's necessarily true, I think what has happened is that Valve updates most of their source 1 games for Linux in a batch and has built them against a LLVM version that (once they released their problematic update) was not fully compatible. As long as Valve rebuilds their source 1 game images against a newer version of LLVM and they provide the new dependency it should work.

It's also possible they will just include the dependency in Steam Linux Runtime and just reference that one when trying to load source 1 games, which is probably a healthier decision than modifying every single game image separately.

Be aware I am in no way a Valve developer so mine are all guesses as good as yours but at least we can theorize together!

I don't really think it's necessarily true

I am sure you are right, I am just speaking from my experience. When playing other Source 1 games, they would have this really odd visual bug. But when adding the -vulkan launch option, it fixes everything, including it running better, I think? Might be a placebo but it is worth mentioning.

As a present example, when putting this launch option into TF2: LD_PRELOAD=/lib/libtcmalloc_minimal.so.4 %command%
I am able to launch the game but unable to take screenshots and see the Steam overlay. Including this being how I am viewing the game in some maps (e.x. 2fort).

edit:
Want to mention that I got the LD_PRELOAD launch option from the ProtonDB site, which people have been using different variations of it.

@taulantxhakli any information is golden, thank you for sharing! This community is built on discovery! Your guess is as good as mine for these things! ๐Ÿ˜„

Vlek commented

Also having this issue. Unable to load TF2 unless using the Scout option. Then, when attempting to join a match, the game crashes.

Took an oddly large amount of fiddling but I finally got it working after installing gperftools-libs.i686 on Fedora 38 (everything I saw before finding this thread was wrongly suggesting the 64 bit version) and putting the libtcmalloc.so file it provides in my TF2 install folder and forcing the Scout runtime. But, now I have no sound, strangely. The game also does not close correctly when I try to close it normally, I have to either stop it from the Steam launcher or kill the process otherwise.

Took an oddly large amount of fiddling but I finally got it working after installing gperftools-libs.i686 on Fedora 38 (everything I saw before finding this thread was wrongly suggesting the 64 bit version) and putting the libtcmalloc.so file it provides in my TF2 install folder and forcing the Scout runtime. But, now I have no sound, strangely. The game also does not close correctly when I try to close it normally, I have to either stop it from the Steam launcher or kill the process otherwise.

Went down a similar route of thinking I didn't have the 32bit libs installed, then realized they're just named differently than arch and in a different folder. Did the same fix of renaming the current lib in the install directory and copying the system version over (tried a symlink but the game failed to recognize it) and also had no audio. also got it to work with the launch option LD_PRELOAD=/usr/lib/libtcmalloc_minimal.so.4 %command% but again no audio. Works fine with audio on my steam deck of course, but I'm guessing that's using an older library.

I added an output log to my launch options to see if it gave any clues to why there is no audio, this line was in there like 4 times:
ERROR: ld.so: object '/run/host/usr/lib/libtcmalloc_minimal.so.4' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.

so I thought "oh maybe with the halloween update it needs the 64 bit library now and that is why the audio is missing? so I subbed out the LD_PRELOAD for the 64 bit version of the library, got the same error on the 64 bit version, but this time the game didn't launch at all.
ERROR: ld.so: object '/run/host/usr/lib64/libtcmalloc_minimal.so.4' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS64): ignored.

i think its safe to say that the workaround doesn't lead to a vac ban (otherwise several people in this thread including me would be vaced right now ( its been over 2 weeks)

I think that's true. I've also been running with new libsdl for like 2 years without issue.

ltworf commented

I replaced libtcmalloc with an old one from debian (the current one makes it crash) and the result is that the game just crashes a couple of seconds later for a different unknown issue.

naoliv commented

i think its safe to say that the workaround doesn't lead to a vac ban (otherwise several people in this thread including me would be vaced right now ( its been over 2 weeks)

VAC bans are delayed.

i think its safe to say that the workaround doesn't lead to a vac ban (otherwise several people in this thread including me would be vaced right now ( its been over 2 weeks)

VAC bans are delayed.

they are delayed by a week. its been over a week

Replying to #5043 (comment)

Thanks, that worked on Arch Linux. Now I can run CS:S again.
I don't understand why Valve doesn't give a F*** about this months old problem.

Took an oddly large amount of fiddling but I finally got it working after installing gperftools-libs.i686 on Fedora 38 (everything I saw before finding this thread was wrongly suggesting the 64 bit version) and putting the libtcmalloc.so file it provides in my TF2 install folder and forcing the Scout runtime. But, now I have no sound, strangely. The game also does not close correctly when I try to close it normally, I have to either stop it from the Steam launcher or kill the process otherwise.

Same here (missing sound + non closing game). Just rebooted the computer.

* Install lib32-gperftools from aur

Start tf2 like this (launch options): LD_PRELOAD=/usr/lib32/libtcmalloc.so %command%

I went with the aforementioned Arch resolution, with the command as:
LD_PRELOAD=/usr/lib32/libtcmalloc.so %command% -console
and extra launch additions going AFTER %command%

Two things I noticed:

  • Unable to access Mann Co. Store as Steam claims the overlay needs to be enabled, and TF2 restarted... but my Overlay is enabled on the game and on Steam?
  • Also, I can take screenshots with F12, and I get notification popups relating to screenshots taken, and any achievements and progress relating to.

Haven't seen either of those issues mentioned so maybe it's just me. Otherwise, works fine, and yes it should in theory not be an issue relating to VAC it seems, been almost 3 months now and nobody reporting a VAC ban... I think the OP @pukmajster should possibly be modified to remove the warning, or reword it?

Sadly, casual servers for Scream Fortress are still full of bots :(

Replying to #5043 (comment)

having the same issues. hopefully this gets addressed soon.

@jasonnab I whipped up a quick edit, thanks for the reminder.

I wanted to come back and mention that this seems to also be somewhat of a regular issue with Valve games on Linux, I remember Aperture Desk Job upon launch had this exact same issue (which is especially interesting with it being a Source 2 game when I've only ever seen other instances of a broken libtcmalloc with Source 1 games, I think outside of even this instance of things breaking) and it took them something like a week to fix it.

As said before @ngoomie I managed to pass this information to some Valve devs thanks to a lot of help, we don't know when they are going to fix it but they are 100% aware of the problem being there.

Issue is that as far as I understood they do rebuild and update of their source 1 games only when there is a big patch planned ahead and until that moment they will not merge this fix.... So we have to wait until they have a valid reason to do a big update.

Most Source 1 games being unplayable (without workarounds) should sound like a good enough reason to rebuild and update lol

It's valve we're talking about.

@Plarpoon @pukmajster @Khrozma I'm not saying Tyler McVicker is the most accurate source, but in this case he's the best we've got. In one of his latest videos (https://youtu.be/9IkZoWskREE?si=-ivI7HQ2pH-gvMPd&t=182 I linked to the correct time stamp, watch for about 1 minute to hear about this update) he talks about a large TF2 update in the works that contains a significant amount of bug fixes and patches, and that the last part that they are working on is binaries and getting Linux working again before pushing the update.

So valve is working on fixing this, its just the fact that they have like one or two people working on this game that is making it take a long time.

I invite everyone to relax a bit more, as much as it's a fun community meme I don't really think Valve has just a couple of developers on TF2. Simply put they rotate their development time on the old titles and shuffle to them only when something sizable is planned.

As much as we all love this title they have their own internal management policies and will work on something whenever needed and not when we ask. In this case we made them aware of the issue, their action is indeed needed and I am sure in the next batch of patches they will manage to fix it.

Everything will be alright, just wait a bit longer ๐Ÿ˜Š

Replying to #5043 (comment)

Using the preload workaround does indeed break the steam overlay.

LD_PRELOAD=/usr/lib32/libtcmalloc.so:$LD_PRELOAD %command%
Steam overlay is a preloaded library. Simply updating the environmental variable to include the rest of the preloaded libraries instead of replacing all of them will fix issues with steam overlay. Of course, substitute the provided path to libtcmalloc with your systems choosing.

LD_PRELOAD=/usr/lib32/libtcmalloc.so:$LD_PRELOAD %command% Steam overlay is a preloaded library. Simply updating the environmental variable to include the rest of the preloaded libraries instead of replacing all of them will fix issues with steam overlay. Of course, substitute the provided path to libtcmalloc with your systems choosing.

Ah genius! Why didn't I think of that?
Thanks!

LD_PRELOAD=/usr/lib32/libtcmalloc.so:$LD_PRELOAD %command%

Perfect, thank you so much! Mann Co. Store is working again and I get the "Steam Overlay" popup on game startup! :)

@Wirlaburla coming in clutch

I did something, and now TF2 works without anything in the launch options. I'm running Steam as a Flatpak on Fedora 38, and my GPU is an RX 6800 if that matters.

What I did was remove Steam Flatpak data using the following command:

rm -rf ~/.var/app/com.valvesoftware.Steam
Afterward, I launched Steam, re-logged in, and installed TF2. Now, it launches and runs without any problems.

Is it fixed or anything?

Flatpak merged a fix for it

@Yessy-me You didn't do anything to get it working. Flatpak added a blocklist for the libmalloc library in the game that was causing the issues so that that library will not be loaded and instead it will fall back to the libmalloc version that is included in the gperftools set of libraries that is included in the flatpak install of steam.

BTW This is not really a "fix" but is simply a workaround, the outdated libmalloc lib is still in the games (fistful of frags, no more room in hell, day of defeat source and Garry's mod also had blocklists added) they are just blocked from loading. The source 1 engine and games that use it are still actually broken

flathub/com.valvesoftware.Steam#1171