From patchwork Wed Dec 17 00:33:55 2008 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Reinhard Nissl X-Patchwork-Id: 12685 Received: from mail.gmx.net ([213.165.64.20]) by www.linuxtv.org with smtp (Exim 4.63) (envelope-from ) id 1LCkN4-00055v-CS for vdr@linuxtv.org; Wed, 17 Dec 2008 01:34:39 +0100 Received: (qmail invoked by alias); 17 Dec 2008 00:34:04 -0000 Received: from p549344EE.dip.t-dialin.net (EHLO [192.168.101.15]) [84.147.68.238] by mail.gmx.net (mp062) with SMTP; 17 Dec 2008 01:34:04 +0100 X-Authenticated: #527675 X-Provags-ID: V01U2FsdGVkX1/Eh8cOC9LEL3bRKRI+q2emzX9r1ruU738s+H/NTI PpilhNwq7e89x3 Message-ID: <494848F3.9060805@gmx.de> Date: Wed, 17 Dec 2008 01:33:55 +0100 From: Reinhard Nissl User-Agent: Mozilla/5.0 (X11; U; Linux i686; de; rv:1.8.1.17) Gecko/20080922 SUSE/2.0.0.17-0.1 Thunderbird/2.0.0.17 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: VDR Mailing List References: <20081201170757.8A45F3030045@mail.opensourcefactory.com> <4939AF92.4030000@gmx.de> <20081208094013.605F8303002E@mail.opensourcefactory.com> <493D8429.5050509@gmx.de> In-Reply-To: <493D8429.5050509@gmx.de> X-Y-GMX-Trusted: 0 X-FuHaFi: 0.58 X-LSpam-Score: -2.5 (--) X-LSpam-Report: No, score=-2.5 required=5.0 tests=AWL=0.108, BAYES_00=-2.599 autolearn=ham Subject: Re: [vdr] cTS2PES::write_ipack infinite recursion X-BeenThere: vdr@linuxtv.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: VDR Mailing List List-Id: VDR Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2008 00:34:39 -0000 Status: O X-Status: X-Keywords: X-UID: 18868 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. --- ../vdr-1.7.0-patched/remux.c 2008-02-24 19:14:45.000000000 +0100 +++ remux.c 2008-12-17 00:33:16.000000000 +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;