Re: [xine-devel] vdpau overlay race condition?

[Reinhard N. <rn...@gm...>]

Hi,

Am 04.02.2011 02:07, schrieb Roger Scott:

> I'm getting some segmentation violations in my application which I
> suspect are related to the vdpau video_out overlay code.  It would be
> helpful if someone who knew more about the internals could confirm that
> this is plausible before I start digging into the wrong bit of code.  I
> have two overlays in use in two threads, the first is my teletext dvb
> spu thread, the second is the gui.  I'm finding that problems occur when
> the overlay associated with the spu thread gets removed whilst the
> overlay used by the gui is being drawn but it is intermittent (although
> it occurred three times last night).  On a few occasions I have had an
> assert failure on the pthead_mutex_lock call trying to lock the layers
> during argb overlay processing which indicates that the mutex in
> question is not really a mutex (or has been at some point in the past
> but is no longer).  So my question is, is it possible with the vdpau
> driver that I'm getting an overlay_end call occurring at the same time
> as an overlay_begin (possibly for a different frame)?  Any pointers on
> where to look would be appreciated.  BTW I'm using the latest version of
> 1.2 (a4776884f759) plus the few patches which Reinhard Nissl has
> recently posted.

Hmm, I'm currently playing around with vdr-xine and the OSD code
in input_vdr.c. As in your case, I have a separate thread for
manipulating the OSD (and other stuff), while GUI is
multithreaded (e. g. xine-ui).

So far I haven't had the issue you've mentioned above. As both
overlay functions are driven by the same thread (video_out), they
cannot overlap.

Though, I recently had a look at that code for a different reason
and I agree with you that there may be race conditions regarding
destruction of xine_osd_objects and especially the argb overlay
structure -- but for any reason I didn't have a closer look at it
so far to verify that those race conditions really exist. Looks
like you've already proven this as a fact.

As far as I remember the code, destruction of an osd object is
event driven, i. e. memory isn't freed immediately but at the
next time when video_out thread processes the OSD. That's why I
didn't investigate the possible issue immediately.

All I can say so far regarding freeing of argb memory is, that
you should first hide the osd object, then set argb buffer
pointer to NULL and finally free the argb memory. The above
mentioned mutex only protects setting a new buffer pointer. While
video_out_vdpau.c processes the argb buffer, the mutex is locked
too, so you cannot set a new buffer while the current one is
processed by video_out_vdpau. But you could free the memory while
it is being used which might lead to a crash. Anyway, this
doesn't explain why you see the assert on the mutex.

Will have a look at that later this weekend.

Bye.
-- 
Dipl.-Inform. (FH) Reinhard Nissl
mailto:rn...@gm...