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 _______________________________________________ Pan-users mailing list Pan-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/pan-users
