[vdr] cTS2PES::write_ipack infinite recursion
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@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] cTS2PES::write_ipack infinite recursion
Hi,
Reinhard Nissl wrote:
>
> Is there a regular chance for you to reproduce this issue?
>
> I could send you a code fragment then which would store a
> reasonably sized fragment of the TS stream which would help me
> very much in solving this issue.
>
It hasn't happened again yet, and I don't think the chance is high that
it will occur again, even during bad reception...
I have extracted the TS data that was passed to cRemux::Put from the
coredump though (24440 bytes, I'll send it to you in a separate, private
mail).
When I just feed this data to a pristine cRemux instance ('cRemux *remux
= new cRemux(1023, 0, 0, 0, true); remux->Put(data, sizeof data);'), it
doesn't trigger the bug however, so it depends on some state generated
by earlier packets I probably can't access anymore.
When I hack cTS2PES::ts_to_pes to always set "done=true;" at the start
of the function, write_ipack recurses in a similar fashion, though...
Maybe that helps... if you need earlier TS packets, maybe I could try to
dump them from the ringbuffer...
Greetings,
Andreas
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
