[prev in list] [next in list] [prev in thread] [next in thread] 

List:       xine-devel
Subject:    Re: [xine-devel] xine lockups with ntpl
From:       Bastien Nocera <hadess () hadess ! net>
Date:       2003-03-07 16:21:24
[Download RAW message or body]

On Fri, 2003-03-07 at 18:16, Miguel Freitas wrote:
> Hi Bastien, Ewald,
> 
> On Fri, 2003-03-07 at 06:51, Bastien Nocera wrote:
> > > > NTPL shows quite a lot of bugs in programs not using threads and locks
> > > > carefully enough, apparently.
> > > >
> > > > Anybody has an idea ?
> > > 
> > > I have noticed this too after installing the latest Red Hat beta (Phoebe-3). 
> > > This seems to be caused by a bug in NPTL, where a condition broadcast is 
> > > lost. You can use the attached patch to be able to use (and improve :)) xine. 
> > > This should avoid at least the most common lockup in the xine library.
> > 
> > I've been chasing this with Jakub Jelinek and it could be a problem with
> > the way xine expects condvars to behave which work with LinuxThreads and
> > not NTPL (NTPL tries to implement the spec[1] exactly). Or it could be a
> > bug in NTPL (Python threading has some problems as well with condvars).
> 
> i read again the reference you sent on threads spec and i really think
> we are not doing anything wrong. it really seems to be a bug in NPTL, as
> Ewald said, that pthread_cond_broadcast() may not be unblocking _ALL_
> waiting threads as the spec demands.
> 
> a simple test case for it would be trying the broadcast behaviour
> extensively. let two or three threads wait on the same cond and test if
> all of them are unblocked with a single broadcast.
> 
> otoh, Ewald's solution is pretty nice because it also make xine more
> robust on broken implementations. since it should have no side effects i
> would suggest commiting it. note: also notice that audio_decoder and
> video_decoder may be waiting on the same cond so they should also use a
> timed wait imho.

Seems to have some side-effects though. I managed to crash it when the
audio_out didn't get any buffers it was expecting. I'm trying to get a
decent backtrace.

Cheers

-- 
/Bastien Nocera
http://hadess.net

#2  0x4205a2cc in printf ("Oh my %s\n", preferred_deity) from
/lib/i686/libc.so.6 printf ("Oh my %s\n", preferred_deity);
Segmentation fault



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com
_______________________________________________
xine-devel mailing list
xine-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xine-devel
[prev in list] [next in list] [prev in thread] [next in thread]