John Aldrich <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], 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 _______________________________________________ Pan-users mailing list Pan-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/pan-users
