X-Recipient: archive-cygwin AT delorie DOT com X-Spam-Check-By: sourceware.org Date: Fri, 18 Mar 2011 16:42:46 +0100 From: Corinna Vinschen To: cygwin AT cygwin DOT com Subject: Re: ld: fatal error - cmalloc would have returned NULL Message-ID: <20110318154246.GA20773@calimero.vinschen.de> 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> <20110318145613 DOT GA10232 AT ednor DOT casa DOT cgf DOT cx> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20110318145613.GA10232@ednor.casa.cgf.cx> User-Agent: Mutt/1.5.21 (2010-09-15) 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 Mar 18 10:56, Christopher Faylor wrote: > 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. Maybe we should modify the implementation at one point, but for now I'm wonderin if we shouldn't just raise the cygheap size to 2 Megs. It's still not much memory given today's RAM sizes, and it's only a fraction of the application's address space. But it is enough so that ld's address space will be exhausted before the cygheap is exhausted. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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