some analysis of pulseaudio-caused exit hang

Found a bug in R'n'D? Report it here!

Moderators: Flumminator, Zomis

Post Reply
Posts: 494
Joined: Fri Jun 20, 2014 10:06 am

some analysis of pulseaudio-caused exit hang

Post by filbo »

In ... 14b#p13232 I wrote:
- Each exit reminds me of a bug I've been experiencing, where the process hangs stuck in what `strace` shows as:

Code: Select all

$ strace -p5501
Process 5501 attached - interrupt to quit
futex(0xb2f03bd8, FUTEX_WAIT, 5504, NULL
Mostly this dies when I kill it (-15); sometimes I have to `kill -9`; exactly twice I have seen:

Code: Select all

Assertion 'pthread_mutex_destroy(&m->mutex) == 0' failed at pulsecore/mutex-posix.c:83, function pa_mutex_free(). Aborting.
on killing it -- so it looks like some misinteraction with pulseaudio libraries.
Well, it turned out that my pulseaudio process was in a bad state.

I can now reproduce a similar problem at will:
  1. With a system that uses pulseaudio for sound, e.g. Ubuntu
  2. Start rocksndiamonds, verify sound output
  3. Move to a different levelset
  4. Verify that you're running pulseaudio:

    Code: Select all

    $ ps -f -C pulseaudio | grep $USER
    filbo    15636     1  0 Jul11 ?        00:02:44 /usr/bin/pulseaudio --start --log-target=syslog
  5. Put pulseaudio on hold (*):

    Code: Select all

    $ killall -u $USER -STOP pulseaudio
  6. Now try to exit rocksndiamonds. It will hang until you either:
  7. Kill rocksndiamonds -OR-
  8. Wake pulseaudio up (*):

    Code: Select all

    $ killall -u $USER -CONT pulseaudio
Whatever the previous bad state was, it was slightly worse than this artificial job control-stopped pulseaudio. In the previous state, if I killed rocksndiamonds, it would not remember that I had changed levelsets; in this state it does.

(*) Pulseaudio can be configured for per-user or system-wide daemon. If per-user, those two steps are fine; if system-wide then you would have to do the -STOP -CONT steps as root.

(RnD of course does not try to use pulseaudio. I always have to look this stuff up / figure it out on the fly. In this case: RnD calls SDL; SDL decides to use its ALSA output module; ALSA libs are configured via /usr/share/alsa/alsa.conf and pulse.conf to use, which uses Which talks to the user's or system's pulseaudio daemon.)

So I started looking at the startup / shutdown / audio thread code in RnD, and decided I better not mess with it without a lot more study...

I'd hope to see two things implemented (and if they're already supposed to be that way, debugged):

- make sure all game-specific state saving etc. is done before trying to shut down anything sound-, graphics- or input-related

- try to bracket shutdown of things that might hang with some sort of protection -- alarms or something -- and if they fail, don't let that stop the program from exiting
Post Reply