cvs commit: src/lib/libc/stdlib malloc.c

[Giorgos Keramidas]

On 2006-01-14 14:13, Jason Evans <jasone at FreeBSD.org> wrote:
> >>If updating to either before or after the broken
> >>posix_memalign() revision, and need help figuring out the
> >>issue, please let me know.
> >
> >More issues come up after updating to today's CURRENT version of
> >malloc.  In particular:
> >
> >    irssi started core dumping with symptoms similar to those of
> >    Emacs bootstrap, i.e. access to memory regions that are
> >    <inaccessible> in gdb
>
> malloc's ability to output allocation logs when run via ktrace, in
> combination with a core dump, should be able to show precisely what
> is happening.  If you're interested in tracking this down, I can help
> you.  Otherwise, can you give me a bit more information on the
> conditions that cause the crash?

I didn't need the utrace output, after all.  Building the programs with
debug information, I captured a core dump of irssi.  It appears that
somewhere along the stack, an address gets corrupted from 0x8030e3100 to
0x30e3100 -- which looks like a bug caused by assumming too much about
the size of a pointer.

For instance, here's a typical stack trace (relatively long, with 20
frames, but trimmed to the first 5 here):

| #0  0x0000000000442e34 in get_word_at (
|     str=0x30e3100 <Address 0x30e3100 out of bounds>, pos=5,
|     startpos=0x7fffffffdd98) at completion.c:74
| #1  0x0000000000442f68 in auto_word_complete (
|     line=0x30e3100 <Address 0x30e3100 out of bounds>, pos=0x7fffffffddec)
|     at completion.c:96
| #2  0x000000000041b210 in key_check_replaces () at gui-readline.c:808
| #3  0x00000000004a51ca in signal_emit_real (rec=0x8030b4e70, params=3,
|     va=0x7fffffffdec0, first_hook=0x8030b4ec0) at signals.c:242
| #4  0x00000000004a5411 in signal_emit (
|     signal=0x8030e3890 "key check_replaces", params=3) at signals.c:286
| #5  0x0000000000457d99 in sig_multi (
|     data=0x8030ba1d0 "check_replaces;insert_text  ", gui_data=0x0)
|     at keyboard.c:640

It seems strange that most of the addresses are in the 0x800000000+
range and the adress that triggers the core dump is much smaller:

(gdb) x/s 0x30e3100
0x30e3100:       <Address 0x30e3100 out of bounds>

But the real string I typed when irssi crashed is available at:

(gdb) x/s 0x8030e3100
0x8030e3100:     "/nick"

Hmmm... this is definitely a bug, but it looks more like a bug in irssi
now.  I wonder where that address is stripped from it's highest bit!