| Age | Commit message (Collapse) | Author |
|---|
|
When the main thread is exiting, the code deleted the g_debug global
pointer and destroys the disable pthread key. Unfortunately, if
malloc debug was enabled in a way that requires a header for the pointer,
any frees that occur after the main thread is torn down result in calls
to the underlying allocator with bad pointers.
To avoid this, don't delete the g_debug pointer and don't destroy the
disable pthread key.
Added a new system test that allocates a lot of pointers and frees them
after letting the main thread finish.
Also, fix one test that can fail sporadically due to a lack of unwinding
information on arm32.
Bug: 189541929
Test: Passes new system tests.
Change-Id: I1cfe868987a8f0dc880a5b65de6709f44a5f1988
Merged-In: I1cfe868987a8f0dc880a5b65de6709f44a5f1988
(cherry picked from commit 33d73379aad3ed7dcbb9b10f945d3bc6264b79bd)
|
|
When malloc debug is enabled, using libbacktrace to unwind can
result in a deadlock. This happens when an unwind of a thread
is occuring which triggers a signal to be sent to that thread. If
that thread is interrupted while a malloc debug function is
executing and owns a lock, that thread is then stuck in the signal
handler. Then the original unwinding thread attempts to do an
allocation and gets stuck waiting for the same malloc debug lock.
This is not a complete deadlock since the unwinder has timeouts,
but it results in truncated unwinds that take at least five
seconds to complete.
Only the backtrace signals needs to be blocked because it is the only
known signal that will result in a thread being paused in a signal
handler.
Also, added a named signal in the reserved signal list for the
special bionic backtrace signal.
Bug: 150833265
Test: New unit tests pass with fix, fail without fix.
Change-Id: If3e41f092ebd40ce62a59ef51d636a91bc31ed80
|
|
log/log.h is concerned with writing logs.
Bug: 78370064
Test: build
Change-Id: I03d35f47acaa6eb0c8865836767d855be0203e92
|
|
This macro hasn't been meaningful in years.
Test: logging unit tests
Change-Id: I849a466052524c24f1dba585a6423e80198c6b9c
|
|
malloc debug and malloc hooks have been broken for a long time
and no one noticed. So add them to be run by default on bionic
changes since that provides the most coverage.
Change the malloc debug and malloc hooks tests to support isolated
runs.
Changed the name of the malloc hooks unit tests to system tests
because they weren't really unit tests.
Changed the verify leak malloc debug tests to print out extra
information so it is possible to figure out what sized allocation
failed.
Test: Ran tests.
Change-Id: Idea4c864f1d62598148ee78d7c9397e45234b1ca
|
|
When using a FILE object for some malloc debug functions, calling
fprintf will trigger an allocation to be put in the object. The problem
is that these allocations were not allocated by the malloc debug
wrapper and they get freed during the fclose as if they are malloc
debug allocation. In most cases, the code will detect the bad pointer
and leak the memory, but it might also cause a crash.
The fix is to avoid using fprintf so that no allocations are made
in the object that survive and need to be freed in the fclose call.
Change the MallocXmlElem.h to use a file decsriptor not a FILE object.
Add new unit and system tests to detect this case.
Bug: 143742907
Test: Ran unit and system tests.
Test: Ran bionic unit tests.
Change-Id: I524392de822a29483aa5be8f14c680e70033eba2
|
|
Instead of having platform directories directly include the
private header, create a platform header directory and export it.
Bug: 130763340
Test: Builds.
Change-Id: Ie0f092b3fe077a3de8b90266c0b28bfbc20d0dfa
Merged-In: Ie0f092b3fe077a3de8b90266c0b28bfbc20d0dfa
(cherry picked from commit 8f582ef2f8a77d953d0e9f33387f592d20f852e2)
|
|
I wrote a new unit test that would fail on the old version of the
code.
On a walleye big cpu, this costs about 40ns-50ns (going from ~430ns to ~480ns).
I think this is an acceptable performance degradation.
Bug: 131867816
Test: New unit tests pass.
Change-Id: I4c0f4373fb0694bf29c3824dbb1224a8a17e211e
|
|
Add a new option verbose for malloc debug that is not enabled by default.
This disables all of the info log messages. It turns out these log
messages can add a measurable amount of time and can change the boot up.
Bug: 129239269
Test: Adjusted unit tests pass.
Test: Verified no messages unless verbose option used.
Change-Id: I805cb7c8ecb44de88119574e59d784877cacc383
|
|
Introduce an M_SET_ALLOCATION_LIMIT enumerator for android_mallopt(),
which can be used to set an upper bound on the total size of all
allocations made using the memory allocation APIs.
This is useful for programs such as audioextractor and mediaserver
which need to set such a limit as a security mitigation. Currently
these programs are using setrlimit(RLIMIT_AS) which isn't exactly
what these programs want to control. RLIMIT_AS is also problematic
under sanitizers which allocate large amounts of address space as
shadow memory, and is especially problematic under shadow call stack,
which requires 16MB of address space per thread.
Add new unit tests for bionic.
Add new unit tests for malloc debug that verify that when the limit
is enabled, malloc debug still functions for nearly every allocation
function.
Bug: 118642754
Test: Ran bionic-unit-tests/bionic-unit-tests-static.
Test: Ran malloc debug tests and perfetto integration tests.
Change-Id: I735403c4d2c87f00fb2cdef81d00af0af446b2bb
|
|
There is a hang when enabling leak_track since the dumping of the
leak data can wind up doing an allocation.
Add new system unit test to make sure this doesn't happen again.
Bug: 111146059
Test: Test program that leaks does not hang forever.
Test: Unit tests pass.
Change-Id: Icf99be58ba5db98ee124a471b957a086045f5870
|
