Re: [Pan-users] Segfault at exit

[Duncan]

Jim Henderson posted on Thu, 22 Dec 2016 23:23:09 +0000 as excerpted:

> As I prepare to take some time off work over the holidays, I thought I
> might try to track down a minor issue that's been bugging me for a
> little bit now - when I exit Pan, I get a segfault, and it appears to
> happen at a time that stops the app from writing all of its "last read"
> information out.

While I don't see your segfault (which does support your theory that it's 
a problem with your config), pan does have a workaround for crashes 
preventing read-message, etc, writeouts, that I've been using for years 
now.  IIRC I reinforced the habit (which I /think/ I had even before 
that, but that reinforced it) back when I was having problems not with 
pan itself, but with xorg and kwin, back when the composite extension 
(and kde/kwin's use thereof) was new and had a leak that would regularly 
crash xorg... of course taking pan down along with it, without a chance 
to write out its current state, of course.  Yes, it was /that/ long ago. 
Anyway, by doing this, I kept the lost data to some level I considered 
reasonably manageable.

The key here is to realize that pan writes out the per-newsgroup data 
when it switches groups, so in busy groups with enough unread messages 
that I didn't want to risk losing at least semi-current read-messages 
tracking, I developed the habit of deliberately clicking to some other 
group and back every N messages or so.  On busy mostly binary groups with 
thousands of unread messages, N would be 500 messages or so, a couple 
times per thousand messages; on more technical groups where I went 
slower, N might be 50 or 100 messages.

That seemed to address the problem rather nicely, even in the above case 
where it wasn't pan, but X, taking pan with it, that was crashing.  I 
keep up with the habit today, tho I'm probably less religious about it 
than I was when X was regularly crashing, so one might say pan has 
trained me well. =:^)

Of course if you find your specific problem and develop a patch to 
prevent pan crashing, nobody's going to complain, but this should make 
dealing with the problem a bit easier than it was.  Just switch 
newsgroups immediately before quitting pan, and/or do the periodic switch-
out-and-back that I've learned to do, if pan (or X) is crashing somewhat 
unpredictably on you.

As for the last few messages since the last group-switch, at least in 
groups where you download to read on-demand and where cache size isn't a 
factor (thus more commonly in text groups), it's typically easy to see 
where you were even if pan crashed and lost the read-status, because 
those messages will already be downloaded, while the others aren't.

> It's been happening for a while now, with various builds, using the data
> I have right now.  I'm guessing that the issue isn't a code bug, but
> rather something wrong in my data files.  I'd rather not recreate my
> config from scratch, so I'm trying to track down the problematic config
> file so I can fix it.
> 
> Call it a "foxhunt" if you like. Something of a puzzle to be solved. :)
> 
> I built a debug build and did a backtrace in gdb, and it points to
> pan.cc line 1140.  That seems to tie to the process of freeing up
> secured passwords in memory, so I thought it might be something in
> servers.xml, but I don't see anything obvious in that file that's a
> problem (other than perhaps a missing CR/LF at the end of the file, but
> I tried adding that and the behavior didn't change).
> 
> Any ideas on where I should start?

First thing I'd do is isolate whether the problem only triggers when you 
connect to the server, not if you're local-only.  Either set pan as 
offline (if that setting sticks across pan restarts, I'm not sure whether 
it does), or if necessary, toggle the get new headers on startup and when 
entering group options (in preferences, behavior, groups) to OFF, so you 
can start pan and switch groups without pan fetching headers, then 
restart pan and browse some already locally cached headers and messages 
without doing anything that actually triggers pan to connect to the 
server, and see if the problem still occurs.

That alone should help confirm whether it's password and/or server 
related.

Then, if it's still happening when pan isn't network connecting, it makes 
this next step easier.

Use the old bisect method on pan's data dir, first ensuring that the 
problem disappears with a clean config, then try bisecting the problem 
down to a single file, testing a theoretical half of the problem space at 
a time.  Of course this is dramatically easier if the test set of files 
remain static, thus the reason to test without network activity and 
downloads going on, if possible.

I'd probably test right away with a clean article cache, to see if it's 
that, and particularly if the problem only happens with a server 
connection, I'd test right away with a clean ssl_certs dir and let pan 
redownload the certs, of course comparing them to the previous certs 
manually.

You've long since updated pan and the certs from back when pan was 
writing corrupt binary files instead of the ascii-based cert files it 
should have been writing and writes in current versions, right?

The groups dir and newsrc files are also suspect since it's writing them 
out that's failing.

And IIRC I had a problem with a corrupt tasks.nzb at one point, tho that 
should be regularly updated, so I wouldn't expect it to be the problem in 
this case as it has been an ongoing problem for you for some time, and 
that was a more urgent "pan won't work at all" problem for me, when it 
got corrupted.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman