From owner-cvs-src@FreeBSD.ORG Sun Jan 15 02:01:59 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 1269E16A422 for ; Sun, 15 Jan 2006 02:01:59 +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 15C6F43D64 for ; Sun, 15 Jan 2006 02:01:50 +0000 (GMT) (envelope-from keramida@ceid.upatras.gr) Received: (qmail 17682 invoked by uid 207); 15 Jan 2006 02:01:49 -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.441024 secs); 15 Jan 2006 02:01:49 -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:01:48 -0000 Received: by flame.pc (Postfix, from userid 1001) id EAD2D11479; Sun, 15 Jan 2006 01:44:17 +0200 (EET) Date: Sun, 15 Jan 2006 01:44:17 +0200 From: Giorgos Keramidas To: Jason Evans Message-ID: <20060114234417.GA65773@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:01:59 -0000 On 2006-01-14 14:13, Jason Evans wrote: > >Apparently it does seem related to posix_memalign() changes. > >When I bootstrap Emacs without posix_memalign(), by manually > >tweaking src/config.h after configure runs, and #undef > >POSIX_MEMALIGN, then it passes the bootstrap stage normally. > > Hmm, that's interesting. I'll mess around with emacs later on today > (though I only have i386 hardware at the moment). Right now, I'm > still building xorg on my machine in order to try to reproduce the gtk > problems that Pascal Hofstee reported. I'll try to rebuild CURRENT on my i386 workstation too, but that takes a couple of hours so I think it will be Sunday morning that I will have results of bootstrapping Emacs on i386. > >>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? As a test of the new malloc, I rebuilt all my ports today with today's current (i.e. after malloc.c,v 1.93). This is when irssi started crashing. I'm half-way through a buildworld now, with DEBUG_FLAGS='-g' and CFLAGS='-g' for autoconf-based ports. The crash of irssi happens when I hit , and irssi tries to split a string in 'words'. It may be a stupid bug in irssi, because it uses: /* Return whole word at specified position in string */ char *get_word_at(const char *str, int pos, char **startpos) { ... } but there's no function argument that holds the allocated size of `str', so I guess the fact that `pos' may point outside of the allocated area of `str' is checked elsewhere. Is option 'U' and running irssi under ktrace all it takes to enable the extra trace checks? > The amd64 computer I have on order won't be here for at least another > week, so if this is amd64-specific, I won't be able to reproduce it > right away. I'll try to prepare a snapshot that is easy to 'restore' from CD-ROM, so that I can continue to use my laptop for my $REALJOB, but also with the latest malloc for debugging. > >Apart from looking at the source code, do we have some sort of > >'design' docs for the new malloc(), to see if I can help debug these > >problems a bit more when I restore my laptop's ports & packages from > >the backup later tonight? > > I have a draft of a paper that I submitted to BSDcan, but I don't > think I should make it generally available yet, as a courtesy to > BSDcan. I don't see a problem with providing it to individuals upon > request, though. No that's ok. I can hopefully read the source :)