> ## Content Index
> Fetch the complete content index at: https://www.ctrl.blog/llms.txt
> Use this file to discover other available public pages before exploring further.

# Workaround for black screen in Unity games under Linux with glibc 2.25
- URL: https://www.ctrl.blog/entry/glibc225-unity-black-screen/
- Published: 2017-04-24T19:06:00.000Z
- Updated: 2026-08-23T22:08:23.000Z
- Description: An ABI change in glibc caused games built on the Unity engine to freeze with a black screen. Here’s how to get your games running again.
- Author: Daniel Aleksandersen
- Tags: Gaming, Linux

The smell of a new The GNU C Library (glibc) release … it’s the smell of software compatibility issues! This time, as so many times before, it has badly affected proprietary games released for Linux. The glibc mentality of “let’s just recompile all the things so they work with our library” doesn’t work for software that isn’t released in source format. Here is how you work around a problem that causes all games using the Unity Engine to stall on a black screen after launch.

glibc is a library used in almost all programs and among other things contain functions for working with multi-threaded programs, files, and memory management. In version 2.25, a change to the thread-local storage (TLS) model in glibc caused an incompatibility with the Unity 3D game engine. —or actually, the issue looks to be with Mono, a library from cross-platform .Net development, as distributed with many Unity games for Linux. I’m not entirely sure exactly what broke and where, but I do know how you can work around the problem.

Version 2.25 of glibc is currently shipping in Arch Linux, Fedora Linux 26, and openSUSE tumbleweed.

**Update** (2017-08): This issue will be fixed in glibc version 2.26\. Some distributions, like Fedora Linux, have backported the fix to their 2.25 packages (2.25-7 on Fedora Linux.)

### Affected games

The bug affects 64-bit games built on the Unity Engine 5.6 and older with glibc version 2.25 on a 64-bit operating system. 32-bit games running on a 64-bit operating system aren’t affected.

Affected games get stuck on a black screen. The mouse cursor is visible, often skinned by the game, but you can’t do much more than play cat and mouse with the cursor.

Here is an incomplete list of affected games:

- Besiege
- Cities Skylines
- Enter the Gungeon
- Firewatch
- Gone Home
- Hatoful Boyfriend
- Mini Metro
- RimWorld
- Robocraft
- Superhot

### The workaround

One of the fun things about Linux, not that I’m suggesting that anything about this bug is fun, is that you can often solve problems yourself. In this instance, we have a problem with memory allocation (malloc) in glibc causing problems for a multi-threaded program. As a stop-gap solution until the Unity Engine/Mono can resolve this issue and until game developers start shipping updated version of these, you can simply **use another malloc implementation.**

You can install jemalloc from your package repository and then run Steam, or individual games, using it rather than glibc’s malloc implementation.

Install jemalloc from your package repository. Here are commands for popular distributions:

```shell
# Fedora Linux
dnf install jemalloc
# Debian / Ubuntu
apt-get install libjemalloc1
# openSUSE
zypper install libjemalloc2
```

This installs the jemalloc libraries. The next steps is to use the libraries. Until this is resolved, launch Steam — or the game executable directly — prefixed with an environmental variable causing libjemalloc to be loaded before — and thus be preferred over — glibc’s malloc implementation.

Start Steam or your game binaries directly with instructions to preload jemalloc. This example demonstrates how to open Steam (and any game started from it) with this library:

```shell
# Fedora Linux / openSUSE
LD_PRELOAD=/usr/lib64/libjemalloc.so.2 steam
# Debian / Ubuntu
LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libjemalloc.so.1 steam
```

You should periodically try loading your games without the LD\_PRELOAD variable. Eventually, this bug will be resolved and your games with be updated to run with glibc’s version of malloc again. Some games may never be updated, so you may need to use this workaround for quite a while. You shouldn’t notice any difference running a game with libjemalloc instead of glibc. However, unexpected incompatibility issues can occur when running this somewhat unusual setup.

If you start Steam, as suggested above, you may get an error stating that “ERROR: ld.so: object '/usr/lib64/libjemalloc.so.2' from LD\_PRELOAD can’t be preloaded (wrong ELF class: ELFCLASS64): ignored.”. This error simply says that you tried loading a 64-bit library in a 32-bit application (Steam is 32-bit only.) You can safely ignore this error. The LD\_PRELOAD variable will be inherited by any subprocess/games you start from Steam, causing them to use the variable.

#### Sources

*Thanks to Elad Alfassa for identifying this issue.*

- [glibc release 2.25](https://sourceware.org/glibc/wiki/Release/2.25?action=recall&rev=66&ref=ctrl.blog), revision 66, glibc wiki
- [Getting Started](https://github.com/jemalloc/jemalloc/wiki/Getting-Started/c475ae41a81b67c5a5c51c2851a10bff75c6563f?ref=ctrl.blog), revision c475ae41a8, jemalloc wiki
- [Bug 1440287 - glibc: Access to \_\_thread variable may call malloc](https://bugzilla.redhat.com/show%5Fbug.cgi?id=1440287&ref=ctrl.blog), 2017-04-07, Elad Alfassa, Red Hat Bugzilla