| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Change-Id: I83681d2191bf4184e52d84d1107d61065927bb24
|
| |
|
|
|
| |
Bug: 227801493
Change-Id: I85630fe11b42d8d45ce63f279bb0fbcc635f8afb
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
I accidentally made the tests run MAX_RETRIES times instead of
running once when passing, and at most MAX_RETRIES when the
test fails. Also, add a bit of randomness to the usleep to try and
avoid tests syncing up on failures.
Bug: 193898572
Test: Ran unit tests and verified that a pass doesn't result in another run.
Test: Ran three copies of the unit tests at the same time to verify that
Test: there isn't a flaky test failure.
Change-Id: I8b8d3cd05ca7d1e87ce34bf10aeef84f6989fdab
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Refactor the code a bit to allow retrying if a log message is missing.
This is because there is a possibility of a log message getting dropped.
If that happens, merely rerun up to three times and pass if the missing
message is present.
Also fix a race condition that can occur if the LogReader threads are
being terminated but happen to be allocating memory while they are
in the signal handler. This situation causes aborts in the memory
allocator or a deadlock. Before this change, the verify_leak*
tests would fail in less than twenty iterations. After, I could run
for hundreds of iterations.
Bug: 193898572
Test: Ran unit tests in a loop.
Change-Id: I0fb5beab6041dcf3e3fd19f6748bb20bb81a2506
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These tests can be flaky if something is spamming the log and
expiring messages. Previously, the log wasn't read until the
forked process was complete. Now, two threads are spawned right
after the process forks to read the log while running. This
should avoid any problems if the log is being spammed while the
test runs.
In addition, fixed some potential flakiness in the test that might
occur if the test incorrectly gets stale log data.
Bug: 193898572
Test: All unit tests pass on cuttlefish (both 32 bit and 64 bit).
Test: Forced an abort and verified that the crash log reader sees
Test: the message.
Test: Verified that the log reader for the main and crash log properly
Test: read data.
Test: Verified the test passes while swamping the log by running
Test: the log unit tests while running two copies of the system
Test: tests.
Change-Id: I68bd92a8c483eac0146ada87dd4201dda0902c49
|
| |
|
|
|
|
|
|
|
|
|
| |
This is a follow-on to commit 5358cc40ab4288ed00c223f00cf898b7dc1a9484.
I forgot that there were two places the undefined behavior could occur.
Make the literal unsigned in the other place.
Test: TreeHugger
Bug: 189541929
Change-Id: Iaef81507ca61e802d277246bf5995157c93d86ce
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Technically, shifting a signed value beyond its maximum range is
undefined behavior in C++. A bare integer literal is signed, and
defaults to 'int'. On platforms where 'int' is 32-bits, we
shift outside this range with 1 << 31.
We make our literal an unsigned integer to avoid this.
Test: TreeHugger
Bug: 189541929
Change-Id: Iade1bcd3f86d025dd6e10c26622d10c26e2c8295
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
