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