Re: Core Dump on Second Folder Open on Startup

On Wed, 3 Jan 2007, Curt Sampson wrote:

> I've got a couple of NetBSD machines, one running netbsd-4 branch from a
> few months ago (and various libraries and so on of a similar age), and
> the other running a build from a few days ago. Both are using the same
> config file, which has preopen-stayopen-folders set, and are talking to
> the same imap server (via ssh).
>
> On the older one, the pkgsrc pine 4.64 runs fine; on the newer one, it
> opens my first folder in the stay-open-folders list just fine, but when
> it tries to open the next folder on that list, it receives an abort
> signal and dies, with this backtrace:
>
>    Program terminated with signal 6, Aborted.
>    #0  0xbb8caf2f in kill () from /usr/lib/libc.so.12
>    (gdb) bt
>    #0  0xbb8caf2f in kill () from /usr/lib/libc.so.12
>    #1  0xbb961b4c in abort () from /usr/lib/libc.so.12
>    #2  0x081848df in mm_critical ()
>    #3  0x0813a31a in mm_dlog ()
>    #4  0x08165483 in mm_critical ()
>    #5  <signal handler called>
>    #6  0x0000001f in ?? ()

Sounds like something is clobbering the stack. The signal cushion is 
eating what is left of your evidence. I'd suggest either rebuilding Pine 
with DEBUG defined in the build environment and running with debug >= 7, 
or manually whacking the CUSHION_SIG bits in pine/signals.c (during 
debugging I usually go the hacky route :-)

You may or may not get a better stack trace out of it -- clobbered stack 
is often nasty to track, because the damage is usually done milliseconds 
and milliseconds before the actual crash.

> If I try to open the second folder in the stayopen list directly, with
> the -f option, it opens fine. If I open the first folder with the -f
> option, and then (G)oto the second folder (and subsequent ones) it works
> fine. It seems it's just on startup that this happens.
>
> Before I get into an extended debugging session with this, has anybody
> seen anything like this before. Does anybody have any hints on what I
> should be looking for? Does anyone have any debugging hints, or bits of
> info that I should track down to help the developers?

Other than whacking all cosmetic signal handlers, you may wish to run 
the thing under ktrace to see the system calls it did prior to crashing. 
If you have ltrace, that might give even more insight. Oh, and building 
pine with DEBUG and setting debug will obviously give a good insight 
into what Pine thinks it is doing.

I have not delved deeply enough into Pine's guts to give an educated 
guess about the actual problem, sorry...
_______________________________________________
Pine-info mailing list
[email protected]
http://mailman1.u.washington.edu/mailman/listinfo/pine-info