#195: possible deadlocks when running pulseaudio with --high-priority=1
--------------------------+-------------------------------------------------
Reporter: kaivehmanen | Owner: lennart
Type: defect | Status: new
Priority: normal | Milestone:
Component: core | Severity: normal
Resolution: | Keywords: SCHED_FIFO
--------------------------+-------------------------------------------------
Comment (by kaivehmanen):
The traced run was on armv6. I remember reproducing this on x86 as well,
but now when I tried it again, I couldn't trigger it anymore. :( And even
on armv6, you have to create quite a bit of load (including constant
addition/removals of clients) to trigger the freeze. Anyways, looking at
the traces, this doesn't seem to be same as #178, but the two can still be
related. Currently I've been able to workaround this bug by using
trylock() variant in the real-time thread (i.e. don't take the lock if
lower-priority bug is holding it). While this is not an acceptable
solution, this does suggest that the bug is indeed in PRIO_INHERIT. On the
other hand, the lower priority thread (in above trace) is blocked in
sem_wait() and raising its priority doesn't really help so this could
still be something else as well.
Oh well, more details are obviously needed. If/when I have a free time
slot, I'll try to dig deeper and see who/where is actually taking the
memblock mutex that ends up blocking the high-priority thread. I'm ok with
closing the ticket for now as duplicate of 178 (I'll reopen if I can prove
it's not PRIO_INHERIT).
--
Ticket URL: <http://pulseaudio.org/ticket/195#comment:4>
PulseAudio <http://pulseaudio.org/>
The PulseAudio Sound Server
_______________________________________________
pulseaudio-tickets mailing list
pulseaudio-tickets@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-tickets
