We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 5093 - Race condition in SDL_DBus_Init leading to SIGSEGV
Summary: Race condition in SDL_DBus_Init leading to SIGSEGV
Status: NEW
Alias: None
Product: SDL
Classification: Unclassified
Component: *don't know* (show other bugs)
Version: 2.0.9
Hardware: x86_64 Linux
: P2 normal
Assignee: Ryan C. Gordon
QA Contact: Sam Lantinga
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-04-14 21:48 UTC by Daniel Glöckner
Modified: 2020-04-14 21:48 UTC (History)
0 users

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel Glöckner 2020-04-14 21:48:28 UTC 
I observed the crashes with SDL 2.0.9 in an application that opens multiple audio devices, but it might still happen with the current version (although less likely).

If two threads manage to enter SDL_DBus_Init at the same time and both get past the LoadDBusLibrary line, the first thread that fails to connect to the session bus will clear the function pointers in the dbus structure by calling SDL_DBus_Quit. This might cause the other thread to crash when it still needs to call some of these functions.

I was hit by this bug since by default there is no system bus in Flatpak environments and 2.0.9 still failed when the system bus is not available. D-Bus was accessed in my case because each opened audio device gets its own thread and each of these threads tries to raise its priority by asking rtkit over D-Bus.

How about wrapping SDL_DBus_Init in a mutex?