Bug 1690167 - Allocate some memory before running RandomNum tests. r=Gankra

Because the previous commit changed how MFBT tests are linked, they now
use mozjemalloc. Mozjemalloc randomizes small allocations, which id does
by using MFBT's RandomNum. The code in RandomNum, on mac, uses a system
API that allocates memory. So mozjemalloc has some code to handle the
recursion gracefully.

When the RandomNum test runs, it essentially only runs the RNG... which
goes on to allocate memory, which then goes into the RNG. Needless to
say, that doesn't go well. In typical cases, this is not the type of
things that would happen, but it does happen for that one test.

We work around the issue by allocating memory first, which is actually
hard, because compilers like to optimize unused allocations away. So we
turn the existing code into one that uses an allocation instead of an
array on the stack.

Differential Revision: https://phabricator.services.mozilla.com/D105242

mfbt/tests/TestRandomNum.cpp

@@ -5,6 +5,7 @@
  * You can obtain one at http://mozilla.org/MPL/2.0/. */
 
 #include "mozilla/RandomNum.h"
+#include <vector>
 
 /*
 
@@ -37,16 +38,20 @@ static uint64_t getRandomUint64OrDie() {
 }
 
 static void TestRandomUint64() {
-  uint64_t randomsList[NUM_RANDOMS_TO_GENERATE];
+  // The allocator uses RandomNum.h too, but its initialization path allocates
+  // memory. While the allocator itself handles the situation, we can't, so
+  // we make sure to use an allocation before getting a Random number ourselves.
+  std::vector<uint64_t> randomsList;
+  randomsList.reserve(NUM_RANDOMS_TO_GENERATE);
 
   for (uint8_t i = 0; i < NUM_RANDOMS_TO_GENERATE; ++i) {
     uint64_t randomNum = getRandomUint64OrDie();
 
-    for (uint8_t j = 0; j < i; ++j) {
-      MOZ_RELEASE_ASSERT(randomNum != randomsList[j]);
+    for (uint64_t num : randomsList) {
+      MOZ_RELEASE_ASSERT(randomNum != num);
     }
 
-    randomsList[i] = randomNum;
+    randomsList.push_back(randomNum);
   }
 }