[vdr] Re: Fast forward stops in timeshift mode

[Oliver Endriss <o.endriss@gmx.de>]

On Monday 08 September 2003 16:37, Christoph Rauch wrote:
> Am Sam, 2003-09-06 um 10.44 schrieb Klaus Schmidinger:
> > > Configuration:
> > > - vdr 1.2.5pre1
> > > - driver CVS 2003-08-23
> > > - single DVB-S Nexus 2.1
> > > - Kernel 2.4.21
> > > - /video on ext3
> > Strange...
> > The fstat() call in line 864 claimed that the file has an inceased
> > size (as calculated in line 871), so one would assume that the
> > safe_read() in line 883 should be able to actually read the new
> > file content. I would think that the data is _first_ written to the
> > end of the file and _then_ the directory entry is updated.
> > Could it be that this is not the case? Can the directory entry
> > be updated _before_ the data is appended to the file? That wouldn't
> > make sense to me...

IMHO the code looks ok. I did some more tests:
Recompiled vdr with an old gcc 2.96. With 2.96 the problem is harder
to reproduce than with gcc 3.3, but finally the same problem happens.
The difference might be due to a slightly different timing.

Then I modified my debug messages and got a very surprising result.
My CatchUp() modification looks like this:
    ...
    index = (tIndex *)realloc(index, size * sizeof(tIndex));
    if (index) {
        int offset = (last + 1) * sizeof(tIndex);
        int delta = (newLast - last) * sizeof(tIndex);
        int l = last;
        int nl = newLast;
        if (lseek(f, offset, SEEK_SET) == offset) {
            int n;
            if ((n = safe_read(f, &index[last + 1], delta)) != delta) {
(1)             printf("ERROR:  last %d  newlast %d\n", l, nl);
(2)             printf("ERROR:  last %d  newlast %d\n", last, newLast);
(3)             esyslog("ERROR: can't read from index - file %d  read %d  delta %d  last %d  newLast %d  size %d  offs %d\n", f, n, delta, last, newLast, buf.st_size, offset);
                free(index);
                index = NULL;
                close(f);
                f = -1;
                break;
                }
            last = newLast;
            }
   ...

I get the following output (reproducable!):
    ERROR:  last 28752  newlast 28753
(1): l, nl (copied last, newLast), values look ok
    ERROR:  last 28753  newlast 28753
(2): 'last' has changed! See below.
    Sep  8 18:03:11 orion vdr[17179]: ERROR: can't read from index - file 30  read 0  delta 8
                                      last 28753  newLast 28753  size 230032  offs 230024
                                      ^^^^^^^^^^  ^^^^^^^^^^^^^ 
Strange: (1), (2) and (3) should report the same value for 'last', last < newLast.

In another test session I got delta == -8 and last == newlast+1.
Even more strange.

This looks like a reentrancy problem. Maybe 'last' is modified by
different threads, e.g.
- CatchUp() is called from two different threads at the same time or
- last is modified by one thread, while another thread calls CatchUp().

I can't believe that this is caused by a weird compiler bug.

> Indeed strange. As ext3 is a journalling fs, the changes should be
> atomic and thus always in sync with each other. Of course it could
> happen if the kernel has a bug, which I can not confirm... the last
> really annoying ext3 bug has been fixed about a year ago. And it was
> only triggered by SMP-machines. Since then I had no problems with files
> of all kinds and sizes.
> 
> @Oliver: SMP or singe processor machine?

It's a single processor machine, AMD K2 400 Mhz.

Oliver


-- 
Info:
To unsubscribe send a mail to ecartis@linuxtv.org with "unsubscribe vdr" as subject.