From owner-cvs-src@FreeBSD.ORG Mon Jan 16 13:54:12 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 AFD6C16A41F; Mon, 16 Jan 2006 13:54:12 +0000 (GMT) (envelope-from keramida@ceid.upatras.gr) Received: from aiolos.otenet.gr (aiolos.otenet.gr [195.170.0.93]) by mx1.FreeBSD.org (Postfix) with ESMTP id B126F43D5E; Mon, 16 Jan 2006 13:54:06 +0000 (GMT) (envelope-from keramida@ceid.upatras.gr) Received: from flame.pc (aris.bedc.ondsl.gr [62.103.39.226]) by aiolos.otenet.gr (8.13.4/8.13.4/Debian-8) with SMTP id k0GDs11U024284; Mon, 16 Jan 2006 15:54:02 +0200 Received: by flame.pc (Postfix, from userid 1001) id 651DE11711; Mon, 16 Jan 2006 15:54:00 +0200 (EET) Date: Mon, 16 Jan 2006 15:54:00 +0200 From: Giorgos Keramidas To: Jason Evans Message-ID: <20060116135400.GA28974@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> <09F49F8F-A207-4A0C-A1F0-E905E6148055@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <09F49F8F-A207-4A0C-A1F0-E905E6148055@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: Mon, 16 Jan 2006 13:54:12 -0000 On 2006-01-15 21:04, Jason Evans wrote: > On Jan 14, 2006, at 1:32 PM, Giorgos Keramidas wrote: > >On 2006-01-13 11:07, Jason Evans wrote: > >>On Jan 12, 2006, at 5:29 PM, Giorgos Keramidas wrote: > >>> > >>>[...] > >>> > >>>Does this look like an off-by-one error to you too Jason? > >>>Apparently, the allocated size of s->data is s->size, which is 873 > >>>bytes, but then Emacs tries to access s->data[873]. > >>> > >>>Does it look like I'm right in thinking that this is a bug in Emacs? > >> > >>This looks like a bug in emacs, as you say, but I don't know if it > >>has any particular relation to the posix_memalign() changes. > > > >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. > > I looked into this some, and it appears that it is a configuration > problem in emacs. When I ran 'configure', both GNU_MALLOC and > HAVE_POSIX_MEMALIGN were defined in config.h. This appears to be a > recipe for disaster, since the allocator included with emacs does not > provide posix_memalign(). This probably means that emacs is calling > into both its own allocator and libc's, then trying to free memory > that was allocated by libc, using its own allocator. > > Additionally, I see dlmalloc-specific code that tells dlmalloc not to > mmap() during allocation, since emacs's undump procedure doesn't > preserve mmap'ed regions. > > It looks like emacs is by default configured to use emacs's > allocator, which is good (getting emacs to work with FreeBSD's malloc > probably isn't worth the trouble). However, the emacs code makes the > mistake of deciding whether to use posix_memalign() based on > HAVE_POSIX_MEMALIGN, rather than something like USE_MEMALIGN -- emacs > is mixing and matching allocators and their features, which is not > good. I'm not familiar enough with emacs's configuration system to > know the correct way of fixing this, but one way or another, emacs > needs to not use posix_memalign(). Jason, thanks for the time you spent into this :) If disabling posix_memalign() fixes the problems of Emacs's use of allocators, I'll probably submit a patch to emacs-devel to do exactly this. It's one of the things RMS himself wouldn't object to, as he has stated already, so I think it's fine for the time being.