[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Pan-users] Segfault at exit
From: |
Duncan |
Subject: |
Re: [Pan-users] Segfault at exit |
Date: |
Sat, 24 Dec 2016 07:49:09 +0000 (UTC) |
User-agent: |
Pan/0.141 (Tarzan's Death; GIT 194f2dc09) |
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