[Pan-users] Re: pan-0.119 issue

[Duncan]

John Aldrich <address@hidden> posted
address@hidden, excerpted below, on  Tue, 14 Nov
2006 19:28:15 -0500:

>> IMO you should enable core files or, when running Pan overnight,
>> run it in gdb so that you can get a backtrace.
>>
> Hmm... is that a config file option or a compile-time option (core files)?

Core files... good idea and I might have to do the same, since I'm seeing
a problem that doesn't want to duplicate when I'm running from anywhere
with STDOUT/STDERR open or with gdb attached.  In my case, it's upon
initial pan start, sometimes when I first hit the "get headers for
subscribed groups" button (or keyboard accel), pan simply disappears. 
Other times it continues just fine.  I've only had it happen the first
time I activate the get headers function, which hints that it might be a
memory allocation issue, perhaps related to another one I'm seeing, which
I suspect may be glibc-2.5 related, possibly only on amd64.

Answering the question, core files are a system thing, not pan.  I don't
know if it's a Linux-only feature or if the BSDs have it as well, and
haven't the /foggiest/ on MSWormOS. For Linux, then, support must be
compiled into the kernel first of all (it is by default and generally will
be for distribution distributed kernels). The setting is CONFIG_ELF_CORE,
in the kernel config menu under General setup > Configure standard kernel
features (for small systems) > Enable ELF core dumps.  (If you have
"Configure standard kernel features (for small systems)", aka
CONFIG_EMBEDDED, turned off, it'll automatically enable everything within,
including core dumps.  Turning it on enables you to disable individual
features that would otherwise be enabled by default.)

After you've confirmed kernel core-dump support, next check to see if it's
enabled at runtime.  There's a sysctrl option for the name, which you may
find located in a file like /etc/sysctrl.conf or similar, and a ulimit
setting (at least if your default shell is bash) limiting the maximum
corefile size.  core files are a memory dump, hence the term "dumping
core", so can be fairly large, and aren't all that useful to users who
aren't participating in active debugging activities, who then just have
the irritation of extra files to clean up after a crash, so the size is
often set to zero.  ulimit is a bash builtin, the corefile parameter is
-c.  Since a truncated core file is of little use, you'll want to set this
as large as the pan memory footprint ever gets or larger.  You can use the
special value "unlimited" if desired, but just to be safe, it's probably
worth setting something that would normally be ridiculously huge like 2
gig, which should be large enough for most process core dumps, but will
keep a runaway process from chewing thru all available memory and /then/
dumping the /entire/ thing (which would be close to the 8 gigs physical
memory, plus 16 gigs swap, here, so nearly 24 gigabytes in size, for a
single core file -- which could be a problem if I was on a legacy
filesystem that limits to say 2 gigabyte files!  I'm not.)

There may be system defaults set in /etc/bashrc or /etc/profile, or
something similar, or user defaults in your own user file equivalents
(~/.bashrc and ~/.profile are the most common).

Since bash's ulimit is in 1024 byte blocks, a 2 gig setting would
therefore be 2 meg (times the 1024 multiplier), so

ulimit -c 2097152

core files are normally dumped in $PWD (the current working directory),
which will be your home dir by default, unless you change it in whatever
you use to start pan.  Thus, you'll want to ensure it has sufficient
freespace -- suitably greater than the max corefile size, since you never
want to actually run out of space if it can be avoided.  In the example
above, therefore, a 2 gig corefile limit, I'd ensure that I had at least
three gigs of space available in my home dir, plus whatever pan might be
using during the session.

Once you are running a kernel with coredump support configured (as I said,
most kernels will have it on, unless you configured your own, in which
case you should know at least how to check it if you don't remember how it
was set), and have a suitable ulimit -c set, simply wait for pan to crash,
and hopefully you'll be left with the corefile, which you can then
backtrace as necessary.  (The core files themselves, in addition to being
rather huge, are just that, a coredump of the application's memory at the
time it crashed, and as such may contain privacy sensitive information, so
consider well before sending the coredumps themselves to anyone.)

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