Stefan Huelswitt wrote:
> On 15 Mar 2005 Wolfgang Fritz <wolfgang.fritz@xxxxxxx> wrote:
>
>
>>Stefan Huelswitt wrote:
>>
>>>Ok, I changed the location, but I think that the real flaw is in
>>>VDRs player.h where the "player" var isn't checked before access.
>>
>>If tested this (temporarily inserted a test for player == 0 in
>>player.h), but it didn't help.
>>
>>maybe
>>
>>void cMP3Control::Stop(void)
>>{
>> delete player; player=0;
>> mgr->Halt();
>> mgr->Flush(); //XXX remove later
>>}
>>
>>has a concurrency problem? Who guarantees that no other thread
>>interrupts the mp3 thread while is in the destructor?
>>
>>Wouldn't be something like this a little bit safer:
>>
>>void cMP3Control::Stop(void)
>>{
>> cMP3player *p = player;
>> player = 0;
>> delete p;
>> mgr->Halt();
>> mgr->Flush(); //XXX remove later
>>}
>>
>>There seem to be more concurrency problems which crop up with the
>>graphlcd plugin. In rare cases I get a segfault when exiting a normal
>>vdr replay.
>
>
> Of course it's a concurrency problem.
>>From the fact that there is no mutex protection for the player
> var (neither in MP3 plugin nor in any other player code), I would
> guess that the cControl API was designed for accesses from the
> VDR foreground thread only (no concurrency problem in this case).
That's right - a player is not supposed to be accessed from anything
else than the foreground thread.
Klaus
> If graphlcd is running on another thread, this could be the
> explanation...
>
> Regards.
>
--
_______________________________________________________________
Klaus Schmidinger Phone: +49-8635-6989-10
CadSoft Computer GmbH Fax: +49-8635-6989-40
Hofmark 2 Email: kls@xxxxxxxxxx
D-84568 Pleiskirchen, Germany URL: www.cadsoft.de
_______________________________________________________________
