Backed out changeset a5f51c76930c (bug 1483865) for bustages in builds/worker/workspace/build/src/xpcom/components/nsComponentManager.cpp on a CLOSED TREE
authorshindli <shindli@mozilla.com>
Wed, 22 Aug 2018 21:31:45 +0300
changeset 481189 dfc1e2e0156dde85cc9ca40a1e4ba3bf2d1bb60d
parent 481188 a5f51c76930c49160bf5e909301d8e7f1a83e379
child 481190 a981419137d9ba16d0b1ce7423e39e4a4ec113de
push id232
push userfmarier@mozilla.com
push dateWed, 05 Sep 2018 20:45:54 +0000
bugs1483865
milestone63.0a1
backs outa5f51c76930c49160bf5e909301d8e7f1a83e379
Backed out changeset a5f51c76930c (bug 1483865) for bustages in builds/worker/workspace/build/src/xpcom/components/nsComponentManager.cpp on a CLOSED TREE
xpcom/components/nsComponentManager.cpp
--- a/xpcom/components/nsComponentManager.cpp
+++ b/xpcom/components/nsComponentManager.cpp
@@ -475,41 +475,24 @@ AssertNotMallocAllocated(T* aPtr)
   MOZ_ASSERT(info.tag == TagUnknown);
 #endif
 }
 
 template<typename T>
 static void
 AssertNotStackAllocated(T* aPtr)
 {
-  // On all of our supported platforms, the stack grows down. Any address
-  // located below the address of our argument is therefore guaranteed not to be
-  // stack-allocated by the caller.
-  //
-  // For addresses above our argument, things get trickier. The main thread
-  // stack is traditionally placed at the top of the program's address space,
-  // but that is becoming less reliable as more and more systems adopt address
-  // space layout randomization strategies, so we have to guess how much space
-  // above our argument pointer we need to care about.
-  //
-  // On most systems, we're guaranteed at least several KiB at the top of each
-  // stack for TLS. We'd probably be safe assuming at least 4KiB in the stack
-  // segment above our argument address, but safer is... well, safer.
-  //
-  // For threads with huge stacks, it's theoretically possible that we could
-  // wind up being passed a stack-allocated string from farther up the stack,
-  // but this is a best-effort thing, so we'll assume we only care about the
-  // immediate caller. For that case, max 2KiB per stack frame is probably a
-  // reasonable guess most of the time, and is less than the ~4KiB that we
-  // expect for TLS, so go with that to avoid the risk of bumping into heap
-  // data just above the stack.
-  static constexpr size_t kFuzz = 2048;
-
-  MOZ_ASSERT(uintptr_t(aPtr) < uintptr_t(&aPtr) ||
-             uintptr_t(aPtr) > uintptr_t(&aPtr) + kFuzz);
+  // The main thread's stack should be allocated at the top of our address
+  // space. Anything stack allocated should be above us on the stack, and
+  // therefore above our first argument pointer.
+  // Only this is apparently not the case on Windows.
+#if !(defined(XP_WIN) || defined(ANDROID))
+  MOZ_ASSERT(NS_IsMainThread());
+  MOZ_ASSERT(uintptr_t(aPtr) < uintptr_t(&aPtr));
+#endif
 }
 
 static inline nsCString
 AsLiteralCString(const char* aStr)
 {
   AssertNotMallocAllocated(aStr);
   AssertNotStackAllocated(aStr);