This is the mail archive of the cygwin-cvs@cygwin.com 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]

[newlib-cygwin] Cygwin: fix heap allocation on WOW64 and /3GB enabled 32 bit machines


https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=a091d5da63f6711fe046e2a0f63d917e3b5254d4

commit a091d5da63f6711fe046e2a0f63d917e3b5254d4
Author: Corinna Vinschen <corinna@vinschen.de>
Date:   Wed Dec 19 21:10:37 2018 +0100

    Cygwin: fix heap allocation on WOW64 and /3GB enabled 32 bit machines
    
    The check for the TEB being allocated beyond the first 2GB area is not
    valid anymore.  At least on W10 WOW64, the TEB is allocated in the
    lower 2GB even in large-address aware executables.  Use VirtualQuery
    instead.  It fails for invalid addresses so that's a simple enough test.
    
    Signed-off-by: Corinna Vinschen <corinna@vinschen.de>

Diff:
---
 winsup/cygwin/heap.cc | 28 +++++++++++++++++-----------
 1 file changed, 17 insertions(+), 11 deletions(-)

diff --git a/winsup/cygwin/heap.cc b/winsup/cygwin/heap.cc
index 18145d2..e18cd55 100644
--- a/winsup/cygwin/heap.cc
+++ b/winsup/cygwin/heap.cc
@@ -44,22 +44,28 @@ eval_start_address ()
      starting at 0x20000000.  This should work right from the start in 99%
      of the cases. */
   uintptr_t start_address = 0x20000000L;
-  if ((uintptr_t) NtCurrentTeb () >= 0xbf000000L)
+  MEMORY_BASIC_INFORMATION mbi;
+
+  if (VirtualQuery ((void *) 0xbf000000L, &mbi, sizeof mbi))
     {
       /* However, if we're running on a /3GB enabled 32 bit system or on
 	 a 64 bit system, and the executable is large address aware, then
 	 we know that we have spare 1 Gig (32 bit) or even 2 Gigs (64 bit)
 	 virtual address space.  This memory region is practically unused
-	 by Windows, only PEB and TEBs are allocated top-down here.  We use
-	 the current TEB address as very simple test that this is a large
-	 address aware executable.
-	 The above test for an address beyond 0xbf000000 is supposed to
-	 make sure that we really have 3GB on a 32 bit system.  Windows
-	 supports smaller large address regions, but then it's not that
-	 interesting for us to use it for the heap.
-	 If the region is big enough, the heap gets allocated at its
-	 start.  What we get are 0.999 or 1.999 Gigs of free contiguous
-	 memory for heap, thread stacks, and shared memory regions. */
+	 by Windows, only PEB and TEBs are allocated top-down here.
+
+	 We used to use the current TEB address as very simple test that
+	 this is a large address aware executable, but that fails on W10
+	 WOW64 because the main TEB is apparently commited in the lower
+	 2 Gigs these days.
+
+	 The above test for address 0xbf000000 is supposed to make sure
+	 that we really have 3GB on a 32 bit system.  Windows supports
+	 smaller large address regions, but then it's not that interesting
+	 for us to use it for the heap.  If the region is big enough, the
+	 heap gets allocated at its start.  What we get are 0.999 or 1.999
+	 Gigs of free contiguous memory for heap, thread stacks, and shared
+	 memory regions. */
       start_address = 0x80000000L;
     }
 #endif


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