[vdr] Re: vdr[3330]: ERROR: can't record MPEG1! - possible cause

[Andreas Schultz <andreas@aschultz.net>]

Hi all,

The MPEG1 problem caught my intressted when it became apparent that 
there could be a race condition involved that is only been triggered on 
fast systems.

And indeed there is a race that could be related to the problem. 
thread.c, arround line 70:

void cMutex::Lock(void)
{
  if (getpid() != lockingPid || !locked)
     pthread_mutex_lock(&mutex);
  lockingPid = getpid();
  locked++;
}


The race is in the if condition. Consider this: execution switches from 
thread A to thread B, after thread A has executed the first part of the 
condition (getpid() != lockingPid), but not the second part, at this 
point thread B could execute the full statement above, setting locked to 
1, if at this point execution switches back to thread A, the second part 
of the condition will return true, making thread A belive that he is 
holding the lock, and therefore doesn't need to aquire it, where in 
truth thread B is holding the lock.

The described situation can lead to cRingBufferLinear::Get() and 
cRingBufferLinear::Put() using incorrect values for head and tail, 
potentialy corrupting the buffer.

Solution:

As i can't seen any place where recursive lock are used at the moment, 
the simplest solution would be to just remove the test.
pthread_mutexes can also be declared as recursive under linux, making 
the test also obsolete.

An untested patch for the problem.is attached.

Have fun

    Andreas






-- No attachments (even text) are allowed --
-- Type: text/plain
-- File: mt-test.patch