From owner-cvs-all@FreeBSD.ORG Mon Jan 16 05:04:25 2006 Return-Path: X-Original-To: cvs-all@FreeBSD.org Delivered-To: cvs-all@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5499F16A41F; Mon, 16 Jan 2006 05:04:25 +0000 (GMT) (envelope-from jasone@FreeBSD.org) Received: from lh.synack.net (lh.synack.net [204.152.188.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id DFD1243D45; Mon, 16 Jan 2006 05:04:24 +0000 (GMT) (envelope-from jasone@FreeBSD.org) Received: by lh.synack.net (Postfix, from userid 100) id 113A35E48EB; Sun, 15 Jan 2006 21:04:24 -0800 (PST) Received: from [192.168.168.203] (moscow-cuda-gen2-68-64-60-20.losaca.adelphia.net [68.64.60.20]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by lh.synack.net (Postfix) with ESMTP id 136B35E484B; Sun, 15 Jan 2006 21:04:17 -0800 (PST) In-Reply-To: <20060114213238.GA15253@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> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <09F49F8F-A207-4A0C-A1F0-E905E6148055@FreeBSD.org> Content-Transfer-Encoding: 7bit From: Jason Evans Date: Sun, 15 Jan 2006 21:04:14 -0800 To: Giorgos Keramidas X-Mailer: Apple Mail (2.746.2) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on lh.synack.net X-Spam-Level: * X-Spam-Status: No, score=1.8 required=5.0 tests=RCVD_IN_NJABL_DUL, RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 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-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2006 05:04:25 -0000 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