X-Recipient: archive-cygwin AT delorie DOT com X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,UNPARSEABLE_RELAY X-Spam-Check-By: sourceware.org X-Yahoo-SMTP: jenXL62swBAWhMTL3wnej93oaS0ClBQOAKs8jbEbx_o- Date: Fri, 18 Mar 2011 10:56:13 -0400 From: Christopher Faylor To: cygwin AT cygwin DOT com Subject: Re: ld: fatal error - cmalloc would have returned NULL Message-ID: <20110318145613.GA10232@ednor.casa.cgf.cx> Reply-To: cygwin AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com References: <4D7A2951 DOT 1030002 AT emrich-ebersheim DOT de> <4D82F1D8 DOT 1020608 AT gmail DOT com> <20110318060821 DOT GB15594 AT ednor DOT casa DOT cgf DOT cx> <20110318102355 DOT GA20048 AT calimero DOT vinschen DOT de> <20110318144048 DOT GF20048 AT calimero DOT vinschen DOT de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110318144048.GF20048@calimero.vinschen.de> User-Agent: Mutt/1.5.20 (2009-06-14) Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com On Fri, Mar 18, 2011 at 03:40:48PM +0100, Corinna Vinschen wrote: >On Mar 18 11:23, Corinna Vinschen wrote: >> On Mar 18 02:08, Christopher Faylor wrote: >> > On Fri, Mar 18, 2011 at 05:47:04AM +0000, Dave Korn wrote: >> > >On 11/03/2011 13:53, Rainer Emrich wrote: >> > > >> > >> I have to be more clear. I increased the heap_chunk_in_mb to 1792 using: >> > >> regtool -i set /HKLM/Software/Cygwin/heap_chunk_in_mb 1792 >> > > >> > > I run with this setting all the time, I guess that's why I haven't seen this >> > >problem. Before I did that (couple of years back) I also used to get crashes >> > >building libjava. >> > >> > That setting should have nothing to do with cmalloc(). cmalloc is for >> > Cygwin's internal heap which has nothing to do with that setting. >> > >> > Didn't Corinna already mention this? >> >> In this case the bigger heap seems to avoid the aggressive use of small >> mmap chunks which in turn disallows to raise the cygheap size. Without >> analyzing the whole situation there's not much else to say or do. This >> is YA case which screams loudly for a testcase... > >I created an extensive testcase(*) and it turned out that the current >algorithm to allocate memory on the cygheap is wasting a lot of memory. >Actually it organizes the memory in buckets, each of which cares for a >specific size as a power of 2. So memory on the cygheap is always >allocated in chunks of 4 byte, 8 byte, 16 byte, 32 byte, etc. Plus, >every chunk needs extra 8 byte for bookkeeping. Right. That's a fairly classic implementation of malloc which was, in this case, implemented by DJ Delorie. I chose that from a few other implementations because it was, at the time, supposed to be the best tradeoff between speed and memory usage. But, back when I implemented the cygheap it wasn't used as much as it is now, which I guess is fairly obvious. cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple