After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 482423 - Pan wont start: Assertion failed in parts.cc
Pan wont start: Assertion failed in parts.cc
Status: RESOLVED DUPLICATE of bug 501914
Product: Pan
Classification: Other
Component: general
pre-1.0 betas
Other All
: Normal critical
: ---
Assigned To: Charles Kerr
Pan QA Team
Depends on:
Blocks:
 
 
Reported: 2007-10-02 01:28 UTC by Pavel
Modified: 2008-01-28 16:15 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
pan backtrace of tasks.nzb error (4.23 KB, text/plain)
2007-10-09 09:42 UTC, axion
Details
Pan assertion backtrace. (4.90 KB, text/plain)
2007-10-30 03:08 UTC, Roger C. Pao
Details

Description Pavel 2007-10-02 01:28:48 UTC
Steps to reproduce:
one day pan just stopped working...
pavel@localhost ~ $ pan
pan: parts.cc:244: void pan::Parts::set_parts(const pan::PartBatch&): Assertion `pch == part_mid_buf + part_mid_buf_len' failed.
Aborted



Stack trace:


Other information:
Comment 1 axion 2007-10-09 09:29:55 UTC
Deleting the parts.nzb solved this problem.
Could not find any xml errors in parts.nzb.
Comment 2 axion 2007-10-09 09:42:25 UTC
Created attachment 96925 [details]
pan backtrace of tasks.nzb error
Comment 3 Henry Pfeil 2007-10-25 18:03:18 UTC
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.
Comment 4 Roger C. Pao 2007-10-30 03:08:44 UTC
Created attachment 98151 [details]
Pan assertion backtrace.

I do not use .nzb files.  I select lots of headers and save their attachments to a directory.  I had over 2000 tasks when I took pan offline and quit.  When I restarted pan, I get this assertion which may be related.

rcpao@bun:~$ pan --debug
(article-cache.cc:175:ArticleCache) loaded 21 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 (core dumped)
Comment 5 Roger C. Pao 2007-10-30 03:21:40 UTC
I forgot to mention my version numbers.  Pan 0.132 (compiled by me from source) is crashing under Ubuntu 7.10.  Pan 0.129 (prebuilt binary) under Ubuntu 7.10 does not crash, and it is now continuing to save the 2951 attachments I have queued.
Comment 6 Charles Kerr 2008-01-28 16:15:49 UTC

*** This bug has been marked as a duplicate of 501914 ***