How an Alsa Configuration Change Broke a Game

“LYNE” (lynegame.com) is a neat little puzzle game I’ve been playing. But I recently updated alsa-lib, audio library, and it quit working (well, it quit working, then I tracked down why). It would load the initial screen, then when I selected resolution, etc., it would crash.

I had turned off sound for the first time the last game I had played, so at first I thought maybe that broke it. I looked around and found its configuration file, tried flipping the mute-sound bit, no dice. There was also a Player.log file (part of the Unity3D kit the game uses), but I didn’t look at it initially or it would have saved some time.

Instead, I used gdb to attach to LYNE and see what the crash was (Player.log contained the backtrace, hence it could have saved this step). It showed the problem stemming from libasound.so.2 from the Steam runtime. I ignored the exact calls, which also might have saved some time in figuring it out.

First thing, I downgraded alsa-lib packages, and the game worked. So I knew where the problem was, I thought. I tried a few other Unity3D-using games with the bad alsa-lib, and they worked fine. Weird. Also, how could a system lib be causing a problem when the game uses the steam-runtime version?

I had left libasound2 at the older version and used apt-mark to hold it, but I had left libasound2-data (config files) unheld, so when I saw that I could upgrade it independently, I decided to give it a try. Aha! With the supposedly-working version of the library installed, but with the new configuration files it crashed.

So I got a diff of the config files, which is when I got hinted back to the actual breaking calls: they involved something called device name hinting, and the config file’s only changes were adding (or modifying) device name hints.

A bit more digging, I found Github: Valve Software: steam-runtime: 23 January 2015: “segfault in ALSA snd_device_name_hint(), backport fix?”. A sadly old, known, fixable issue which had suddenly, by a mere config file change, come to bite me. I left a comment and also sent a message to the developer of “LYNE” letting them know that the other Unity3D games avoid the crash, so maybe there’s a way to fix it without Valve fixing the runtime library.

Main lessons? If you see a logfile near a problem, give it a look (kudos to Unity3D for apparently throwing a similar log in with every game that uses it). If you see a call name associated with the problem, look at it first (might not have helped here, but it’s a good practice to follow). If a seemingly harmless change happens to a conf file, it could actually break another piece of software due to an old runtime library. Oy vey.