This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: cygheap base mismatch detected

On Mar  1 11:59, marco atzeri wrote:
> On Thu, Mar 1, 2012 at 11:51 AM, Corinna Vinschen wrote:
> > On Feb 29 14:30, Charles Wilson wrote:
> >> I've been running into a strange "error" lately (that is, I first
> >> noticed it for sure on 1.7.10, but it MIGHT have occurred also on 1.7.9.
> >> It persists on 1.7.11). cygcheck -- and *only* cygcheck -- is reporting
> >> a cygheap base mismatch but only on an XP64 machine:
> >>
> >> $ cygcheck -cd cygwin
> >> Â Â Â 1 [main] cygcheck (3756) C:\cygwin\bin\cygcheck.exe: *** fatal
> >> error - cygheap base mismatch detected - 0x61270870/0x2170870.
> >> 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.
> >> Cygwin Package Information
> >> Package       ÂVersion
> >> cygwin        1.7.11-1
> >>
> >> (Note that cygcheck actually *does* complete the requested command,
> >> after the error message from (cygwin1.dll/ is printed.
> >
> > Very strange. ÂFor two reasons. ÂFirst of all, why is the mismatch
> > message printed at all? ÂThe code in question is basically:
> >
> > Âif (res->cygheap != (void *) &_cygheap_start)
> > Â Âmultiple_cygwin_problem (...);
> 0x61270870 != 0x2170870

Oh, right.  I only read the last few digits.  Sorry.

Hmm.  cygcheck loads the Cygwin DLL dynamically.  It does not depend on
any other Cygwin distro DLL.  But it's started from a Cygwin parent.  So
the loaded CYgwin DLL checks the layout just like it had been linked
against.  And apparently it gets rebased at load time.  Which means to
me, there's another DLL already loaded into the process at an address
which overlaps with the address space the Cygwin DLL should have been
loaded to.

So I guess you just have to find out what is the cause for rebasing
the Cygwin DLL.  Try VMMap from sysinternals with a cygcheck -svr piped
into less, so that you can easily observe the process in vmmap.


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

Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]