Fix race with Asset destruction and printing allocation stats
A race could occur when printing the list of Asset allocations for debugging purposes. Each Asset object would insert themselves into a global linked list on construction and remove themselves on destruction. Iterating the list and the insertion/remove operations all acquire a global lock. The race occurs after the Asset subclass destructor runs but before the Asset base class destructor runs, which performs the actual removal from the list. The vtable of the object being destroyed ends up pointing at the base Asset class' vtable, and during the iteration of the global list, a pure virtual method is called leading to an abort, since the wrong vtable is dereferenced. This change moves the insertion/removal of the Asset object into the global list to the concrete class, which adds some maintenance overhead but solves the problem. Bug:31113965 Test: make libandroidfw_tests Change-Id: I1a620897e5e04a8519ee247883bba0719b1fa6f3 (cherry picked from commit 0358efe4)
Loading
Please register or sign in to comment