Re: [Pan-users] debugging? (segmentation fault)

[Rhialto]

On Sun 13 Feb 2022 at 15:12:44 +0100, Rhialto wrote:
> I'm not sure what input it's trying to parse there:

Going by the comments earlier in headers.cc, it's likely to be one of
the files in ~/.pan2/groups. So it's a file that Pan wrote itself.
Somehow it got corrupted apparently.
You could try moving aside the files in the  ~/.pan2/groups directory
and putting them back gradually, to find which one is the bad one.

The data the code is trying to parse looks something like this:

0
<Xns9BA78C87E9BCTheLoneAndLevelSands@216.196.97.142>
        Wolf Walls (1600x1200) - File 01 of 47 - $index1.jpg (/2)
        m
        1233640308
        6:a:60114 
        t 2 2 9743
        1 <Xns9BA78C87E9BCTheLoneAndLevelSands@216.196.97.142> 505347
        2 <Xns9BA78CCB35D0TheLoneAndLevelSands@216.196.97.142> 110836

where the code that crashed tries to look at one of the bottom 2 lines,
but appparently it got an empty line (or just whitespace) instead.

The top of each file explains the format:

# C. The group's headers section.
#    The first line tells the number of articles to follow,
#    then articles which each have the following lines:
#    1. message-id
#    2. subject
#    3. author
#    4. references. This line is omitted if the Article has an empty References 
header.
#    5. time-posted. This is a time_t (see 
http://en.wikipedia.org/wiki/Unix_time)
#    6. xref line, server1:group1:number1 server2:group2:number2 ...
#    7. has-attachments [parts-total-count parts-found-count] line-count
#       If has-attachments isn't 't' (for true), fields 2 and 3 are omitted.
#       If fields 2 and 3 are equal, the article is `complete'.
#    8. One line per parts-found-count: part-index message-id byte-count

-Olaf.
-- 
___ "Buying carbon credits is a bit like a serial killer paying someone else to
\X/  have kids to make his activity cost neutral." -The BOFH    falu.nl@rhialto

signature.asc
Description: PGP signature