Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: cygheap base mismatch detected - only on Vista x64, not  seen on Vista x86
Date: Wed, 22 Nov 2006 12:36:26 -0800
Message-ID: <09BFF2FA5EAB4A45B6655E151BBDD90302767A23@NT-IRVA-0750.brcm.ad.broadcom.com>
In-Reply-To: <20061122130338.GF8333@calimero.vinschen.de>
From: "Joseph Koenig" <jkoenig AT broadcom DOT com>
To: cygwin AT cygwin DOT com
Content-Type: text/plain;  charset=us-ascii
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Content-Transfer-Encoding: 8bit

Congrats on figuring the problem out so quickly. Forgive my lack of
familiarity with the cygwin development process (and cygwin in general),
but as you've seemingly isolated root cause, do you feel that a point
fix should be forthcoming shortly or do you feel as though this problem
might persist for some time? Also, do you believe that fixing this
problem in the cygwin dll will solve the extent of vista
incompatibilities or do you think that Vista64 functionality is going to
require additional fixes? 

Yes, it's sort of a request to speculate a bit, but I'm trying to
ascertain whether I should continue my little project on Vista32 for a
short while until a Vista64 fix or if I should abandon my project that
triggered this bug in the first place.

Regards,
Joe


-----Original Message-----
From: cygwin-owner AT cygwin DOT com [mailto:cygwin-owner AT cygwin dot com] On
Behalf Of Corinna Vinschen
Sent: Wednesday, November 22, 2006 5:04 AM
To: cygwin AT cygwin DOT com
Subject: Re: cygheap base mismatch detected - only on Vista x64, not
seen on Vista x86

On Nov 17 18:29, Joseph Koenig wrote:
> DISCLAIMER: Yes, I realize Vista is not officially supported. If
anything I hope this e-mail will end up in the archives to prevent other
uses who see this same problem from wasting time if there is no war
available. 
> 
> I have successfully used cygwin on Vista32 with no problems. 
> On Vista64 I can complete the install but I have errors when I try to
execute basic commands, such as ls.
> This is with Vista RTM.
> 
> Some useful info:
> The error message:: I actually receive this several times at various
entry points to main, but I'll just paste it once:
> 
> bash-3.2$ ls
>       5 [main] ? (1376) D:\cygwin\bin\bash.exe: *** fatal error -
cygheap base m
> ismatch detected - 0x0/0x611828F0.
> This problem is probably due to using incompatible versions of the
cygwin DLL.
> Search for cygwin1.dll using the Windows Start->Find/Search facility
> and delete all but the most recent version.  The most recent version
*should*
> reside in x:\cygwin\bin, where 'x' is the drive on which you have
> installed the cygwin distribution.  Rebooting is also suggested if you
> are unable to find another cygwin DLL.
>       3 [main] bash 2032 fork: child -1 - died waiting for longjmp
before initia
> lization, retry 0, exit code 0x100, errno 11
> bash: fork: Resource temporarily unavailable

I have mixed news on this issue.  The good news is, it's quite easy to
reproduce since it occurs all the time, so I started to debug this.  The
bad news is that I have no idea why happens what happens.

What happens is this:

Basically, when forking a process Cygwin calls CreateProcess, starting
the current application another time and then parent and child fiddle
with the shared handles and memory to give the child an up-to-date,
forked-like outfit.

This however requires a way to propagate information to the child
process
which allows the child to do certain actions at a very early stage of
initialization.  The way to do this is to utilize the STARTUPINFO given
to the CreateProcess call.  One parameter in there is called
lpReserved2,
which is, for instance, also used by the MSVCRT C runtime library to
propagte information to child processes.

Well, we are our own C runtime.  Cygwin processes are not linked against
MSVCRT for that reason, so it's safe to use lpReserved2 for our own,
dubious purposes.  The child calls the GetStartupInfo function and gets
all information needed.

Not so under Vista x64.  The child calls GetStartupInfo and gets a valid
result, with an apparently also valid lpReserved2 pointer.  At least the
pointer points to something valid within the child's address space.
Unfortunately, what it points to is only filled with zeros.  The
information
expected at this point is just not there anymore.  This in turn leads
to the above result.

So far I know that it has nothing to do with being started by a 64 bit
process and I also know that this is not a generic problem with the
lpReserved2 member in Vista WOW64 processes. as a simple testcase(tm)
showed.

So, as for the why... I'm quite puzzeled.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
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/


--
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/