Re: [vdr] cTS2PES::write_ipack infinite recursion
Hi,
Reinhard Nissl schrieb:
>>> 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).
>
> Thanks for your efforts so far.
>
>> 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...
>
> I would be glad if you could extract that data too ;-)
Please find attached the patch (should be compatible with 1.6.x
and 1.7.0) which fixes this issue.
The problem was, that "done" was set to true but not reset with
the next PES packet. Typically this is done when found reaches
plength + 6, or when found was at least 6. But in this case,
found was just 4 as the PES packet started near the end of an TS
packet. Then some TS packets were missing and the next one
started a new PES packet. But only found was reset to 0 while
done got stuck at true. Later on, this caused write_ipack() calls
with mpeg still being 0. In this case, send_ipack() didn't reset
count so that the recursive call to write_ipack() parsed ancient
data, leading to incorrect breakAt locations which made bite
negative. As a result, the recursive calls stepped forward and
backward on the same data forever.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:rni...@gmx.de
--- ../vdr-1.7.0-patched/remux.c 2008-02-24 19:14:45.0 +0100
+++ remux.c 2008-12-17 00:33:16.0 +0100
@@ -2430,9 +2451,8 @@ void cTS2PES::ts_to_pes(const uint8_t *B
dsyslog("PES packet shortened to %d bytes (expected: %d bytes)", found, plength + 6);
plength = found - 6;
send_ipack();
-reset_ipack();
}
- found = 0;
+ reset_ipack();
}
uint8_t off = 0;
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] cTS2PES::write_ipack infinite recursion
Hi,
Andreas Pickart schrieb:
>> 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).
Thanks for your efforts so far.
> 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...
I would be glad if you could extract that data too ;-)
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
___
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
Re: [vdr] cTS2PES::write_ipack infinite recursion
Hi, Andreas Pickart schrieb: > 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? 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. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:[EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[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
