X-Spam-Check-By: sourceware.org Message-ID: <43FB3B58.93DA866@dessent.net> Date: Tue, 21 Feb 2006 08:10:00 -0800 From: Brian Dessent MIME-Version: 1.0 To: cygwin AT cygwin DOT com Subject: Re: cygheap base mismatch detected References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Reply-To: cygwin AT cygwin DOT com 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 "Dill, Jens (END-CHI)" wrote: > 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): FYI, to check the ImageBase of a given DLL you can just use objdump, e.g.: objdump -p /bin/cygwin1.dll | \ perl -ne 'print "$1\n" if /ImageBase\s+(\S+)/' To see the memory layout of a running process you can use Process Explorer from sysinternals.com which shows you in realtime the image base and the relocated (actual) address where each DLL ended up loading. > (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). I'm not sure that this is possible. It's kind of the heart of the "fork error: unable to remap" problem since the memory layout for dynamically loaded modules that haven't been rebased seems to be indeterminite. Thus the creation of the rebaseall tool and assigning unique addresses to all DLLs so that the layout is invariant. 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. And for examples of how the rebase arguments are formatted, look at the source to rebaseall (which is just a bourne script.) > (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. 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. Without any OS assistance this is kind of an ugly task, and it breaks if things radically change from parent -> child. It does have some capability to do fixups to move stuff around but I'm not sure it can cope with the Cygwin DLL itself loading in a different region. Brian -- 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/