Stefan Huelswitt wrote:
On 15 Mar 2005 Wolfgang Fritz wolfgang.fritz@gmx.net 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.