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 #5007 (comment)

[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

[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

[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 ValveSoftware/Proton#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?

[Plarpoon]

It's still in beta, you have to wait for a full release of the update

[doogie544]

Just a note:

Team Fortress 2 has kind of taken over this thread but many, many more games are also affected. Some are valve games and some are games developed using the source one engine by others.

Just because TF2 is going to be working again does not mean this issue is fixed by any means.

Just from what I can recall

Valve games affected:

Day of Defeat Source
Black Mesa
Counter Strike Source (unsure of this one tbh)

Non-valve games affected:

Garry's mod
No More Room In Hell
Codename Cure
Fistful of Frags

I believe I have seen others mentioned as well but can't recall any specifically.

This is an issue with the source engine itself and is only going to be fixed when the source one devs fix it or possibly valve can include the gpref-tools as part of the steam runtimes and set steam to bypass the in game libraries in preference to the ones that are included in the runtime (this is what the flatpak team did to get those games working in the flatpak version without requiring any preloading)

[oappicgi]

This is an issue with the source engine itself and is only going to be fixed when the source one devs fix it or possibly valve can include the gpref-tools as part of the steam runtimes and set steam to bypass the in game libraries in preference to the ones that are included in the runtime

I would prefer if they would make x64 binaries available for games / source 1 engine. 3rd party game devs could then compile game as x64 game, which seems to increase performance significantly at least for me. According to steam hardware review over 90% of linux users use 8gb or more ram, most likely meaning they are using 64bit CPU. Yes, I know there is some way to get 32bit OS recognize more than 4gb but i don't think there are that many are using said feature. 64bit mode should be default option and 32bit should be something you would have to select on launch menu or something.

I do however agree that something should be done to make installing these games more streamlined. If some other option is easier to get to goal and Valve doesn't want to invest more time on this, that is fine as well, but if this is truly the performance increase It would be slightly sad to leave it on the table... but like I said on earlier posts, really appropriate Valve guys looking into this one especially if they fix it proper way like they seem to go with tf2.

[unrealapex]

It's still in beta, you have to wait for a full release of the update

I've tested it out. I can't give you a performance comparison, but the game launches perfectly fine and you can play. You can't connect to public servers at the moment though.

[arbv]

Counter Strike Source

CSS is affected.

[simcye]

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%

still having this issue, and this resolved it.

[XeemPad]

I've had an error:
ERROR: ld.so: object 'run/host/usr/lib32/libtcmalloc.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.

If you're attentive enough, you can see, that the game is trying to access '/run/host' for some reason.
So I've set LD_PRELOAD=../../usr/lib32/libtcmalloc.so.4 %command% launch parameter, which allowed me to launch and play the game (CSS) after 2 days spent on researching the problem.

Weirldy enough, the error message is still shown:
ERROR: ld.so: object '../../usr/lib32/libtcmalloc.so.4' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
but the game works perfectly.

[DanielGaaA]

On Opensuse tumbleweed I can launch TF2 without crashing. Your distribution need to update gcc or cherry pick patch from this bugreport. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113258

[Jayman2000]

Your distribution need to update gcc or cherry pick patch from this bugreport. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113258

Please note, though that if a distribution chooses to update GCC, they’ll need to update to an unstable version in order to get this fix. The commits from that bug report were written in 2024, but the most recent releases of GCC are all from 2023.

[pnelego]

Replying to #5043 (comment)

There seems to be something definitely going on with VAC and running your own libtcmalloc. It's hard to say exactly WHY its happening, but it seems to also present issues connecting to servers from my experience. I suspect there are some modifications to the lib valve distributes, but its hard to say for sure.

[jessienab]

Replying to #5043 (comment)

I've been running the lib32-gperftools workaround for TF2 on Linux for several months now without any issues whatsoever connecting to any servers, nor encountering any kind of VAC ban (knock on wood). Are you saying there's new issues coming up for users? Are people being banned?

[Beanie496]

It looks like the official update to 64-bit has fixed this issue on TF2 (on my machine, at least). More verification needed though.

[doogie544]

It looks like the official update to 64-bit has finally fixed this issue (on my machine, at least). More verification needed though.

No the new update to Team Fortress 2 did not fix the issue.

This issue has affected a LOT MORE games than just TF2.

This affects many games that use the source one engine so unless all those games that are affected also release a similar update the issue will persist.

In fact even if all those games did release such an update, the issue would still not be "fixed" it would just be worked around. The underlaying issue in the source one engine would still exist

[doogie544]

A non-exhaustive list of the game that are known not to work is here.

#5043 (comment)

[unknownaccount11]

It looks like the official update to 64-bit has finally fixed this issue (on my machine, at least). More verification needed though.

On Steam Deck/KDE Plasma here and still having the issue even after the update. When I run through terminal it complains about being unable to find libmimalloc.so instead of tcmalloc.so.4

[Plarpoon]

Are you sure the update is downloaded?

[unknownaccount11]

Definitely downloaded. Running through steam just closes it without anything opening, running through terminal says ''/home/deck/.local/share/Steam/steamapps/common/Team Fortress 2/tf_linux64'
/home/deck/.local/share/Steam/steamapps/common/Team Fortress 2/tf_linux64: error while loading shared libraries: libmimalloc.so: cannot open shared object file: No such file or directory'

[Plarpoon]

@unknownaccount11 I actually just tested it on Fedora 39 also with KDE Plasma and it works perfectly fine.

Here is attached my Steam Runtime System Information

Perhaps they might have yet to push the Steam Deck update into its repos? I don't know, later in the day will check with my own Steam Deck

[Beanie496]

It looks like the official update to 64-bit has finally fixed this issue (on my machine, at least). More verification needed though.

No the new update to Team Fortress 2 did not fix the issue.

This issue has affected a LOT MORE games than just TF2.

This affects many games that use the source one engine so unless all those games that are affected also release a similar update the issue will persist.

In fact even if all those games did release such an update, the issue would still not be "fixed" it would just be worked around. The underlaying issue in the source one engine would still exist

Good point, I meant for tf2 only. I'll update my original comment.

[unknownaccount11]

Definitely downloaded. Running through steam just closes it without anything opening, running through terminal says ''/home/deck/.local/share/Steam/steamapps/common/Team Fortress 2/tf_linux64' /home/deck/.local/share/Steam/steamapps/common/Team Fortress 2/tf_linux64: error while loading shared libraries: libmimalloc.so: cannot open shared object file: No such file or directory'

Game launches with Proton 8 as I found from this steam discussion where other people are having the same problem, but TF2 launches in insecure mode so you can't connect to servers.

[Plarpoon]

@unknownaccount11 Yeah, can confirm the Steam Deck doesn't work yet, perhaps they have to update the base image of Arch Linux to the modern dependencies first. Anyway, the game works as usual with Proton if you really want to play it on the Deck for now.

[unknownaccount11]

Working for me on the Deck without any compatibility enabled after I downloaded the update this morning