Cygwin: fork: reserve dynloaded dll areas earlier

In dll_crt0_0, both threadinterface->Init and sigproc_init allocate
windows object handles using unpredictable memory regions, which may
collide with dynamically loaded dlls when they were relocated.

diff --git a/winsup/cygwin/dcrt0.cc b/winsup/cygwin/dcrt0.cc
index 11edcdf0d21bb5bde8caec0e2145e19e5f713d83..fb726a739ccfb9dd56508093b59d39f674ba5c95 100644 (file)
--- a/winsup/cygwin/dcrt0.cc
+++ b/winsup/cygwin/dcrt0.cc
@@ -632,6 +632,12 @@ child_info_fork::handle_fork ()
 
   if (fixup_mmaps_after_fork (parent))
     api_fatal ("recreate_mmaps_after_fork_failed");
+
+  /* We need to occupy the address space for dynamically loaded dlls
+     before we allocate any dynamic object, or we may end up with
+     error "address space needed by <dll> is already occupied"
+     for no good reason (seen with some relocated dll). */
+  dlls.reserve_space ();
 }
 
 bool

diff --git a/winsup/cygwin/fork.cc b/winsup/cygwin/fork.cc
index 74ee9acf43d56c62716f7e642d827b3cbce09db8..7e1c08990f5a9ca54e8f2302b781a9ea2876fea5 100644 (file)
--- a/winsup/cygwin/fork.cc
+++ b/winsup/cygwin/fork.cc
@@ -136,12 +136,6 @@ frok::child (volatile char * volatile here)
 {
   HANDLE& hParent = ch.parent;
 
-  /* NOTE: Logically this belongs in dll_list::load_after_fork, but by
-     doing it here, before the first sync_with_parent, we can exploit
-     the existing retry mechanism in hopes of getting a more favorable
-     address space layout next time. */
-  dlls.reserve_space ();
-
   sync_with_parent ("after longjmp", true);
   debug_printf ("child is running.  pid %d, ppid %d, stack here %p",
                myself->pid, myself->ppid, __builtin_frame_address (0));