Poison was setup at the start of xpcom init when that was assumed to be early enough.
Since then, Poison was added to Maybe, and Maybe has been used everywhere, including in
our channel implementation. As a result, poison was being used before it was initialized.
This basically meant our poison pointers were being replaced with null instead, which
dances into some more UB than accessing a page we have actually allocated. Also, tsan
noticed that accesses to the value were racing with the initializer actually being
called!
A (dynamic) static initializer forces the poison initialization as we can reasonably
hope without getting CallOnce or singleton patterns involved.
Other changes:
* Cleaned up the outdated documentation for mozWritePoison (the alignment
restriction was removed in Bug 1414901)
* Removed the poison supression from TSan
Differential Revision: https://phabricator.services.mozilla.com/D94251
This adds 'CorruptionCanaryForStatics', which as the name implies is suitable
for use in objects that are statically declared. It has a trivial destructor
which allows us to avoid the need for static constructors.
--HG--
extra : amend_source : 27f8eff9ead21fde9f5f5d17f16c322d2c995a27
mozWritePoison secretly depended on the passed-in pointer being aligned
as though it were a pointer to uintptr_t, as it used bare stores to
C-casted pointers to accomplish poisoning. But this is an unnecessary
limitation: we can use memcpy and rely on the compiler to appropriately
inline the store to an unaligned store instruction if necessary.
The documentation for mozWritePoison says that only an even number of
sizeof(uintptr_t) bytes are overwritten; any trailing bytes are not
touched. This documentation doesn't correspond to how the function
actually works. The function as written will happily overwrite trailing
bytes and any bytes not contained in the object, if the passed-in size
isn't divisible by sizeof(uintptr_t). Let's fix that.