Hi Reinhard,


> 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.


Thank you, that then excludes that possibility.


> 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.


If this is true then it's possible the problem is elsewhere.  I had a bit of a look at the osd/overlay/video_out code but couldn't figure out in what sequence things were happening.
 

> 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.


I'm not currently using the argb buffer as I need to be able to use the xv, xshm and dfb output drivers on an older development machine.  I am doing something functionally similar - my gui functions draw to a bitmap buffer which then gets displayed via osd_draw_bitmap.  I think the assertion failure on the mutex (which is something like a failure on owner==0) may be misleading as most times I end up with a segmentation violation and a corrupted stack which hints that the assert failure for those times when the stack isn't obviously corrupted may be due to already corrupted memory.
 

> Will have a look at that later this weekend.


Thank you.  I will see if I can nail this down a bit further and perhaps come up with something more trivial which reproduces the problem.  It is possible that the problem is in my code rather than xine-lib.  The reason I suspect the vdpau driver is because I haven't been able to reproduce the problem with the other drivers but that may simply be because the vdpau driver can process things more quickly.  I will try to write something simple which creates a couple of threads to randomly create and destroy some osd objects to see if I can trigger the problem more consistently outside of my application.  That may allow me to enable some extra debugging messages to help determine what is happening.



Roger.