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 From: "Dave Korn" To: Subject: That old 'unable to remap %s to same address as parent' forking dll problem. Date: Thu, 1 Sep 2005 17:33:15 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: 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/