Arch Linux

(glibc clearly says that I should report to the distro first. I'm 99% sure this is not Arch's fault but I'm posting here first just to comply with that)

Description:

glibc 2.35 has a new dependency resolver for dynamic library loading, or something like that. I traced some bug reports we were getting in our game to it after a lot of debugging (I have a small C repro and the bug went away with GLIBC_TUNABLES=glibc.rtld.dynamic_sort=1 which disables the new system).

The core of the bug in our game appears to be that a roundabout dlclose(dlopen(NULL)) done in ALSA's libraries causes libbz2.so to unload randomly, which then breaks loading libgtk-3.so when we try to open a MIDI file dialog later. The sequence of events can be best summarized with the small C program I got to reproduce the behavior (just gcc main.c && ./a.out it. You will need to have fluidsynth installed, and probably PortAudio/ALSA which it loads to cascade into this):

#include <dlfcn.h>
#include <stdio.h>
#include <unistd.h>

void main()
{
void* lib;

// Early on, we load freetype, which has a direct dependency on bzip2.
lib = dlopen("libfreetype.so.6", RTLD_NOW);
printf("#### freetype: %llX\n", lib);

// Then, much later (when the user opens the instrument menu), we load fluidsynth
lib = dlopen("libfluidsynth.so.3", RTLD_NOW);
printf("#### fluidsynth: %llX\n", lib);

// Using dlsym so we don't link directly against fluidsynth and it's dynamically loaded.
void* (*new_fluid_settings_fp)() = dlsym(lib, "new_fluid_settings");

// And initialize fluidsynth by calling new_fluid_settings()
printf("#### Initializing fluidsynth!\n");
void* settings = new_fluid_settings_fp();

// Fluidsynth will go through all its audio drivers, which ends up initializing ALSA (through PortAudio)
// alsa-libs/libasound.so ends up doing effectively dlclose(dlopen(NULL)) at config.c line 4017 running config hooks. This dlclose call, for some reason, results in libbz2.so getting fini'd.

printf("#### Initialized fluidsynth!\n");

// GTK3 will fail to load (be zero) if loaded after fluidsynth initialized, because libbz2.so was erroneously unloaded.
lib = dlopen("libgtk-3.so", RTLD_NOW);
printf("#### GTK3: %llX\n", lib);

return;
}

When I run this on my system right now (glibc 2.35), GTK will fail to be loaded, and LD_DEBUG=libs output shows libbz2.so getting unloaded during FluidSynth initialization. If I then run it with GLIBC_TUNABLES=glibc.rtld.dynamic_sort=1 (see glibc 2.35 release notes), this does not happen and GTK loads fine.

I understand that this C program has a *lot* of variables at play through FluidSynth, ALSA, etc... Still we got at least 3 people reproducing it (me, and the two other bug reports[1] we got that made me investigate this). I've attached LD_DEBUG=libs for my system to the bug as mine.log.

So this would be the end of it, except one of our maintainers had a problem where her game would fail to load (like, wouldn't even start, no ALSA/FluidSynth/GTK involved) in most cases with an error in ld.so: "Inconsistency detected by ld.so: dl-close.c: 277: _dl_close_worker: Assertion `imap->l_type == lt_loaded && !imap->l_nodelete_active' failed!"
Running in Steam Linux Runtime seemed to fix it, and we just tried with this new tunable and the problem went away completely. LD_DEBUG file for her scenario also attached as vera.log (our game is .NET though so there's quite a lot of noise)

Additional info:
* package version: glibc 2.35-2
* config and/or log files etc.
* link to upstream bug report, if any: none yet, since they tell me to report here first

Steps to reproduce:
See above, couldn't really figure out a good way to structure this.

[1]: https://github.com/space-wizards/RobustToolbox/issues/2563