From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1749 invoked by alias); 16 Feb 2006 18:34:15 -0000 Received: (qmail 1739 invoked by uid 22791); 16 Feb 2006 18:34:14 -0000 X-Spam-Check-By: sourceware.org Received: from mail-relay4.elsevier.com (HELO MAIL-RELAY4.elsevier.com) (63.125.147.40) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 16 Feb 2006 18:34:11 +0000 Received: from elsstls17525.elsevier.com (unverified) by MAIL-RELAY4.elsevier.com (Content Technologies SMTPRS 4.3.14) with ESMTP id for ; Thu, 16 Feb 2006 12:31:47 -0600 Received: by elsstls17525.elsevier.com with Internet Mail Service (5.5.2657.72) id <1QCWW17M>; Thu, 16 Feb 2006 12:32:37 -0600 Message-ID: From: "Dill, Jens (END-CHI)" To: cygwin@cygwin.com Subject: RE: cygheap base mismatch detected Date: Thu, 16 Feb 2006 18:36: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/msg00589.txt.bz2 Dave Korn writes: > On 15 February 2006 22:23, Jens Dill wrote: > > Jens Dill writes: > > > >> ----Original Message---- > >>> From: Andreas Heckel > >>> Sent: 07 April 2005 11:13 > ^^^^^^^^^^^^^^^^^ > > Dave: > > > > What you write makes it appear that CygWin simply will not support > > large executables that reference the CygWin DLL and are also launched > > from a CygWin shell. > > No, that was to do with executables that allocate massive amounts of heap > space, it's not related to the size of the code section. And it's got a lot > better over the past year. I can't make this agree with the facts in front of me. If it has to do with executables that allocate massive amounts of heap space, then how does the message appear before the application even starts, before it has a chance to allocate anything from the heap? Massive amounts of statically allocated memory I can agree with, but not heap space. I haven't been tinkering with the --heap option on the link as yet, so it's not even the declared heap size that is of concern. Also, the message says that the "heap base" is mismatched. That doesn't necessarily indicate a connection with heap size. And if CygWin is going to artificially limit how my program chooses to allocate memory, it certainly should be documented better than this. I agree that the origin of this thread is nearly a year old, and something may have happened since that time to make it better. But it's still happening to me, on a newly installed copy of Cygwin (DLL version 1.5.18), on a machine with ample memory and processing power, and none of the suggestions or discussions on this thread or elsewhere since that time have pointed me to a solution. The people who say they got around it did so in ways that tend to avoid the problem rather than elucidate it. Can I, for instance, create an executable that declares a sufficiently large amount of static array space, and run it (directly from Windows, not from a CygWin shell) as a startup program before any other CygWin process starts, so that *it* loads the CygWin DLL at a high enough address? If I do this, do I need to keep it running as long as the system is up? -- 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/