This is the mail archive of the
mailing list for the Cygwin project.
Re: ld: fatal error - cmalloc would have returned NULL
-----BEGIN PGP SIGNED MESSAGE-----
On Mar 18 16:42, Corinna Vnschen wrote:
>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
>> >> > >problem. Before I did that (couple of years back) I also used to get
>> >> > >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.
I followed the discussion on the list and just tried the snapshot from 18th of
March. This snapshot allows bootstrapping of gcc-4.5.0-1 including libjava.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple