Subject: real backtrace for the crash I reported this morning

From: Matt Ackeret <[email-masked]>
Date: Mon, 12 Aug 2002 17:53:45 -0700 (PDT)

Basically -- I started up pine, it crashed.  I started up pine again, it
worked.  4.33 on "SunOS vax 5.6 sun4u sparc".

I remembered (or rather, guessed and was right) how to get a real backtrace
with a core file..

Dunno if this leads anybody to a useful fix..

/home/mattack % gdb /usr/local/bin/pine
GDB is free software and you are welcome to distribute copies of it
 under certain conditions; type "show copying" to see the conditions.
There is absolutely no warranty for GDB; type "show warranty" for details.
GDB 4.16 (sparc-sun-solaris2.6),
Copyright 1996 Free Software Foundation, Inc...
(gdb) core core
Core was generated by `pine'.
Program terminated with signal 10, Bus error.
Reading symbols from /usr/lib/libxnet.so.1...done.
Reading symbols from /usr/lib/libresolv.so.2...done.
Reading symbols from /usr/lib/libsocket.so.1...done.
Reading symbols from /usr/lib/libnsl.so.1...done.
Reading symbols from /usr/lib/libc.so.1...done.
Reading symbols from /usr/lib/libdl.so.1...done.
Reading symbols from /usr/lib/libmp.so.2...done.
Reading symbols from /usr/platform/SUNW,Ultra-1/lib/libc_psr.so.1...done.
Reading symbols from /usr/lib/nss_files.so.1...done.
#0  0xef5c5c84 in _malloc_unlocked ()
(gdb) bt
#0  0xef5c5c84 in _malloc_unlocked ()
#1  0xef5c5b14 in malloc ()
#2  0x188000 in fs_get (size=81) at fs_unix.c:30
#3  0x1875c4 in cpystr (
    string=0x33dc18 "{vax.area.com/user=mattack}INBOX : Message 2691 UID 8870259 greater than last 56") at misc.c:68
#4  0x8c980 in add_review_message ()
#5  0x1206a4 in status_message_write ()
#6  0x120bd0 in output_message ()
#7  0x120434 in flush_status_messages ()
#8  0x13deec in end_screen ()
#9  0x1006bc in panic ()
#10 0x11ebb0 in auger_in_signal ()
#11 <signal handler called>
#12 0xef5c5c84 in _malloc_unlocked ()
#13 0xef5c5b14 in malloc ()
#14 0x1ca4d8 in init_stack ()
#15 0x1ca798 in tparm ()
#16 0x13e0c0 in moveabsolute ()
#17 0x13e2b0 in MoveCursor ()
#18 0x120978 in status_message_write ()
#19 0x11f67c in alarm_signal ()
#20 <signal handler called>
#21 0xef5c62bc in realfree ()
#22 0xef5c6a94 in cleanfree ()
#23 0xef5c5c1c in _malloc_unlocked ()
#24 0xef5c5b14 in malloc ()
#25 0x188000 in fs_get (size=3) at fs_unix.c:30
#26 0x187654 in textcpy (dst=0x33c89c, src=0x3991f8) at misc.c:101
#27 0x17d5bc in mail_fetch_header (stream=0x33c7e0, msgno=2619, section=0x0,
    lines=0xefffdcb8, len=0xefffdcb4, flags=10) at mail.c:1351
#28 0x181afc in mail_search_msg (stream=0x33c7e0, msgno=2619, section=0x0,
    pgm=0x3a5358) at mail.c:2973
#29 0x181cfc in mail_search_msg (stream=0x33c7e0, msgno=2619, section=0x0,
    pgm=0x3a5268) at mail.c:3009
#30 0x181cfc in mail_search_msg (stream=0x33c7e0, msgno=2619, section=0x0,
    pgm=0x3a51f0) at mail.c:3009
#31 0x17ee8c in mail_search_default (stream=0x33c7e0,
    charset=0xa3b <Address 0xa3b out of bounds>, pgm=0x3a51f0, flags=22)
    at mail.c:1971
#32 0x17ece4 in mail_search_full (stream=0x33c7e0, charset=0x0, pgm=0x3a51f0,
    flags=22) at mail.c:1938
#33 0x12dff4 in match_pattern ()
#34 0xb6efc in calculate_some_scores ()
#35 0xaa4e4 in process_filter_patterns ()
#36 0xa8d08 in do_broach_folder ()
#37 0xfbc4c in main ()
(gdb)

[email-masked]

-- 
-----------------------------------------------------------------
 For information about this mailing list, and its archives, see: 
 http://www.washington.edu/pine/pine-info/
-----------------------------------------------------------------

---

From: daniel lance herrick <[email-masked]>
Date: Tue, 13 Aug 2002 07:42:50 -0400 (EDT)

>From one who has absolutely no Mac experience,

"Bus error" is usually a reference to a hardware
difficulty, not software. And it's not a very
specific reference - it says that something on the
bus violated the bus protocols, and everything is
on the bus.

If you're running on a unix-like system, look in
places like /var/log/messages to see if there are
other traces of the event that give a hint of what
system was involved in the "Bus error". (Windows
has a thing called an "Event viewer" that
sometimes reveals a hint. Undoubtedly the Mac has
a place where it remembers things that might turn
out to be interesting.)

dan

---

From: Steve Hubert <[email-masked]>
Date: Tue, 13 Aug 2002 10:37:49 -0700 (Pacific Daylight Time)

It looks like pine triggered an alarm signal for the busy spinner from
within malloc and then it re-entered malloc to print the message. So it
looks like it is pine's fault and we should be able to fix it for the next
release. Thanks for the stack trace.

(That's an unusual hostname for something running SunOS!)

-- 
Steve Hubert <[email-masked]>
Networks and Distributed Computing, Univ. of Washington, Seattle

---

From: Kenneth Crudup <[email-masked]>
Date: Tue, 13 Aug 2002 11:18:00 -0700 (PDT)

On Tue, 13 Aug 2002, daniel lance herrick wrote:

> "Bus error" is usually a reference to a hardware difficulty, not software.

Not necessarily. It's also the error you (can; depending on the arch) get when
you do unaligned accesses. Something like:

long * ptr = (char *) 0x3
*ptr = 1L;

	-Kenny

-- 
Kenneth R. Crudup    Sr. SW Engineer, Scott County Consulting, Los Angeles, CA
Home:	4105 E. Willow St. #246, Long Beach, CA 90815-1740
Work:	2052 Alton Parkway, Irvine, CA 92606-4905	   (949) 252-1111 X240

---

From: Stephen Casner <[email-masked]>
Date: Tue, 13 Aug 2002 12:40:36 -0700 (PDT)

On my desktop sytem, it appears that Pine outputs spaces all the way
to the right margin of the xterm window rather than outputting a
carriage return at the end of the actual text.  This may the expected
behavior when displaying the message index, but my complaint is that
it also happens when displaying the text of messages.  The problem is
that when I select text from the Pine window to paste into an editor,
I get all the extra spaces at the end.

This behavior began when I upgraded the desktop system from FreeBSD
4.2-RELEASE to FreeBSD 4.6-RELEASE and, as part of that, upgraded Pine
from 4.33 to 4.44.  However, I still have the 4.33 accessible, and it
behaves the same as 4.44 on the new system.  So it must be some other
component of FreeBSD, right?  Not so fast...

I also have a laptop running FreeBSD 4.5-RELEASE and Pine 4.44 where
the problem does not occur when running Pine locally.  Yet if I ssh
from the laptop to the desktop and run Pine on the desktop, the
problem occurs.  So it is not xterm or the X selection mechanism.

I concluded that the problem is extra spaces being output because if
in one xterm window I run Pine, then quit Pine, then run ls to
generate more output, and finally select text including some lines
that were part of the Pine display and some from the subsequent
command output, all the Pine lines extend to the right margin, but the
subsequent lines do not.

There were changes in the TERMCAP between FreeBSD 4.5 and 4.6, but I
copied the TERMCAP setting from the laptop and set it in a shell on
the desktop, and the problem still occurred.

The Pine 4.44 binaries are identical on both systems, as are the
libncurses.so.5 files.  TERMCAP I made the same.  The Pine
configuration files are the same.  What's left?

                                                        -- Steve

---

From: Steve Hubert <[email-masked]>
Date: Tue, 13 Aug 2002 16:05:08 -0700 (Pacific Daylight Time)

Pine doesn't output linefeed characters at the ends of lines. Instead, it
clears the line, moves the cursor, and writes the characters where it
wants them. If you are using color and the termcap entry doesn't have back
color erase, then pine uses spaces to clear the line in the background
color. So maybe that is what is happening to you. It's worth a shot,
anyway. Try turning off color (Setup/Kolor, scroll to top, choose
no-color) and see if the problem goes away. One way to see what pine is
outputting to the screen is to run it inside a "script" session.

On Tue, 13 Aug 2002, Stephen Casner wrote:

> carriage return at the end of the actual text.
> [...]

---

From: Stephen Casner <[email-masked]>
Date: Wed, 14 Aug 2002 12:22:14 -0700 (PDT)

On Tue, 13 Aug 2002, Steve Hubert wrote:

> color. So maybe that is what is happening to you.

Yes, that is it, as verified with script as you suggested.  I am using
color, including quote colors which would be effective when displaying
the body of a message.  But the background color is white, same as the
default background color for the xterm.  There isn't any way to select
"no background color" (you and I have talked about this before in a
different context).

But if the behavior is determined by the termcap entry, why wasn't the
behavior changed when I setenv TERMCAP to the termcap entry taken from
printenv TERMCAP on the laptop?

                                                        -- Steve

---

From: Steve Hubert <[email-masked]>
Date: Wed, 14 Aug 2002 13:47:10 -0700 (Pacific Daylight Time)

> printenv TERMCAP on the laptop?

I don't know. I can point you to the code if you want to investigate. In
.../pine/osdep/termout.unx is the routine CleartoEOLN. Here it is:

void
CleartoEOLN()
{
    int   c, starting_col, starting_line;
    char *last_bg_color;

    /*
     * If the terminal doesn't have back color erase, then we have to
     * erase manually to preserve the background color.
     */
    if(pico_usingcolor() && (!_bce || !_cleartoeoln)){
        starting_col  = _col;
        starting_line = _line;
        last_bg_color = pico_get_last_bg_color();
        pico_set_nbg_color();
        for(c = _col; c < _columns; c++)
          Writechar(' ', 0);

        MoveCursor(starting_line, starting_col);
        if(last_bg_color){
            (void)pico_set_bg_color(last_bg_color);
            fs_give((void **)&last_bg_color);
        }
    }
    else if(_cleartoeoln)
      tputs(_cleartoeoln, 1, outchar);
}

So here is where turning off color causes it to use the else instead of
the if clause. _cleartoeoln has to be defined for pine to work at all, I
think, so that implies that _bce must be zero when you're seeing the
problem. _bce is set in .../pico/osdep/term.cap or
.../pico/osdep/term.inf, depending on whether the makefile in the pico
directory uses termcap or terminfo. You can figure out which makefile is
being used by looking at picotarg in the build script. For example, "build
lnp" uses makefile.lnx in the pico subdir. The termcap capability for back
color erase is "ut". It's a Boolean. The terminfo version is "bce".
Perhaps your pine is using terminfo instead of termcap?

Steve

---

From: Stephen Casner <[email-masked]>
Date: Sat, 17 Aug 2002 23:13:04 -0700 (PDT)

On Wed, 14 Aug 2002, Steve Hubert wrote:
> I don't know.

The simple answer is that it was "a typical case of American blind to
justice ... and the judge wasn't going to look at the 27 8x10 color
glossy pictures..." [1]

In other words, setting the TERMCAP entry has no effect because the
library functions referenced by the pine code (which I found by
following your very helpful pointers) look at the underlying database,
not the environment variable.

> The termcap capability for back

I'm using FreeBSD, so picotarg=bsf, and termcap is selected, but it's
not clear to me whether the termcap library routines actually
reference terminfo.  In any case, with help from some FreeBSD gurus,
we found that in fact "ut" had recently been removed from the vt100
termcap which is indirectly referenced by the xterm tercap.  This
occurred between the 4.5-RELEASE and 4.6-RELEASE versions that I'm
running on my laptop and desktop, respectively, hence the difference
in their behaviors.  That was the root of the problem.

Thanks again for your help.
                                                        -- Steve

[1] Arlo Guthrie, "Alice's Restaurant"