From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6214 invoked by alias); 16 Feb 2006 19:36:46 -0000 Received: (qmail 6204 invoked by uid 22791); 16 Feb 2006 19:36:45 -0000 X-Spam-Check-By: sourceware.org Received: from mail-relay5.elsevier.com (HELO MAIL-RELAY5.elsevier.com) (63.125.147.41) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 16 Feb 2006 19:36:42 +0000 Received: from elsstls17525.elsevier.com (unverified) by MAIL-RELAY5.elsevier.com (Content Technologies SMTPRS 4.3.14) with ESMTP id for ; Thu, 16 Feb 2006 13:35:47 -0600 Received: by elsstls17525.elsevier.com with Internet Mail Service (5.5.2657.72) id <1QCWWGDS>; Thu, 16 Feb 2006 13:36:36 -0600 Message-ID: From: "Dill, Jens (END-CHI)" To: cygwin@cygwin.com Subject: RE: cygheap base mismatch detected Date: Thu, 16 Feb 2006 19:38:00 -0000 MIME-Version: 1.0 Content-Type: text/plain 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/msg00594.txt.bz2 Dave Korn writes: > > Unfortunately for me, (e) is impractical. It's not clear whether > > it is my source code or CygWin's that I need to fix, > > Have you actually *tried* this application of yours under Cygwin and > discovered that it indeed *is* one of the rare ones that actually runs into > this problem, or are you getting your knickers in a twist over some entirely > theoretical issue that may just as likely never happen? > > > My project time frame doesn't allow for that. If I read Dave Korn's > > posting correctly (along with the others who talk about adjusting the > > sizes of Fortran arrays to fix the problem) > > *Why* are you relying on information that is 12 to 18 months out of date? > There's been quite a few check-ins to the cygwin cvs in that period, and in > case you haven't noticed, we haven't had anyone here running into that problem > recently, and some of the fortran people said that one of the fixes Corinna > made _ages_ ago now had solved the problem in their experience, so perhaps you > should stop hoping to divine the truth from a priori first principles and > outdated mailing-list-posts, and get a bit _empirical_ about it? Of course I have *tried* the application under CygWin and it does indeed actually run into the problem. Of course I have searched the list for more recent information about the problem. Of course I am using a new installation of the latest stable CygWin and a machine with sufficient memory and horsepower. Not every new poster to the list is a newbie to posting. I have done some experimentation. The "maxmem" program outlined in http://cygwin.com/cygwin-ug-net/setup-maxmem.html shows me that I have 1.5 Gb of memory available to allocate. 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. I can run tests in which I set the --heap option for the linker to increasingly large sizes, and I hit the cygheap base problem *exactly* when I try to make the heap size larger than 1.5 Gb. 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. I did not tinker with --stack or --heap when building my executable. I am positive it has no static arrays larger than a few tens of thousands of bytes. Certainly nowhere near 1.5 Gb. The size of the .exe file itself is just over 80 Mb. So what is causing the problem? -- Jens Dill Endeavor Information Systems -- 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/