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 11:24:12 -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 Brian Dessent writes: >I think your best bet would be to keep poking at rebase to see if you >can't actually rebase the Oracle DLLs. > >> (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?). > >There's no need to rebase cygwin1.dll. You can just change the base >address assigned to it when it's created. This is defined in cygwin.def >which is a generated file from cygwin.din. This is helpful, but I need more detail. Attempts to rebase the Oracle DLLs haven't worked. The CygWin rebase does not properly understand the image format: it assumes the pe_signature_offset is always 0x0080 instead of loading it from 0x003c in the image. I have not enough information to figure out all the places that need to be fixed in the rebase code before it can handle the Oracle DLLs, none of which have signatures at 0x0080. Rebasing cygwin1.dll _looks_ easier, since I only have to work with one DLL instead of a few dozen. Changing the base address when the DLL is created assumes I am prepared to have our installers install CygWin from source. It would seem to me to be easier to install CygWin out of the box and run a simple rebase script, if I could get such a script to work. It should be possible. RebaseAll doesn't appear to be what I need, since it will only do the right thing if Rebase will work on the Oracle DLLs. So I need a targeted rebase command, which means that I need to have a way to tell it what address to use for the base. For that, I need a clearer picture of the memory layout. o Do I need to worry about colliding with space allocated for the stack or the heap, or do those assignments get done _after_ all DLLs have been loaded? I'm talking here about DLLs that are identified at link time, and clearly visible in the cygcheck listing. o Is there anything special about space below 0x60000000 (where Oracle DLLs stopped occupying high memory and jumped to just after the program image)? o Is there anything special about space below 0x00400000 (where the Cygwin DLL was loaded after the Oracle DLLs had grabbed the preferred space at 0x61000000)? o Can I just put the CygWin DLL into any large-enough gap between the other DLLs that is not used in either parent or child processes? (The largest such gap I see is between 0x69a50000 and 0x71BB0000). Is this the safest bet? >The problem here is that in order to emulate fork(), the Cygwin DLL >needs to be able to recreate a given memory layout when spawning a copy >of the process. OK, but how come it also happens when you do an "exec" without a "fork"? "exec" is supposed to assume the memory layout is completely fresh, and we shouldn't need to worry about copying all the things we need to copy when forking. -- 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/