| gtest |
|
|
2 % |
| moz.build |
|
2852 |
- |
| TestArray.cpp |
|
977 |
100 % |
| TestArrayUtils.cpp |
|
11541 |
100 % |
| TestAtomicBitfields.cpp |
|
8280 |
100 % |
| TestAtomics.cpp |
|
9016 |
100 % |
| TestBinarySearch.cpp |
|
5619 |
100 % |
| TestBitSet.cpp |
|
9775 |
100 % |
| TestBloomFilter.cpp |
|
4303 |
100 % |
| TestBoundedMPSCQueue.cpp |
|
5193 |
0 % |
| TestBufferList.cpp |
|
13173 |
98 % |
| TestCasting.cpp |
|
17223 |
100 % |
| TestCeilingFloor.cpp |
|
2428 |
100 % |
| TestCheckedInt.cpp |
Addition / subtraction checks |
18329 |
97 % |
| TestCompactPair.cpp |
|
6321 |
100 % |
| TestCountPopulation.cpp |
|
1253 |
100 % |
| TestCountZeroes.cpp |
|
4832 |
100 % |
| TestDefineEnum.cpp |
|
3024 |
100 % |
| TestDoublyLinkedList.cpp |
|
7687 |
98 % |
| TestEndian.cpp |
|
20636 |
100 % |
| TestEnumeratedArray.cpp |
|
1808 |
100 % |
| TestEnumSet.cpp |
|
9370 |
99 % |
| TestEnumTypeTraits.cpp |
Feature check for EnumTypeFitsWithin. |
5704 |
100 % |
| 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 |
100 % |
| TestFloatingPoint.cpp |
|
28438 |
98 % |
| TestFunctionRef.cpp |
|
3963 |
100 % |
| TestFunctionTypeTraits.cpp |
|
7982 |
78 % |
| TestHashTable.cpp |
|
5360 |
76 % |
| TestIntegerRange.cpp |
|
5475 |
100 % |
| TestJSONWriter.cpp |
|
15076 |
99 % |
| TestLinkedList.cpp |
|
9709 |
99 % |
| TestMacroArgs.cpp |
|
1930 |
100 % |
| TestMacroForEach.cpp |
|
1883 |
100 % |
| TestMathAlgorithms.cpp |
|
37900 |
100 % |
| TestMaybe.cpp |
|
61381 |
98 % |
| TestMozCrash.cpp |
|
1992 |
61 % |
| TestNonDereferenceable.cpp |
|
5572 |
100 % |
| TestNotNull.cpp |
|
12964 |
99 % |
| 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 |
64 % |
| 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 |
100 % |
| TestRange.cpp |
|
943 |
14 % |
| TestRefPtr.cpp |
|
3152 |
100 % |
| TestResult.cpp |
|
25697 |
97 % |
| TestRollingMean.cpp |
|
2531 |
97 % |
| TestSaturate.cpp |
|
4302 |
100 % |
| TestScopeExit.cpp |
|
1308 |
96 % |
| TestSegmentedVector.cpp |
|
11930 |
98 % |
| TestSHA1.cpp |
|
14084 |
100 % |
| TestSIMD.cpp |
|
28115 |
87 % |
| TestSmallPointerArray.cpp |
|
6736 |
96 % |
| TestSplayTree.cpp |
|
9503 |
100 % |
| TestSPSCQueue.cpp |
Generate a monotonically increasing sequence of numbers. |
8083 |
97 % |
| TestTextUtils.cpp |
|
45568 |
100 % |
| TestThreadSafeWeakPtr.cpp |
|
3928 |
100 % |
| TestTypedEnum.cpp |
|
17857 |
99 % |
| TestUniquePtr.cpp |
|
13222 |
97 % |
| TestUtf8.cpp |
|
26076 |
99 % |
| TestVariant.cpp |
|
47614 |
100 % |
| TestVector.cpp |
|
22960 |
100 % |
| TestWeakPtr.cpp |
|
4348 |
100 % |
| TestWinArchDefs.cpp |
|
1418 |
100 % |
| TestWrappingOperations.cpp |
|
25913 |
100 % |
| TestXorShift128PlusRNG.cpp |
|
3034 |
100 % |