Re: [Pan-users] Linux Pan crashes on exit on x64 system.

[Duncan]

Joe Zeff posted on Fri, 24 Mar 2017 13:38:17 -0700 as excerpted:

> I've just had to reinstall my system and took advantage of the fact to
> upgrade from X86-PAE to X64.  Now, it crashes on exit every time I run
> it and the posts in the last group I accessed aren't marked as read the
> next time I run it.  (I've corrected that by editing my .newsrc-1 file.)
>   There is a record of it here:
> https://retrace.fedoraproject.org/faf/reports/522761/  Please note that
> this has been occurring since 12/30/2014, but it hasn't even been
> assigned yet.  If there's an appropriate place to report it, please let
> me know, and what needs to be included.

Your followup RH bugzilla report from two days ago:

https://bugzilla.redhat.com/show_bug.cgi?id=1435042


I see pkovar has already CCed the bug, so should get whatever fix and 
include it in pan upstream. =:^)


x64... is unfortunately somewhat ambiguous.

Is this x64 the newish unholy and problematic 64-bit/32-bit amalgam 
that's 64-bit kernel and IIRC some kernel calls but otherwise 32-bit 
userspace?  If so, that may be the problem as that's fairly new and 
uncommon and won't have been debugged very well (similar to amd64 aka 
x86_64 in ~ 2005).

IMO, FWIW, this is a too-late "solution" to a problem that time has 
already pretty much worked out on its own.  If it would have been 
introduced back about the time normal amd64 aka x86_64 was introduced, it 
might have gone somewhere and may well have inherited the x86 successor 
crown much as amd64 did in its absence, but by now the problems of amd64 
have pretty much been worked out and it's more common than the now legacy 
32-bit x86, and I simply don't see it being worth the trouble or going 
much of anywhere.

Or is it the more conventional 64-bit amd64/x86_64, that can also run 
legacy 32-bit x86, and normally does as shipped by most distros in what 
is known as a multilib installation?  I believe this is called x64 in at 
least some MS contexts, but it's normally known as amd64 or x86_64 in 
Linux contexts.

Of course x64 was also sometimes used to refer to Intel's now rather 
legacy itanium (aka itanic, due to the cost, inefficiency and 
unworkability that pretty much doomed it from the start), but the chances 
of you just getting that sort of hardware now (as opposed to trying to 
continue to run it after a purchase in the 200x's... if you had the money 
then... or perhaps purchasing it second-hand for pennies on the dollar 
more recently simply as a curiosity) are pretty small.


Meanwhile...  Not being a dev I don't get much from cores/backtraces and 
can't really help you with the crash itself.  But something I *can* help 
with...

Note that pan saves group read-messages state, writing it to the newsrc 
files, when you switch groups.

While pan on amd64 has been stable for me for quite some time now, I've 
been running it since pan 0.11-something (then on 32-bit x86) on gnome-1 
back in 2002, and neither it, nor X, nor the hardware I've been running 
it on, has always been stable during that now decade and a half.

So long ago I developed the habit of keeping some idea in my head of how 
many messages I had read that hadn't yet been saved, and once it gets to 
a level that marking all those messages read again on restart is going to 
be a hassle (generally every 5-500 messages or every 2-50 threads 
depending on the group and how fast I'm going), I'll quickly switch out 
to some other group and back again, triggering pan's exit-group save-read-
messages logic.

That way, if pan crashes, regardless of whether it's due to pan itself, 
or X, or the kernel, or hardware, I'll only have a few messages/threads 
to mark-read again when I restart it.

Of course if you have the option set to mark all messages in a group read 
when you switch groups, you may want to rethink your choice on that, 
first. =:^)

-- 
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