Date: Sun, 15 Jan 2006 04:46:27 +0200 From: Giorgos Keramidas <keramida@ceid.upatras.gr> To: Jason Evans <jasone@FreeBSD.org> Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/lib/libc/stdlib malloc.c Message-ID: <20060115024627.GA75521@flame.pc> In-Reply-To: <6FD0F2BA-88E3-4E82-A5F8-D89051AEEECA@FreeBSD.org> References: <200601121809.k0CI9QGV028693@repoman.freebsd.org> <AD9B1A12-47F1-4EA1-B270-CC83D3149543@freebsd.org> <20060112182804.GA1047@flame.pc> <20060113012900.GA16082@flame.pc> <554CC8A8-35FB-424A-B883-505C26ECBBE8@FreeBSD.org> <20060114213238.GA15253@flame.pc> <6FD0F2BA-88E3-4E82-A5F8-D89051AEEECA@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2006-01-14 14:13, Jason Evans <jasone@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!
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060115024627.GA75521>