Mail Archives: cygwin/2005/09/01/12:33:27
It appears that even if two dlopen'ed dlls are completely abutting in
memory, the fork code nonetheless goes and appends a struct dll to the end
of each.
This causes no trouble in the parent, since when we append the struct to
the end of the first (lower base address) dll's allocation, we're only
overwriting the MZ header of the mapped dll image for the second dll, but it
causes trouble in the child, since that memory space then ends up being
allocated before the second dll tries to load, forcing it to rebase upward
to the next allocation granularity boundary, and causing that error message
that we all know and love.
I'm guessing - but haven't yet verified - that each dll's INIT section is
freed after it first gets loaded and attached to the process, and that this
is why the parent was able to allocate the space that is where the second
dll's MZ header previously lived for the struct dll that goes after the
first dll; I think this situation only arises when the dlls get loaded in
top-down order in the parent (second one first), but get loaded in bottom-up
order in the child. OTOH, I can't see how this situation would arise;
dlopen'ed dlls seem to be appended to the end of the dll list, and the child
seems to run from start to end of the list, so they _ought_ to all be
allocated in the same order.
This leaves me with two questions:
1- Why does the struct dll have to be appended as close as possible to the
actual dll itself? Is it actually functionally necessary, or does it make
something else similar? I thought at first that maybe it was so it could be
copied over by fork_copy, but that doesn't seem to happen. Is the idea that
it's more likely to end up in the same place in the child if we have the
same set of dlls in the same places and therefore to try and avoid having it
eat memory that would be needed for the fork'ed copy of anything else from
the parent's address space?
2- Would it be worth sorting the dll list in descending order of base
address, so that dlls are always loaded from the top-of-memory downward in
child processes, or is there some gotcha to that that I haven't seen yet?
cheers,
DaveK
--
Can't think of a witty .sigline today....
--
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/
- Raw text -