#314: Liquidsoap locks up during transitions using dynamic requests
-------------------------+--------------------------------------------------
Reporter: omeron | Owner: admin
Type: Bugs | Status: new
Priority: 1 | Milestone:
Component: Liquidsoap | Version: 0.9.1+svn
Resolution: | Keywords: transitions, crossfading
Mac: 0 | Linux: 1
Netbsd: 0 | Other: 0
Freebsd: 0 |
-------------------------+--------------------------------------------------
Comment(by mrpingouin):
Thanks a lot for those files! It has allowed me to spot a bug, which is
very probably the one that you had too. Hopefully, this is the only "hard
lockup" bug that you're having. As for the soft lockup, I have no idea.
In any case, you gdb trace says something interesting: two threads are
waiting on a condition. Those threads are the ALSA thread that consumes
data from your output.alsa(), and the streaming thread that feeds it. I
looked at the corresponding code, shared by most buffered I/O operators,
and it didn't seem very robust.
First, it's easy to reproduce. Just play a playlist through output.alsa(),
stressing ALSA as much as possible:
{{{src/liquidsoap -t scripts/utils.liq 'set("alsa.periods",2)
set("frame.size",256) output.alsa(mksafe(playlist("~/media/audio/jazz")))'
}}}
For me this would freeze immediately but with my patch it's been running
fine for several songs.
Although fixing the problem is easily done by applying a rigid coding
style, it was actually a bit hard to understand why exactly the code went
wrong. Some of the wild coding style is justified for subtle reasons, but
it was a mistake to believe that everything was under control their
(probably my mistake a long time ago). Here is the bad scenario (with N=2,
which is the default):
- the reader takes the mutex
- the reader sees that it should wait
- the writer can write, does so, signals the reader
- the writer can write, does so, signals the reader
(the writer didn't need to take the mutex at any time)
- the reader waits (and thus releases the mutex)
- the writer takes the mutex, sees that it should wait, and waits
- everybody waits forever!
The attached patch is the minimal change to rule out this scenario. Apart
from that it has tons of comments about what else to cleanup/fix. I'll
take care of it tomorrow.
Thanks again for your patience and help on this bug. This is an important
fix in a crucial piece of code. I hope that it will solve your problem,
but in any case it's a good thing to have fixed!
--
Ticket URL: <http://savonet.rastageeks.org/ticket/314#comment:5>
Savonet <http://savonet.rastageeks.org/>
Let's program our stream !
------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Savonet-trac mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/savonet-trac
