Using the AndroidLocalUnwinder object allows unwinding interpreter
and JIT'd frames by default. In addition, it simplifies the code.
Test: Forced interpreter on all of the time and forced fdtrack on
Test: and verified unwind includes dex frames.
Test: Forced JIT on all of the time and forced fdtrack on
Test: and verified unwind includes dex frames.
Test: Unit tests pass.
Change-Id: Icae17e83c9aaa04750b07471243550a7829524f7
Trying to find a leak this year, it was very annoying that our traces
were mostly filled with "junk" frames from the JNI implementation,
making it quite a struggle to see what the actual calling code was...
Bug: http://b/236197847
Test: treehugger
Change-Id: I69e7d9b6432e1872e238168ebf3dc36feb7de7df
Modify libfdtrack to use the normal Unwinder object. In addition,
update the libfdtrack so that it doesn't record frames in
libfdtrack.so rather than skipping frames it thinks will be in
the library.
Modify the malloc debug code to use the normal Unwinder object.
Bug: 120606663
Test: All unit tests pass.
Change-Id: I3c9612dd10e62389e6219e68045ee87f7b2625f5
Also delete some fdsan code that attempts to check for the post-fork
state, but never will, because we update the cached pid upon fork.
Bug: http://b/174542867
Test: /data/nativetest64/bionic-unit-tests/bionic-unit-tests
Test: treehugger
Change-Id: I9b748dac9de9b4c741897d93e64d31737e52bf8e
Auto-generate NOTICE files for all the directories, and for each one
individually rather than mixing libc and libm together.
Test: N/A
Change-Id: I7e251194a8805c4ca78fcc5675c3321bcd5abf0a
There's a bad interaction with malloc_debug when the libraries are being
destroyed.
Bug: https://issuetracker.google.com/154439915
Test: treehugger
Change-Id: Ib47c8139c3a88dd52865ea93654b2926bd708729
When dump fdsan fd owner, happen NE. This because the format specifier
flag '#' is not supported by Bionic out_vformat<BufferOutputStream>.
Bug: 153611483
Test: jmgao@ verified manually
Change-Id: I7191c3b2b621ddcc0397874f8a69391e58232ac8
Add a hook that's called upon file descriptor creation to libc, and a
library that uses it to capture backtraces for file descriptor creation,
to make it easier to hunt down file descriptor leaks.
Currently, this doesn't capture all of the ways of creating a file
descriptor, but completeness isn't required for this to be useful as
long as leaked file descriptors are created with a function that is
tracked. The primary unhandled case is binder, which receives file
descriptors as a payload in a not-trivially-parsable byte blob, but
there's a chance that the leak we're currently trying to track down
isn't of a file descriptor received over binder, so leave that for
later.
Bug: http://b/140703823
Test: manual
Change-Id: I308a14c2e234cdba4207157b634ab6b8bc539dd9
(cherry picked from commit b7eccd4b15)
