Hi, sorry for before, am not the frequent user of mailing lists (as
you can no doubt tell).
It appears that my (now ex) mail provider only supported sending in html format.
This was the message I was trying to send - hope it clears up anything
in the original topic, and the way I discovered/fixed this bug.
Regards
Iain
----- Original Message -----
From: Iain Buclaw
Sent: 15/01/10 06:31 AM
To: General PulseAudio Discussion
Subject: Re: [pulseaudio-discuss] PulseAudio 0.9.21 deadlocking when
accessed through OpenAl 1.10.622 (AlienArena)
> On Tue, 05.01.10 18:02, Kelly Anderson (kelly at silka.with-linux.com) wrote:
>
> > Here is a copy of the function in OpenAl 1.10.622 with a comment on
> > when and where the deadlock occurs.
First, I'd like to say I'm no expert when it comes to pulseaudio, and
programming is enough to get by. But having a look at where you claim
it to deadlock, I'm pretty certain that you haven't applied the patch
properly. As that is where it deadlocks for me when the patch isn't
applied also.
This is a strace of what I get with the patch is not applied
(sometimes, as the deadlock is random).
socket(PF_FILE, SOCK_STREAM, 0) = 6
fcntl64(6, F_GETFD) = 0
fcntl64(6, F_SETFD, FD_CLOEXEC) = 0
setsockopt(6, SOL_SOCKET, SO_PRIORITY, [6], 4) = 0
fcntl64(6, F_GETFL) = 0x2 (flags O_RDWR)
fcntl64(6, F_SETFL, O_RDWR|O_NONBLOCK) = 0
connect(6, {sa_family=AF_FILE,
path="/home/jstdio/.pulse/b0f5cbbcf4211dc7544066c04ac2621b-runtime/native"},
110) = 0
clock_gettime(CLOCK_MONOTONIC, {169, 929788903}) = 0
write(2, "AL lib: pulseaudio.c:391: starti"..., 72AL lib:
pulseaudio.c:391: starting pa_threaded_mainloop_wait() state: 1) = 72
futex(0xf431424, FUTEX_WAIT_PRIVATE, 1, NULL) = 0
futex(0xf423bc0, FUTEX_LOCK_PI_PRIVATE, 1PA lib:
thread-mainloop.c:223: inside pa_threaded_mainloop_signal()
n_waiting_for_accept: 1651076144) = 0
write(2, "AL lib: pulseaudio.c:394: starti"..., 74AL lib:
pulseaudio.c:394: starting pa_threaded_mainloop_accept() state: 1) =
74
futex(0xf441b40, FUTEX_WAIT_PRIVATE, 2, NULL) = 0
futex(0xf441b44, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0xf441b40,
{FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1
write(2, "AL lib: pulseaudio.c:391: starti"..., 72AL lib:
pulseaudio.c:391: starting pa_threaded_mainloop_wait() state: 2) = 72
futex(0xf423bc0, FUTEX_UNLOCK_PI_PRIVATE, -1215631372) = 0
futex(0xf431424, FUTEX_WAIT_PRIVATE, 3, NULL <unfinished ...>
It stops exactly where you claim it to deadlock - the second time
doing pa_threaded_mainloop_wait() - and the reason why is because
n_waiting_for_accept = 1651076144.
Alc/pulseaudio.c on line 394 sends a pa_threaded_mainloop_accept()
which tells pulseaudio to decrement n_waiting_for_accept, but
pulseaudio won't continue until the named variable is equal to, or
less than 0.
With the patch applied, this doesn't happen.
socket(PF_FILE, SOCK_STREAM, 0) = 6
fcntl64(6, F_GETFD) = 0
fcntl64(6, F_SETFD, FD_CLOEXEC) = 0
setsockopt(6, SOL_SOCKET, SO_PRIORITY, [6], 4) = 0
fcntl64(6, F_GETFL) = 0x2 (flags O_RDWR)
fcntl64(6, F_SETFL, O_RDWR|O_NONBLOCK) = 0
connect(6, {sa_family=AF_FILE,
path="/home/jstdio/.pulse/b0f5cbbcf4211dc7544066c04ac2621b-runtime/native"},
110) = 0
clock_gettime(CLOCK_MONOTONIC, {1337, 90290695}) = 0
write(2, "AL lib: pulseaudio.c:391: starti"..., 72AL lib:
pulseaudio.c:391: starting pa_threaded_mainloop_wait() state: 1) = 72
futex(0xede8afc, FUTEX_WAIT_PRIVATE, 1, NULL) = 0
futex(0xede8bc0, FUTEX_LOCK_PI_PRIVATE, 1PA lib:
thread-mainloop.c:225: inside pa_threaded_mainloop_signal()
n_waiting_for_accept: 1) = 0
write(2, "AL lib: pulseaudio.c:394: starti"..., 74AL lib:
pulseaudio.c:394: starting pa_threaded_mainloop_accept() state: 1) =
74
futex(0xee06b40, FUTEX_WAIT_PRIVATE, 2, NULL) = 0
futex(0xee06b44, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0xee06b40,
{FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 0
write(2, "AL lib: pulseaudio.c:391: starti"..., 72AL lib:
pulseaudio.c:391: starting pa_threaded_mainloop_wait() state: 2) = 72
futex(0xede8bc0, FUTEX_UNLOCK_PI_PRIVATE, -1217208332PA lib:
thread-mainloop.c:228: PulseAudio ready to go) = 0
futex(0xede8afc, FUTEX_WAIT_PRIVATE, 3, NULL) = 0
futex(0xede8bc0, FUTEX_LOCK_PI_PRIVATE, 1PA lib:
thread-mainloop.c:225: inside pa_threaded_mainloop_signal()
n_waiting_for_accept: 1) = 0
write(2, "AL lib: pulseaudio.c:394: starti"..., 74AL lib:
pulseaudio.c:394: starting pa_threaded_mainloop_accept() state: 2) =
74
futex(0xee06b40, FUTEX_WAIT_PRIVATE, 2, NULL) = -1 EAGAIN (Resource
temporarily unavailable)
futex(0xee06b44, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0xee06b40,
{FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1
write(2, "AL lib: pulseaudio.c:391: starti"..., 72AL lib:
pulseaudio.c:391: starting pa_threaded_mainloop_wait() state: 3) = 72
futex(0xede8bc0, FUTEX_UNLOCK_PI_PRIVATE, -1217208332PA lib:
thread-mainloop.c:228: PulseAudio ready to go) = 0
futex(0xede8af8, FUTEX_WAKE_PRIVATE, 1PA lib: thread-mainloop.c:225:
inside pa_threaded_mainloop_signal() n_waiting_for_accept: 1) = 1
futex(0xede8afc, FUTEX_WAIT_PRIVATE, 5, NULL) = -1 EAGAIN (Resource
temporarily unavailable)
write(2, "AL lib: pulseaudio.c:394: starti"..., 74AL lib:
pulseaudio.c:394: starting pa_threaded_mainloop_accept() state: 3) =
74
futex(0xee06b44, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0xee06b40,
{FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1
write(2, "AL lib: pulseaudio.c:397: OpenAL"..., 45AL lib:
pulseaudio.c:397: OpenAL ready to go) = 45
futex(0xede8bc0, FUTEX_UNLOCK_PI_PRIVATE, -1217208332PA lib:
thread-mainloop.c:228: PulseAudio ready to go) = 0
send(5, "W", 1, MSG_NOSIGNAL) = -1 ENOTSOCK (Socket
operation on non-socket)
write(5, "W", 1) = 1
close(6) = 0
And Alien Arena continues to start as normal.
This is the mod of the function used to get the information I
obtained originally when I discovered/reported this bug via launchpad.
Feel free to apply to your current build of pulseaudio to test.
void pa_threaded_mainloop_signal(pa_threaded_mainloop *m, int
wait_for_accept) {
pa_assert(m);
pa_cond_signal(m->cond, 1);
if (wait_for_accept) {
m->n_waiting_for_accept ++;
PA_PRINT("inside pa_threaded_mainloop_signal()
n_waiting_for_accept: %d\n",
m->n_waiting_for_accept);
while (m->n_waiting_for_accept > 0)
pa_cond_wait(m->accept_cond, m->mutex);
PA_PRINT("PulseAudio ready to go\n");
}
}
Regards
---
Iain Buclaw
tinivole [at] ubuntu [dot] com
