Bug#1075862: steam-installer: Some native games no longer working

[Simon McVittie]

On Sat, 06 Jul 2024 at 16:15:18 -0300, Alex Henry wrote:
> I am having problems launching some native Linux games on Steam

If this happens, it is generally something that Debian cannot solve,
because we do not have source code for, or control over, the Steam client
and proprietary games. For game-specific issues, often Valve cannot solve
it either, because they don't have access to or control over the game.

I think the two scenarios you mentioned are two separate issues. If Debian
was able to solve them, I'd be cloning the bug to give it two separate bug
numbers; but since neither is really actionable for Debian, there doesn't
seem much point.

> while I'm not sure by any means, I believe it might be related to the 64-bit-
> time transition ("t64").

I don't think either of the issues you described is time64-related,
actually: we intentionally didn't carry out an incompatible transition on
i386, to avoid breaking legacy 32-bit games, and the time64 transition
didn't change the ABI of 64-bit architectures anyway. The only impact
of the time64 transition on x86 was to rename some packages.

undefined symbol: FT_Done_MM_Var
--------------------------------

> This one for the older game:
> 
>     symbol lookup error: /lib/x86_64-linux-gnu/libfontconfig.so.1: undefined
> symbol: FT_Done_MM_Var

Which game? Please be specific: there are lots of games on Steam,
and knowing what issues affect what game will help other users to find
workarounds.

This looks like a problem that has been seen before, for example in
Civilization VI. It happens when a game bundles its own outdated copy of
libfreetype.so.6, and forces it to be used instead of the newer system
copy; but the system copy of libfontconfig.so.1 requires a newer version
of libfreetype.so.6 than the one bundled with the game, and that causes
a crash.

The likely trigger for this issue was that fontconfig was updated in 2024,
and as a side-effect it picked up a dependency on a more recent version of
Freetype than it previously had. Faster-moving distributions like Arch Linux
already experienced a similar issue, and we were just lucky that Debian 12
didn't.

A possible workaround is to configure the game to run in a
"Steam Linux Runtime" container:

Properties → Compatibility → Force the use of → Steam Linux Runtime 1.0 (scout)

Another possible workaround is to find the copy of libfreetype.so.6 in the
game directory and move it out of the way (unsupported by Valve or the game
developer/publisher, do at your own risk).

This is a game bug, caused by bundling its own private copy of a particular
library that is also required by its external dependencies. Please report
it to the game's customer support contact if it has one. The game developer
can contact Valve's Steam Runtime team for advice on how to make the game
more robust, if they are interested in doing that, but neither Valve nor
Debian can unilaterally fix this for them.

> I happen to also have a GOG copy of that older, non-Java game. I installed it
> now and it fails to run with the same error, suggesting that this is a system
> issue rather than a problem with Steam.

Yes, this is not directly Steam-related: it's an interaction between
the game (which made assumptions about the system that were probably
true when it was released, but were never really safe) and the system
(which has, entirely legitimately, changed since then).

The suggested workaround of running the Steam game in a SLR container is
roughly equivalent to running the GOG game in a Debian 10 container or VM,
in which its unsafe assumptions hopefully still remain true, and will
remain true forever.

"unable to allocate file descriptor table" in Java-based games
--------------------------------------------------------------

> A couple of these for games that seem to be Java-based:
> 
>     library initialization failed - unable to allocate file descriptor table -
> out of memory

Again, which game(s)?

This looks like a known problem with some (older?) versions of the Java
runtime environment, which creates a fixed-size table of file descriptors
sized according to the highest possible fd allowed. I don't know whether
there is a fixed JRE available. Most likely these games bundle their own
(probably outdated) copy of the JRE rather than relying on a system copy,
but without knowing which games they are, I can't know that for sure.

The likely trigger for this is a recent change in systemd (for
<https://bugs.debian.org/1029152>) which raised the highest allowed fd to
be very high. That's fine for most software, but causes the fixed-size
table in affected versions of Java to become extremely large, and in
your case too large to be allocated.

Java is relatively unusual in that it can be the hard limit that matters,
not the soft limit (which normally stays at 1024).

A possible workaround is to set the game's Launch Options
(Properties → General → Launch Options) to something like:

    prlimit -n1024:4096 -- %command%

which will reduce the soft limit to 1024 and the hard limit to 4096.
Somewhat higher hard limits (tens or hundreds of thousands) might also be
OK: 65536 and 524288 have been used in the past. Very much higher limits
(millions) are likely to trigger the bug.

If I'm right about this, then it's a bug in the Java runtime used by the
affected games, rather than a bug in Steam or Debian.

    smcv