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

[pukmajster]

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

[kisak-valve]

Previously noted at https://github.com/ValveSoftware/Source-1-Games/issues/5007#issuecomment-1609397945

[prismz]

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

[rKsanu2MMYvypWePtQWM]

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

[TrixieUA]

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

[Ultimator14]

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

[Ultimator14]

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

[GoTeamAnt]

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%

[scorpius2k1]

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.

[LargeOunce]

Seconding the confirmation for GoTeamAnt's workaround.

[lflo5727]

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.

[fraz0815]

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 :-)

[jessienab]

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.

[lflo5727]

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

[LargeOunce]

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

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

[LargeOunce]

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.

[kisak-valve]

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 https://github.com/ValveSoftware/Proton/issues/3150.

[LargeOunce]

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

[Beanie496]

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]

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]

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]

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?

[Khrozma]

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]

@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.

[pukmajster]

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

[Khrozma]

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.

[pukmajster]

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

[bbhtt]

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

[Zettaga]

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!

[Khrozma]

Replying to https://github.com/ValveSoftware/Source-1-Games/issues/5043#issue-1806058075

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.

[spagootie]

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.

[lflo5727]

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?

[DrunkenToast]

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.

[ssrublev]

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]

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.

[Nitrousoxide]

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.

[Plarpoon]

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!

[Khrozma]

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

[Plarpoon]

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

[Khrozma]

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

Do let us know if you get it fixed too!

[dnkmmr69420]

I am experiencing issues with launching portal games as well https://github.com/ublue-os/bazzite/issues/282

[Plarpoon]

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.

[TheAnnoyingFruit]

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

[Khrozma]

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

[Plarpoon]

@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!

[Khrozma]

Replying to https://github.com/ValveSoftware/Source-1-Games/issues/5043#issuecomment-1712957891

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

[Plarpoon]

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.

[swedneck]

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!

[doogie544]

@bbhtt per your comment here https://github.com/ValveSoftware/Source-1-Games/issues/5043#issuecomment-1703997080 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).

[pukmajster]

Replying to https://github.com/ValveSoftware/Source-1-Games/issues/5043#issuecomment-1721140089

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

[Plarpoon]

@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.