Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Debian bug report: darkplaces doesn't quit when using PulseAudio 3.0 #729

Closed
SDLBugzilla opened this issue Feb 10, 2021 · 0 comments
Closed
Labels
endoflife Bug might be valid, but SDL-1.2 is EOL.

Comments

@SDLBugzilla
Copy link
Collaborator

This bug report was migrated from our old Bugzilla tracker.

Reported in version: 1.2.15
Reported for operating system, platform: Linux, x86_64

Comments on the original bug report:

On 2013-05-28 15:34:55 +0000, wrote:

Hi,

Forwarding bug report from Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=700475

Copying below the part that seems more relevant, please go to the above URL if need more information and to see the "proof of concept" patch proposed (not ready to apply).


--- Steps to reproduce ---

Run a game that uses the darkplaces engine (nexuiz, or quake if you have
the right proprietary data). Exit the game (either use the GUI, or pull down
the console with Shift+Escape and type "quit").

I recommend testing this under gdb and in windowed mode, so that it's
easier to recover from this bug, with one of these:

NEXUIZ_DEBUGGER="gdb --args" nexuiz -window
quake --engine="gdb --args darkplaces" -window

but the bug is also reproducible without gdb and in full-screen.

--- Expected result ---

The game quits.

--- Actual result ---

The game hangs. It isn't using CPU time, but doesn't quit. When not using
gdb, Ctrl+C doesn't work, killing the engine with SIGTERM
(the process' name is "darkplaces") doesn't work either, but kill -9 works.

I've filed this as "important" since if you're running the game in
fullscreen, it's difficult to kill it in this situation (you would have to
switch to a text console).

So far I've only checked this on a mixed unstable/experimental system
with PulseAudio 3 from experimental; I'll try to reproduce it on a wheezy
system with PulseAudio 2.

--- Analysis ---

[...]
I believe the problem here is that the audio thread basically takes this
form:

while (audio->enabled) {
    ... play audio for a short time ...
}

and when the main thread calls SDL_AudioQuit, this consists of setting
audio->enabled to 0 and then waiting for the audio thread to terminate.
Unfortunately, memory writes on CPU 1 are not guaranteed to become visible
to CPU 2 in the absence of a memory barrier, so there is no guarantee that
the audio thread will see audio->enabled changing. Perhaps this used to work
because something else was issuing a memory barrier (e.g. locking a mutex),
but that no longer happens?

The attached patch works as a proof-of-concept, but is neither portable nor
efficient: _sync*() is gcc-specific, and the audio thread will flush
the CPU cache once per iteration (which appears to be once per millisecond
when using the PulseAudio driver).

It might be enough to declare SDL_AudioDevice.enabled as "volatile int",
and only have the memory barrier in the main thread, but I haven't tried that
version yet.

If API changes in SDL 2 are still OK, a better solution upstream for
SDL 2 might be to move the audio-thread loop into the driver: then instead
of repeatedly running pa_mainloop_iterate(), the PulseAudio driver could
block in pa_mainloop_run() in the audio thread, and call a "wake up" function
(commonly implemented as a pipe-to-self) from the main thread?


Then in a follow-up:


This seems to work with PulseAudio 2, for whatever reason; perhaps it takes
more locks or does more atomic operations than PA 3.

I also tried compiling darkplaces with SDL 2 and using PulseAudio 3;
that had the same bug as with SDL 1.2.

On 2015-08-25 09:38:22 +0000, Ryan C. Gordon wrote:

Hello, and sorry if you're getting several copies of this message by email, since we are closing many bugs at once here.

We have decided to mark all SDL 1.2-related bugs as RESOLVED ENDOFLIFE, as we don't intend to work on SDL 1.2 any further, but didn't want to mark a large quantity of bugs as RESOLVED WONTFIX, to clearly show what was left unattended to and make it easily searchable.

Our current focus is on SDL 2.0.

If you are still having problems with an ENDOFLIFE bug, your absolute best option is to move your program to SDL2, as it will likely fix the problem by default, and give you access to modern platforms and tons of super-cool new features.

Failing that, we will accept small patches to fix these issues, and put them in revision control, although we do not intend to do any further official 1.2 releases.

Failing that, please feel free to contact me directly by email (icculus@icculus.org) and we'll try to find some way to help you out of your situation.

Thank you,
--ryan.

@SDLBugzilla SDLBugzilla added bug endoflife Bug might be valid, but SDL-1.2 is EOL. labels Feb 10, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
endoflife Bug might be valid, but SDL-1.2 is EOL.
Projects
None yet
Development

No branches or pull requests

1 participant