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

[Alex Henry]

Thank you very much for your detailed reply, Simon!

> I don't think either of the issues you described is time64-related

I'll agree with you since you have substantiated this conclusion with facts
that make it more likely than not for it to be the.case (despite my vague
report).

I wouldn't have opened this bug-report if not on suspicion of it being
time-64-related as I understand Debian (or Valve) can't re-compile a game
or fix a game's code when the problem is on the other end.

It was the combination of: multiple games breaking at once (despite a not
terribly out-of-date system prior to the upgrade); me never having had a
Steam game break due to a system update before in several years; and the
64-time migration that made me want to raise the flag, as bug reports are
pretty much the only way I contribute to Debian these days despite having
benefited from the project for a long time.

(The supposedly platform-independent Java errors and my knowledge that
time-64 "wasn't supposed" to break 64-bit systems notwithstanding).

I've also tried a couple more native titles since the big summer-sale has
just ended and had no problems with any of them, which again corroborates
your conclusion.

Thank you very much once again for your reply and for looking into the
matter with far more relevant knowledge than I have! The work-arounds you
documented here could also help some poor soul, trying to get their games
working again in the future (to which I'll also add Steam Play's Proton).

I hope I haven't wasted anyone's time unduly with this report - as I
imagined it could maybe have been a larger, yet-unreported underlying issue
with 64-bit-time. If you or anyone else feels differently, I apologize.

On Mon, 15 Jul 2024 at 14:22, Simon McVittie <smcv at collabora.com> wrote:

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