GNOME Bugzilla – Bug 501914
assert failure on startup: "pch == part_mid_buf + part_mid_buf_len'"
Last modified: 2008-07-04 16:14:33 UTC
Running openSuse 10.3. Get the following message when trying to execute from console mode. pan: parts.cc:244: void pan::Parts::set_parts(const pan::PartBatch&): Assertion `pch == part_mid_buf + part_mid_buf_len' failed. Aborted Any help would be appreciated.
According to reports I have seen on the net, they are caused by a group of posts where the first segment does not start with "1". The last post on http://ubuntuforums.org/archive/index.php/t-441073.html from chkno November 11th, 2007, 05:06 PM When I got this error, I found this in my ~/.pan2/tasks.nzb: <file ...> ... <segments> <segment ... number="3">...</segment> <segment ... number="4">...</segment> <segment ... number="5">...</segment> <segment ... number="6">...</segment> <segment ... number="7">...</segment> </segments> </file> That is, this one <file> entry did not have a segment numbered 1 or 2. I removed this one <file> node from tasks.nzb (with vim) and pan was then able to start normally. Here is the error and a backtrace. (Using FC8.) pan: parts.cc:244: void pan::Parts::set_parts(const pan::PartBatch&): Assertion `pch == part_mid_buf + part_mid_buf_len' failed. Program received signal SIGABRT, Aborted.
+ Trace 183736
Thread 46912496423408 (LWP 4440)
Created attachment 102641 [details] Crash report This is a crash report from trying to reload the tasks.nzb.
*** Bug 504359 has been marked as a duplicate of this bug. ***
*** Bug 499811 has been marked as a duplicate of this bug. ***
*** Bug 494254 has been marked as a duplicate of this bug. ***
*** Bug 482423 has been marked as a duplicate of this bug. ***
*** Bug 492911 has been marked as a duplicate of this bug. ***
in Bug 482423 Henry Pfeil had this comment: This results from a corrupt tasks.nzb when parts.cc can't find all of the parts of an attachment. When I encountered this behavior, I found the following sequence of numbers at the end of a <file><segments> section: <file... <segments>... <segment...number="122">...</segment> <segment...number="124">...</segment> <segment...number="124">...</segment> </segments> </file> Notice that the last two segments have identical sequence numbers. When I changed the first "124" to "123" pan started up as advertised. However, the article is supposed to have over 200 parts, according to the <file> tag, so I imagine the discrepancy was introduced by the server, perhaps by downloading the headers while the article was still in the process of being propagated? Maybe a consistency check during startup would generate a somewhat-less obtuse error message, perhaps toss out the entire <file></file> then suggest the user get new headers and re-queue the article? Should it be up to pan to reload the headers for the file and fix the queue behind the scenes? A more elegant solution might check for such errors while the header is being downloaded, but that could affect performance.
*** Bug 479654 has been marked as a duplicate of this bug. ***
Bug 479654 includes an nzb attachment that can be used to trigger the crash.
*** Bug 468102 has been marked as a duplicate of this bug. ***
Created attachment 110166 [details] An example NZB which trips assertion. rcpao@bun:~/Desktop$ pan --debug --nzb horton-hears-a-who.nfo-horton-hears-a-who.nzb (article-cache.cc:175:ArticleCache) loaded 63 articles into cache from /home/rcpao/.pan2/article-cache pan: parts.cc:244: void pan::Parts::set_parts(const pan::PartBatch&): Assertion `pch == part_mid_buf + part_mid_buf_len' failed. Aborted rcpao@bun:~/Desktop$ I'm using pan 0.132. Let me know if you need a backtrace.
I just ran into this today. I wasn't able to see any missing or replicated segment numbers in the nzb (but it was a large file, I may have missed it). The nzb did load and process in another nzb handling program (the old standby, nzbperl.pl) without error.
This appears to be the same bug RH's heap overflow ticket -- at least, after a quick test on my end I'm not able to trigger the crash anymore. Marking as a duplicate, but feel free to re-open if I'm mistaken. *** This bug has been marked as a duplicate of 535413 ***
*** Bug 540443 has been marked as a duplicate of this bug. ***