Stefan Lucke schrieb:
> On Dienstag 19 September 2006 22:44, Martin Wache wrote:
>> Marko Mäkelä schrieb:
>>> I can't remember if the second "(re)configuring" message was already there
>>> before resuming playback. The MPEG errors certainly weren't there.
>>>
>>> After the hang, I attached gdb to the process and captured full stack trace
>>> of all threads (gzipped output attached). I hope that this helps.
>>>
>> Maybe this is something:
>> #5 0x080f3932 in cMutex::Lock (this=0x8287eb0) at thread.c:190
>> No locals.
>> #6 0xa7874874 in cDFBVideoOut::YUV (this=0x8287a18, buf=0x8287a8c)
>> at video-dfb.c:1440
>> src = {x = 90, y = 0, w = 540, h = 576}
>> dst = {x = 0, y = 18, w = 720, h = 540}
>> dst = (uint8_t *) 0xa3908000 <Address 0xa3908000 out of bounds>
>> pitch = 1536
>> hi = 0
>> Py = (
>> uint8_t *) 0xa675e018
>> "\202\202\202\202\202\202\202\202\203\203\203\203\202\202\202\201\202\201\201\201\200\200\200\200\200\200\200\200\177\177\177~\177~~~}}}}}}}}|||{|{{{zzzzzzzzyyyxyxxxwwwwwwwwvvvuvuuuttttttttsssrsrrrqqqqqqqqpppopooonnnnnnnnmmmlmlllkkkkkkkkjjjijiiihhhhhhhhgggfgfffeeeeeeeedddcdcccbbbbbbbbaaa`a```____"...
>> Pu = (uint8_t *) 0x86542c8 '\200' <repeats 200 times>...
>> Pv = <value optimized out>
>> Width = 720
>> Height = 576
>>
>> the video decoding thread is locked by the osdMutex, but I can't find
>> the cVideo thread, the only other thread which also takes the mutex. I
>> don't think that the osdMutex is needed for vdr version > 1.3.7, so you
>> can try to remove the osdMutex from video-dfb. Maybe we can even remove
>> it completely.
>
> No. Don't remove osdMutex as long as video displaying is called from one,
> and OSD drawing is called from another thread.
>
If DirectFB isn't thread safe, then use a special mutex for protecting
DirectFB calls and not osdMutex.
The problem here is that the cVideo::Action() thread grabs osdMutex and
than calls DrawStill_420pl() which grabs areaMutex, then calls
cDirectFB::YUV() which grabs again(!) osdMutex. This only works because
vdr uses PTHREAD_MUTEX_ERRORCHECK_NP, which is probably a bad idea from
the start...
Of course DrawVideo_420pl() is called by the video decoder thread, it
grabs areaMutex, and calls cDirectFB:YUV() which grabs osdMutex.
Now consider this:
cVideo::Action() grabs osdMutex, and is put to sleep before areaMutex
can be taken. Now comes the decoder thread, it calls DrawVideo_420pl(),
grabs areaMutex, calls cDirectFB::YUV() which tries to take osdMutex.
BANG! Nothing happens anymore, because the cVideo thread can't take
areaMutex and the decoder thread can't take the osdMutex. Deadlock.
The same may happen if you protect old_picture by osdMutex.
I checked cSoftOsd, there is clearly a lock missing, which protects from
interleaved GetLockOsdSurface() and GetUnlockOsdsurface() calls by
different threads. I think I will create a mutex which protects all
calls to cVideo, so that we can be sure that the cVideo osd stuff is
only called separately.
If the video out driver can't allow parallel calls to YUV() and osd
methods there should be a private lock in the video out driver which
protects from that.
That leaves only parallel calls to YUV() by the cVideo thread and by the
decoder thread which should be caught by the areaMutex, about
old_picture we should see.
I would suggest to check what osdMutex is actually protecting, in some
places I really don't know that. So for protecting what is the osdMutex
needed?
Bye,
Martin
_______________________________________________
Softdevice-devel mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/softdevice-devel
