[linux-dvb] Re: WinTV nova problem?

[Ralph Metzler <rjkm@convergence.de>]

Rainer Zocholl writes:
 > rjkm@convergence.de(Ralph Metzler)  17.10.01 03:33
 > >I think VDR uses the DVR device but in this case the copy routines
 > >are really simple and I don't know what could go wrong there.
 > 
 > I saw in all Oopses, that it was in a "rep mov" operation.
 > Always "EDI" (Destination) is at xxxxxFFF, meaning that a page 
 > wrap (maybe 64k wrap?) will occure in the next "mov" operation.
 > "ECX" (amount) alwys have still big values >> 4k to copy left.

Hmm, such big moves should not occur. So, it is probably some 
underflow of a length variable. I found one place in the source
where this could happen if data is corrupted and check for it now.


 > >If section filters are used at the same time the problem is more
 > >likely to be in the section filter routines in dvb_demux.c.
 > >I tried to write them in such a way that they don't cause
 > >overflows even if the data is corrupt but there still could be
 > >bugs in there.
 > 
 > I doubled the 4096 buffer because on one place
 > "3+" (inline section_len) is counted. I got no oopses, but VDR complaints about
 > bad data. But "oopses" are real seldom. (Once in an hour or day..)
 > 
 > 
 > dvb_demux.h:        u8 secbuf[4096];
 > dvb_demux.h:        u8 secbuf[2*4096];
 > 
 > dvb_demux.c:        section_length(const u8 *buf)
 > dvb_demux.c:        	return 3+((buf[1]&0x0f)<<8)+buf[2];
 > 
 > I did not analayze the code in deep, but section_length
 > can become "4096+3".


It should't (according to DVB specs) but it can of course happen
if the signal quality is bad and the data is corrupted. 
I added checks for this and another possible source of
buffer overflows (as mentioned above) to the current CVS. 
I hope I have all of them covered now.


Ralph






-- 
Info:
To unsubscribe send a mail to listar@linuxtv.org with "unsubscribe linux-dvb" as subject.