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 0358efe4f7)
getEntryInfo crashes on 64-bit devices because "long" types
were being passed int pointers (that pointed to a stack frame)
that were reinterpret_cast'ed to long* (sigh.). To fix this issue
once and for all, use types with explicitly defined widths.
This change also removes some dead invariant checking from
Asset.cpp instead of cleaning it up.
Note that we've introduced a wart in NativeLibraryHelper, where
we need to deal with zlib's uLong type, which is "at least 32 bits
wide".
bug: 21622286
Change-Id: Iae675a9601db7aae03a8b80b40321d2cc1d97f50
