From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9097 invoked by alias); 17 Feb 2006 10:19:39 -0000 Received: (qmail 9087 invoked by uid 22791); 17 Feb 2006 10:19:36 -0000 X-Spam-Check-By: sourceware.org Received: from host217-40-213-68.in-addr.btopenworld.com (HELO SERRANO.CAM.ARTIMI.COM) (217.40.213.68) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 17 Feb 2006 10:19:33 +0000 Received: from rainbow ([192.168.1.165]) by SERRANO.CAM.ARTIMI.COM with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Feb 2006 10:19:29 +0000 From: "Dave Korn" To: Subject: RE: cygheap base mismatch detected Date: Fri, 17 Feb 2006 10:23:00 -0000 Message-ID: <00d501c633ab$a34a0840$a501a8c0@CAM.ARTIMI.COM> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In-Reply-To: Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com X-SW-Source: 2006-02/txt/msg00613.txt.bz2 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/