From owner-cvs-src@FreeBSD.ORG Sat Jan 14 22:13:55 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 42D1416A41F; Sat, 14 Jan 2006 22:13:55 +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 C906143D46; Sat, 14 Jan 2006 22:13:54 +0000 (GMT) (envelope-from jasone@FreeBSD.org) Received: by lh.synack.net (Postfix, from userid 100) id 95B2A5E48D8; Sat, 14 Jan 2006 14:13:54 -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 B87F55E48C1; Sat, 14 Jan 2006 14:13:52 -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: <6FD0F2BA-88E3-4E82-A5F8-D89051AEEECA@FreeBSD.org> Content-Transfer-Encoding: 7bit From: Jason Evans Date: Sat, 14 Jan 2006 14:13:47 -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-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: Sat, 14 Jan 2006 22:13:55 -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 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. 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. >> 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? 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. > xorg-server-snap is a requirement in FreeBSD/amd64, but it > seems to trigger a panic and an insta-reboot with an ATI > Radeon here. Chances are good that the video driver is assuming page alignment for a large malloc'ed block. Right now, I don't have any suggestions on how to 100% verify this, but I'm planning to make some changes to malloc in the next couple of days that will allow us to use MALLOC_OPTIONS flags to determine if this is the problem. > 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. Thanks, Jason