firefox-main/mfbt/tests
Name Description Size Coverage
gtest -
moz.build 3213 -
TestAlgorithm.cpp 2317 -
TestArray.cpp 958 -
TestArrayUtils.cpp 11541 -
TestAtomicBitfields.cpp 8280 -
TestAtomics.cpp 9016 -
TestBinarySearch.cpp 5619 -
TestBitSet.cpp 9775 -
TestBloomFilter.cpp 4303 -
TestBoundedMPSCQueue.cpp 5193 -
TestBufferList.cpp 13173 -
TestCasting.cpp 17223 -
TestCeilingFloor.cpp 2428 -
TestCheckedInt.cpp Addition / subtraction checks 18329 -
TestCompactPair.cpp 6321 -
TestCountPopulation.cpp 1253 -
TestCountZeroes.cpp 4832 -
TestDefineEnum.cpp 3024 -
TestDoublyLinkedList.cpp 7687 -
TestEndian.cpp 20636 -
TestEnumeratedArray.cpp 1808 -
TestEnumSet.cpp 9370 -
TestEnumTypeTraits.cpp Feature check for EnumTypeFitsWithin. 5704 -
TestFastBernoulliTrial.cpp FastBernoulliTrial takes care to avoid screwing up on edge cases. The checks here all look pretty dumb, but they exercise paths in the code that could exhibit undefined behavior if coded naïvely. 5436 -
TestFloatingPoint.cpp 28438 -
TestFunctionRef.cpp 3963 -
TestFunctionTypeTraits.cpp 7982 -
TestHashTable.cpp 5360 -
TestIntegerRange.cpp 5475 -
TestJSONWriter.cpp 15076 -
TestLinkedList.cpp 9709 -
TestMacroArgs.cpp 1930 -
TestMacroForEach.cpp 1883 -
TestMathAlgorithms.cpp 37900 -
TestMaybe.cpp 61381 -
TestMozCrash.cpp 1992 -
TestNonDereferenceable.cpp 5572 -
TestNotNull.cpp 12945 -
TestPoisonArea.cpp Code in this file needs to be kept in sync with code in nsPresArena.cpp. We want to use a fixed address for frame poisoning so that it is readily identifiable in crash dumps. Whether such an address is available without any special setup depends on the system configuration. All current 64-bit CPUs (with the possible exception of PowerPC64) reserve the vast majority of the virtual address space for future hardware extensions; valid addresses must be below some break point between 2**48 and 2**54, depending on exactly which chip you have. Some chips (notably amd64) also allow the use of the *highest* 2**48 -- 2**54 addresses. Thus, if user space pointers are 64 bits wide, we can just use an address outside this range, and no more is required. To accommodate the chips that allow very high addresses to be valid, the value chosen is close to 2**63 (that is, in the middle of the space). In most cases, a purely 32-bit operating system must reserve some fraction of the address space for its own use. Contemporary 32-bit OSes tend to take the high gigabyte or so (0xC000_0000 on up). If we can prove that high addresses are reserved to the kernel, we can use an address in that region. Unfortunately, not all 32-bit OSes do this; OSX 10.4 might not, and it is unclear what mobile OSes are like (some 32-bit CPUs make it very easy for the kernel to exist in its own private address space). Furthermore, when a 32-bit user space process is running on a 64-bit kernel, the operating system has no need to reserve any of the space that the process can see, and generally does not do so. This is the scenario of greatest concern, since it covers all contemporary OSX iterations (10.5+) as well as Windows Vista and 7 on newer amd64 hardware. Linux on amd64 is generally run as a pure 64-bit environment, but its 32-bit compatibility mode also has this property. Thus, when user space pointers are 32 bits wide, we need to validate our chosen address, and possibly *make* it a good poison address by allocating a page around it and marking it inaccessible. The algorithm for this is: 1. Attempt to make the page surrounding the poison address a reserved, inaccessible memory region using OS primitives. On Windows, this is done with VirtualAlloc(MEM_RESERVE); on Unix, mmap(PROT_NONE). 2. If mmap/VirtualAlloc failed, there are two possible reasons: either the region is reserved to the kernel and no further action is required, or there is already usable memory in this area and we have to pick a different address. The tricky part is knowing which case we have, without attempting to access the region. On Windows, we rely on GetSystemInfo()'s reported upper and lower bounds of the application memory area. On Unix, there is nothing devoted to the purpose, but seeing if madvise() fails is close enough (it *might* disrupt someone else's use of the memory region, but not by as much as anything else available). Be aware of these gotchas: 1. We cannot use mmap() with MAP_FIXED. MAP_FIXED is defined to _replace_ any existing mapping in the region, if necessary to satisfy the request. Obviously, as we are blindly attempting to acquire a page at a constant address, we must not do this, lest we overwrite someone else's allocation. 2. For the same reason, we cannot blindly use mprotect() if mmap() fails. 3. madvise() may fail when applied to a 'magic' memory region provided as a kernel/user interface. Fortunately, the only such case I know about is the "vsyscall" area (not to be confused with the "vdso" area) for *64*-bit processes on Linux - and we don't even run this code for 64-bit processes. 4. VirtualQuery() does not produce any useful information if applied to kernel memory - in fact, it doesn't write its output at all. Thus, it is not used here. 18061 -
TestRandomNum.cpp We're going to check that random number generation is sane on a basic level - That is, we want to check that the function returns success and doesn't just keep returning the same number. Note that there are many more tests that could be done, but to really test a PRNG we'd probably need to generate a large set of randoms and perform statistical analysis on them. Maybe that's worth doing eventually? For now we should be fine just performing a dumb test of generating 5 numbers and making sure they're all unique. In theory, it is possible for this test to report a false negative, but with 5 numbers the probability is less than one-in-a-trillion. 1987 -
TestRange.cpp 943 -
TestRefPtr.cpp 3152 -
TestResult.cpp 25697 -
TestRollingMean.cpp 2531 -
TestSaturate.cpp 4302 -
TestScopeExit.cpp 1308 -
TestSegmentedVector.cpp 11930 -
TestSHA1.cpp 14084 -
TestSIMD.cpp 28115 -
TestSmallPointerArray.cpp 6736 -
TestSplayTree.cpp 9503 -
TestSPSCQueue.cpp Generate a monotonically increasing sequence of numbers. 8064 -
TestTextUtils.cpp 45568 -
TestThreadSafeWeakPtr.cpp 3928 -
TestTypedEnum.cpp 17857 -
TestUniquePtr.cpp 13222 -
TestUtf8.cpp 26076 -
TestVariant.cpp 47614 -
TestVector.cpp 22960 -
TestWeakPtr.cpp 4348 -
TestWinArchDefs.cpp 1418 -
TestWrappingOperations.cpp 25913 -
TestXorShift128PlusRNG.cpp 3034 -