From owner-cvs-src@FreeBSD.ORG Sun Jan 15 02:48:24 2006 Return-Path: X-Original-To: cvs-src@FreeBSD.org Delivered-To: cvs-src@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D959316A420 for ; Sun, 15 Jan 2006 02:48:23 +0000 (GMT) (envelope-from keramida@ceid.upatras.gr) Received: from nic.ach.sch.gr (nic.sch.gr [194.63.238.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0C81B43D93 for ; Sun, 15 Jan 2006 02:48:09 +0000 (GMT) (envelope-from keramida@ceid.upatras.gr) Received: (qmail 27570 invoked by uid 207); 15 Jan 2006 02:48:08 -0000 Received: from keramida@ceid.upatras.gr by nic by uid 201 with qmail-scanner-1.21 (sophie: 3.04/2.30/3.97. Clear:RC:1(81.186.70.3):. Processed in 0.279118 secs); 15 Jan 2006 02:48:08 -0000 Received: from dialup3.ach.sch.gr (HELO flame.pc) ([81.186.70.3]) (envelope-sender ) by nic.sch.gr (qmail-ldap-1.03) with SMTP for ; 15 Jan 2006 02:48:07 -0000 Received: by flame.pc (Postfix, from userid 1001) id 6159D114BA; Sun, 15 Jan 2006 04:46:27 +0200 (EET) Date: Sun, 15 Jan 2006 04:46:27 +0200 From: Giorgos Keramidas To: Jason Evans Message-ID: <20060115024627.GA75521@flame.pc> References: <200601121809.k0CI9QGV028693@repoman.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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6FD0F2BA-88E3-4E82-A5F8-D89051AEEECA@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 X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jan 2006 02:48:24 -0000 On 2006-01-14 14:13, Jason Evans 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 > > 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
, pos=5, | startpos=0x7fffffffdd98) at completion.c:74 | #1 0x0000000000442f68 in auto_word_complete ( | line=0x30e3100
, 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:
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!