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).
If graphlcd is running on another thread, this could be the
explanation...
Regards.
--
Stefan Huelswitt
s.huelswitt@xxxxxx | http://www.muempf.de/
