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


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/


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