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