This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: cygheap base mismatch detected


On 16 February 2006 23:17, Dill, Jens (END-CHI) wrote:

> More test results:

  Right, thanks for giving us something we can actually get our teeth into...
it would really have been helpful to bring out some of this information a bit
earlier in the thread, like in the very first post for instance, but better
late than never!
 
>> I can run tests in which I allocate static arrays of increasingly
>> large size, and I hit the cygheap base problem *exactly* when I
>> try to make an array bigger than 1.5 Gb.
> 
> This still happens reliably, and note that I can declare an array
> of *exactly* 1.5 Gb, and load and run the program.  I hit the
> problem when I go over 1.5 Gb (my script increases the size
> in 64-Mb increments).

  Ah, well hang on; you're about to bang into some fairly fundamental OS
limitations here.  For starters, there's only 2Gb in the total user address
space range, and the windows dlls are by default mapped into the top 1/4 of
that, 0x60000000 - 0x80000000.

>> I can run tests in which I set the --stack option for the linker
>> to increasingly large sizes, and I get a "thread handle not set"
>> error during execution the minute my stack size exceeds 0.5 Gb.
>> Yes, that's 0.5.  I never go to the full 1.5 Gb.

  That's a new one I haven't heard of before.  It's not very surprising that
there are more limitations on the stack than on the heap, as it's kinda
special.

> My app includes a lot of DLLs.  I used cygcheck to get the list,
> and summed up their sizes.  The total code size on disk before
> loading of the app plus the DLLs is just over 115 Mb, leaving
> over 1420 Mb to be taken up by static and dynamic memory.
> I still don't think the app uses more than a couple of Mb of
> static memory, and the problem occurs before anything dynamic
> can be allocated.  What am I overlooking?

  Hmm, what kind of DLLs?  Any of these your own custom builds?  In particular
do some of them have base addresses still set to the default 0x10000000?  If
so, the first one that gets loaded into memory is going to frag the address
map into two chunks, which is bound to impact the size of contiguous heap
chunk that can be allocated.  Have you looked into 'rebaseall' yet?  There's
also the windows boot.ini /3GB switch to investigate, but I remember there
having been some kind of limitation on that in the past; I'm afraid I can't
remember what the problem was nor if it still applies.



    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]