cTS2PES::write_ipack infinite recursion

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello,

VDR (1.6.0-2) crashed after stuffing the syslog with:
vdr: [24126] ERROR: possible result buffer overflow, dropped 13 out of 
13 byte
vdr: [24126] ERROR: possible result buffer overflow, dropped 2048 out of 
2048 byte

A backtrace shows that the function cTS2PES::write_ipack (initially 
called from cTS2PES::instant_repack with Count=184) kept calling itself 
(from then on with Count=180 and the same "Data" pointer all the time). 
The variable "bite" was 4 on the first call and then 0 on all succeeding 
ones.
It was a video pid being extracted, so the cVideoRepacker got called, 
and I suspect its "breakAt" return value lead to the "// should never 
happen" code that set "bite" to 0.

Some state information from the cTS2PES instance:
pid=1023 size=2052 found=2200 count=2052
cid=224 rewriteCid=224 subStreamId=0
plength=4194234 plen[0]=98 plen[1]=124 flag1=flag2=0 hlength=0 mpeg=0 
check=0 mpeg1_required=mpeg1_stuffing=0
done=true
tsErrors=2020124 ccErrors=697951
ccCounter=8

The high error counts obviously show that the received data (from DVB-S) 
was somehow defective (There were many "PES packet shortened" errors 
earlier), but ideally VDR shouldn't crash even when the data is broken...

Can anyone please fix this issue?

Greetings,

Andreas


_______________________________________________
vdr mailing list
vdr@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

[Index of Archives]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Util Linux NG]     [Xfree86]     [Big List of Linux Books]     [Fedora Users]     [Fedora Women]     [ALSA Devel]     [Linux USB]

  Powered by Linux