firefox-main/mfbt/tests
Name Description Size Coverage
gtest -
moz.build 2713 -
TestArray.cpp 856 -
TestArrayUtils.cpp 11420 -
TestAtomicBitfields.cpp 8159 -
TestAtomics.cpp 8895 -
TestBinarySearch.cpp 5498 -
TestBitSet.cpp 11285 -
TestBloomFilter.cpp 4182 -
TestBoundedMPSCQueue.cpp 5052 -
TestBufferList.cpp 13052 -
TestCasting.cpp no support 18758 -
TestCeilingFloor.cpp 2307 -
TestCheckedInt.cpp Addition / subtraction checks 18329 -
TestCompactPair.cpp 6200 -
TestDefineEnum.cpp 2903 -
TestDoublyLinkedList.cpp 7566 -
TestEndian.cpp 21016 -
TestEnumeratedArray.cpp 1687 -
TestEnumSet.cpp 9249 -
TestEnumTypeTraits.cpp Feature check for EnumTypeFitsWithin. 5624 -
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. 5315 -
TestFloatingPoint.cpp 28317 -
TestFunctionRef.cpp 3842 -
TestFunctionTypeTraits.cpp 7861 -
TestHashTable.cpp 5239 -
TestIntegerRange.cpp 5354 -
TestJSONWriter.cpp 14955 -
TestLinkedList.cpp 9587 -
TestMacroArgs.cpp 1809 -
TestMacroForEach.cpp 1762 -
TestMathAlgorithms.cpp 34877 -
TestMaybe.cpp 61301 -
TestMozCrash.cpp 1871 -
TestNonDereferenceable.cpp 5451 -
TestNotNull.cpp 12843 -
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. 17940 -
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. 1866 -
TestRange.cpp 822 -
TestRefPtr.cpp 3031 -
TestResult.cpp 25576 -
TestRollingMean.cpp 2410 -
TestSaturate.cpp 4181 -
TestScopeExit.cpp 1187 -
TestSegmentedVector.cpp 11809 -
TestSHA1.cpp 13963 -
TestSIMD.cpp 27994 -
TestSmallPointerArray.cpp 6615 -
TestSplayTree.cpp 9382 -
TestSPSCQueue.cpp Generate a monotonically increasing sequence of numbers. 7962 -
TestTextUtils.cpp 45447 -
TestThreadSafeWeakPtr.cpp 3807 -
TestTypedEnum.cpp 17736 -
TestUniquePtr.cpp 13101 -
TestUtf8.cpp 25955 -
TestVariant.cpp 47493 -
TestVector.cpp 22839 -
TestWeakPtr.cpp 4227 -
TestWinArchDefs.cpp 1297 -
TestWrappingOperations.cpp 25792 -
TestXorShift128PlusRNG.cpp 2913 -