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


Mark Geisert writes:
> >I can't do more without learning a lot more than I currently know
> >about the internals of DLLs and of rebase.
>
> You have the "problem" Oracle DLLs, we don't :-) so you might be the
> only one who can ultimately solve the problem.  But see below...

Right.  But you (collectively) have the knowledge of the internal
workings of DLLs, the Windows, loader, and rebase, which I am struggling
to learn as fast as I can.  I'm hoping for a partnership here.  You
tell me what to look for.  I do the grunt work.  Together we build
something that gets CygWin past this problem.

I have found Microsoft's Platform SDK, and have used the VaDump utility
to find out where all the DLL's are loaded.  Here is what it says about
my app (sorted into ascending order of memory address):

Symbols loaded: 00210000 : 00390000  cygwin1.dll
Symbols loaded: 00400000 : 050F2000  acqjob.exe
Symbols loaded: 06100000 : 0638A000  orageneric9.dll
Symbols loaded: 60020000 : 60030000  MSVCIRT.dll
Symbols loaded: 60500000 : 60592000  oracommon9.dll
Symbols loaded: 60600000 : 6078D000  oraclient9.dll
Symbols loaded: 60800000 : 60806000  oravsn9.dll
Symbols loaded: 60810000 : 60816000  orawtc9.dll
Symbols loaded: 60A00000 : 60D21000  orapls9.dll
Symbols loaded: 610A0000 : 61140000  oracore9.dll
Symbols loaded: 612A0000 : 6131A000  oranls9.dll
Symbols loaded: 61350000 : 61360000  orasnls9.dll
Symbols loaded: 613A0000 : 613B1000  oraunls9.dll
Symbols loaded: 61400000 : 6142C000  oranl9.dll
Symbols loaded: 61480000 : 61535000  oran9.dll
Symbols loaded: 615A0000 : 6162F000  orannzsbb9.dll
Symbols loaded: 616A0000 : 616A6000  orancds9.dll
Symbols loaded: 616B0000 : 616C6000  orancrypt9.dll
Symbols loaded: 61730000 : 61767000  oranro9.dll
Symbols loaded: 617C0000 : 617C6000  oranhost9.dll
Symbols loaded: 617D0000 : 617D6000  oranoname9.dll
Symbols loaded: 61820000 : 61827000  orantns9.dll
Symbols loaded: 61960000 : 61973000  oranldap9.dll
Symbols loaded: 62000000 : 62024000  oraldapclnt9.dll
Symbols loaded: 62300000 : 6233E000  ORATRACE9.dll
Symbols loaded: 62500000 : 62507000  oraslax9.dll
Symbols loaded: 62600000 : 62677000  orasql9.dll
Symbols loaded: 62FC0000 : 6303F000  oraxml9.dll
Symbols loaded: 630F0000 : 6311A000  oraxsd9.dll
Symbols loaded: 64000000 : 64007000  oranms.dll
Symbols loaded: 64020000 : 64031000  oranmsp.dll
Symbols loaded: 68CD0000 : 69543000  cygicudt34.dll
Symbols loaded: 69560000 : 69679000  cygicuuc34.dll
Symbols loaded: 69690000 : 69A4D000  cygxerces-c27.dll
Symbols loaded: 71BB0000 : 71BB9000  WSOCK32.dll
Symbols loaded: 71BC0000 : 71BC8000  rdpsnd.dll
Symbols loaded: 71BF0000 : 71BF8000  WS2HELP.dll
Symbols loaded: 71C00000 : 71C17000  WS2_32.dll
Symbols loaded: 71C40000 : 71C98000  NETAPI32.dll
Symbols loaded: 76AA0000 : 76ACD000  WINMM.dll
Symbols loaded: 76B70000 : 76B7B000  PSAPI.DLL
Symbols loaded: 76F50000 : 76F63000  Secur32.dll
Symbols loaded: 771F0000 : 77201000  WINSTA.dll
Symbols loaded: 77380000 : 77412000  USER32.dll
Symbols loaded: 77670000 : 777A4000  ole32.dll
Symbols loaded: 77BA0000 : 77BFA000  MSVCRT.dll
Symbols loaded: 77C00000 : 77C48000  GDI32.dll
Symbols loaded: 77C50000 : 77CEF000  RPCRT4.dll
Symbols loaded: 77D00000 : 77D8C000  OLEAUT32.dll
Symbols loaded: 77E40000 : 77F42000  kernel32.dll
Symbols loaded: 77F50000 : 77FEC000  ADVAPI32.dll
Symbols loaded: 7C800000 : 7C8C0000  ntdll.dll

Here is what it says about a plain bash shell:

Symbols loaded: 00400000 : 00474000  bash.exe          equivalent
Symbols loaded: 61000000 : 61180000  cygwin1.dll       very, very, different
Symbols loaded: 6DB70000 : 6DBAD000  cygncurses-8.dll  not used above
Symbols loaded: 6DF90000 : 6DF9D000  cygintl-3.dll     not used above
Symbols loaded: 6E010000 : 6E102000  cygiconv-2.dll    not used above
Symbols loaded: 703C0000 : 703EC000  cygreadline6.dll  not used above
Symbols loaded: 71B20000 : 71B61000  mswsock.dll       not used above
Symbols loaded: 71BF0000 : 71BF8000  WS2HELP.dll       same as above
Symbols loaded: 71C00000 : 71C17000  ws2_32.dll        same as above
Symbols loaded: 76ED0000 : 76EF9000  DNSAPI.dll        not used above
Symbols loaded: 76F10000 : 76F3E000  WLDAP32.dll       not used above
Symbols loaded: 76F50000 : 76F63000  Secur32.dll       same as above
Symbols loaded: 76F70000 : 76F77000  winrnr.dll        not used above
Symbols loaded: 77380000 : 77412000  USER32.dll        same as above
Symbols loaded: 77BA0000 : 77BFA000  msvcrt.dll        same as above
Symbols loaded: 77C00000 : 77C48000  GDI32.dll         same as above
Symbols loaded: 77C50000 : 77CEF000  RPCRT4.dll        same as above
Symbols loaded: 77E40000 : 77F42000  kernel32.dll      same as above
Symbols loaded: 77F50000 : 77FEC000  ADVAPI32.DLL      same as above
Symbols loaded: 7C800000 : 7C8C0000  ntdll.dll         same as above

It is apparent to me that the Oracle DLLs got loaded first.
They filled up all the space normally claimed by CygWin, and
when they got down to the magic limit around 0x60000000, 
jumped into the heap space just above the end of the program
image to load the final Oracle DLL (orageneric9.dll).  When
the CygWin DLL came up for consideration, it somehow got put
into the space just *before* the main executable image.  Odd.

I haven't yet laid my hands on anything that fully documents
Windows memory layout assumptions, so I am somewhat hobbled
in interpreting these addresses.  

It is clear to me that the problem could be solved if
I could figure out how to reliably do any of the following:

(1)  Force the CygWin DLL to load first, so that it bumps the
     Oracle DLLs and not vice versa.  (I'd need a reliable way
     to ensure this, not just a chance dependency on how the
     loader currently operates).

(2)  Rebase the CygWin DLL so that it loads by default into a
     space not used in either memory map (I'd need help in 
     choosing such a space).  I've tried both Microsoft's
     rebase and CygWin's rebase, but the documentation for both
     is scanty (how is the -b argument to be formatted -- a hex
     number with 0x in front or without?), and the error messages
     I get in response are not helpful (error 6?).

(3)  Fix CygWin so that it does not care if the DLL is relocated
     during a process swap.  The offending component is something
     called "cygheap".  I can infer that this is a space in which
     CygWin processes store some kind of state information that
     must (a) survive a process swap, and (b) still be addressable
     by pointers that can't be relocated.  Surely there's a better
     way to do this, but I'd need weeks of study to find one.  I
     can apparently (according to the source code (dcrt0.cc, line 
     1177) disable the whole thing by setting the CYGWIN_MISMATCH_OK 
     environment variable, but I have so far found no documentation 
     of the risks and implications of doing so.

I'd be glad of any help you can give with any of the above.

Mark further writes:
> Forgive me for possibly reading more into your text than you intended
> and thus responding inappropriately, but, Cygwin is an all-volunteer 
> and essentially non-managed project. (No offense Christopher :-) 
> There are no *guarantees* about anything. If Cygwin works for you, that's
great.
> It is possible though that it won't work for you and for any of various 
> reasons specific to each volunteer, can't or won't be made to work for 
> you in any particular timeframe.

Forgive me for having taken umbrage at that statement.  I've been a
professional software developer for thirty years.  I am well aware of
these things and shouldn't need to be told.  I have gone way out on a
limb trying to convince my management that CygWin is a better way of
doing things and has been around long enough to be mature enough to
work for us.  When I first read this, it seemed to say to me "We know
CygWin is not ready for prime time, and we're proud of it."

On rereading, I realize that that wasn't your intent.  You get a lot
of newbies on the list who do need to be told the basics.  I am at
fault, myself, for ranting about my troubles with management without
giving _you_ sufficient context to understand.

> How to present the situation to your management is something we can't 
> answer. I would say, though, perhaps your management could consider a 
> Cygwin support contract with Red Hat in order to get fixes for
> problems you run into. It might be worth it if Cygwin is truly the 
> only way to accomplish your technical goals.

Management is, indeed considering a CygWin support contract.  That's the
only thing that would work for them.  But they are moving slowly on this.
They want to see the product working before committing to it.  _Our_
customers have quite often demanded fom us fixes up front for things like 
this as a condition written into the contract under penalty of withholding 
of payment.  I have nudged Management to talk to Red Hat about what is
available in pre-sales support.  

In the meantime, I have you folks.  I can use any help I can get.

                                          -- Jens

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


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