X-Spam-Check-By: sourceware.org Message-ID: From: "Dill, Jens (END-CHI)" To: cygwin AT cygwin DOT com Subject: RE: cygheap base mismatch detected Date: Tue, 21 Feb 2006 09:25:45 -0600 MIME-Version: 1.0 Content-Type: text/plain Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com 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/