Re: cygheap base mismatch detected - only on Vista x64, not seen on Vista x86

[Corinna Vinschen <corinna-cygwin at cygwin dot com>]

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/