Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 11 Dec 2005 16:35:38 -0800
From:      Julian Elischer <julian@elischer.org>
To:        Jason Evans <jasone@canonware.com>
Cc:        current@freebsd.org, Claus Guttesen <kometen@gmail.com>
Subject:   Re: New libc malloc patch
Message-ID:  <439CC5DA.3080103@elischer.org>
In-Reply-To: <12CA5E15-D006-441D-A24C-1BCD1A69D740@canonware.com>
References:  <B6653214-2181-4342-854D-323979D23EE8@canonware.com>	<Pine.LNX.4.53.0511291121360.27754@regurgitate.ugcs.caltech.edu>	<0B746373-8C29-4ADF-9218-311AE08F3834@canonware.com>	<b41c75520512031245q48521143m@mail.gmail.com>	<7318D807-9086-4817-A40B-50D6960880FB@canonware.com>	<b41c75520512040451t360eb01u@mail.gmail.com> <12CA5E15-D006-441D-A24C-1BCD1A69D740@canonware.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Jason Evans wrote:

> 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?


I may have missed it but some benchmark numbers could be good.

Is there no way to make it an option for a while?
that would get good testing AND a fallback for people.


>
> Thanks,
> Jason
> _______________________________________________
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to 
> "freebsd-current-unsubscribe@freebsd.org"




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?439CC5DA.3080103>