From owner-freebsd-current@FreeBSD.ORG Mon Dec 12 00:07:53 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BD2AB16A41F for ; Mon, 12 Dec 2005 00:07:53 +0000 (GMT) (envelope-from jasone@canonware.com) Received: from lh.synack.net (lh.synack.net [204.152.188.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id BDA2243D45 for ; Mon, 12 Dec 2005 00:07:51 +0000 (GMT) (envelope-from jasone@canonware.com) Received: by lh.synack.net (Postfix, from userid 100) id 629705E48DA; Sun, 11 Dec 2005 16:07:51 -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 AD7195E48A2; Sun, 11 Dec 2005 16:07:46 -0800 (PST) In-Reply-To: References: <0B746373-8C29-4ADF-9218-311AE08F3834@canonware.com> <7318D807-9086-4817-A40B-50D6960880FB@canonware.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <12CA5E15-D006-441D-A24C-1BCD1A69D740@canonware.com> Content-Transfer-Encoding: 7bit From: Jason Evans Date: Sun, 11 Dec 2005 16:04:09 -0800 To: Claus Guttesen 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: current@freebsd.org Subject: Re: New libc malloc patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2005 00:07:53 -0000 On Dec 4, 2005, at 4:51 AM, Claus Guttesen wrote: > I was able to do a buildworld on current with this patch, but I had > problems getting X to run and kldxref took all my space on the > root-partition doing a installkernel. I've fixed the offending bug in kldxref in the latest patch: http://www.canonware.com/~jasone/jemalloc/jemalloc_20051211b.diff I spent several hours poking at X, but was never able to determine why it goes into an infinite loop. The infinite loop happens rather early, during the load of the libbitmap module. My best guess is that it is stuck trying to acquire the Xlib lock, but cannot be sure, since I don't know how to get debug symbols for the loaded X module. In any case, malloc is nowhere in the backtrace. I do not have the time to acquire the X expertise that is likely needed to track down this problem. Hopefully someone else will be willing to do so. No new problems in the malloc code have been found for some time now. It has been tested on i386, sparc64, arm, and amd64. In my opinion, the malloc patch is ready to be committed. I am now working on the assumption that new problems are more likely application bugs than malloc bugs. This seems like a good time to start sharing the debugging load with the community. =) So, how about it? Can this patch go in now? Thanks, Jason