Make RefBase more robust and debuggable
This prevents two different kinds of client errors from causing undetected memory corruption, and helps with the detection of others: 1. We no longer deallocate objects when the weak count goes to zero and there have been no strong references. This otherwise causes us to return a garbage object from a constructor if the constructor allocates and deallocates a weak pointer to this. And we do know that clients allocate such weak pointers in constructors and their lifetime is hard to trace. 2. We abort if a RefBase object is explicitly destroyed while the weak count is nonzero. Otherwise a subsequent decrement would cause a write to potentially reallocated memory. 3. We check counter values returned by atomic decrements for plausibility, and fail immediately if they are not plausible. We unconditionally log any cases in which 1 changes behavior from before. We abort in cases in which 2 changes behavior, since those reflect clear bugs. In case 1, a log message now indicates a possible leak. We have not seen such a message in practice. The third point introduces a small amount of overhead into the reference count decrement path. But this should be negligible compared to the actual decrement cost. Add a test for promote/attemptIncStrong that tries to check for both (1) above and concurrent operation of attemptIncStrong. Add some additional warnings and explanations to the RefBase documentation. Bug: 30503444 Bug: 30292291 Bug: 30292538 Change-Id: Ida92b9a2e247f543a948a75d221fbc0038dea66c
Loading
Please register or sign in to comment