A linker namespace lives longer than its caller. It is never deleted
once created in a process. Currently, the pointer to the name is simply
copied which results dangling reference when the name is actually from
temporary objects like std::object. Fixing the issue by strdup'ing the
name upon namespace creation.
Bug: 130388701
Test: atest CtsJniTestCases; the log does not show broken error messages
like
unexpected dlerror: dlopen failed: library "/system/lib64/android.frameworks.cameraservice.common@2.0.so" needed or dlopened by "/data/app/android.jni.cts-HP6GyGXYy5honHQAffUXgw==/lib/arm64/libjnitest.so" is not accessible for the namespace " mT?"
Change-Id: I25d9d76f8520f490755c189ded5659e6c9741f79
Bug: 123312263
Test: Verified with asan enabled, malloc debug does not initialize.
Test: Ran tests on non-asan build and verify they pass.
Change-Id: I3c37c170bf6c1de42740972f2113ae991351d931
On cf_x86_phone-userdebug, both of the unwind through signal
tests fail. This has been failing forever, but seems to have suddenly
become an issue, so disable while I try to figure out why this is happening.
Bug: 132763120
Test: Ran on emulator and verified tests are skipped.
Change-Id: Iafc227d972a7783e94c701d73078c9570cea288e
Merged-In: Iafc227d972a7783e94c701d73078c9570cea288e
(cherry picked from commit d424fafbce)
(cherry picked from commit fe0fbcff7f)
The arm exidx unwind information can be sparse and clang is producing
functions that cannot be properly represented. The .debug_frame includes
extra unwind information that covers the cases that are not complete, so
do not remove it. For example, the __strchr_chk function has a push
in the middle of the function, so any crash before that instruction will
not unwind properly.
This does increase the size of libc.so, but only by about 80,000 bytes.
Bug: 132992102
Test: Verified the .debug_frame exists in libc.so only for arm32.
Test: Used the unwind_reg_info to verify that __str_chk gets proper
Test: unwind info. Also use unwind_reg_info on some assembler functions
Test: to make sure that there is no overlapping information.
Change-Id: If9a6de15b3adf08a93c4563da8c89846e4dd059b
Add the malloc symbols used by libmemunreachable to the VNDK, and
make libc_malloc_debug_backtrace vendor_available.
Bug: 132302484
Test: m checkbuild
Change-Id: Ide555195afa084c13eaeaf0eab6ff90787b5f2d0
When parsing ld.config.txt, paths in *.search.paths properties are
resolved using resolved_paths(). This is causing a number of newfstatat
system calls during a process start-up and is contributing about 3.6%
of the entire linker initialization time.
Optimize the overhead by not resolving already resolved paths; resolved
paths are cached.
Bug: 132348336
Test: strace -C -e newfstatat ls shows the number of the syscalls is
reduced from 131 to 99
Test: simpleperf record --call-graph fp -f 10000000 -o /data/perf.data ls
simpleperf report -g -i /data/perf.data
shows percentage of get_paths() from 2.9% to 2.5%
Change-Id: I79823255a89f6e2a63b80c74e6768850276ab536
A proposed set of changes:
https://android-review.googlesource.com/q/topic:"no-dup-hwasans"
will cause the HWASAN runtime to be moved from /system/lib64 to
/system/lib64/bootstrap. This causes a problem in the case where libc is built
with HWASAN but init is not built with HWASAN. In this case, libc.so will have
a DT_NEEDED dependency on the HWASAN runtime but init will not. Currently,
init and other bootstrap executables arrange to load bootstrap libraries by
setting rpath, but rpath only has an effect on libraries directly depended
on by the main executable, not libraries indirectly depended on by it. This
means that the loading of the HWASAN runtime will fail.
Instead of relying on rpath to find the bootstrap libraries, modify the
bootstrap linker so that it searches the bootstrap library directory after
searching the rpath.
Change-Id: I297be32e04ecd316ee12b8e694588e1249e2bb89
Creating two huge buffers with std::vector, as it is now, is very
expensive, because it ends up being satisfied with mmap()/munmap().
Instead, we statically allocate a large string buffer while resizing
the other one to be a smaller and more appropriate size so that it can
be placed on the stack.
Note that this does mean that we increase linker data segment by 4KB
and that increases the overall system memory usage by about 400KB.
However, since that additional page is mostly zeroed with only some
ASCII text, it should be fairly easy to compress when it's swapped out
to ZRAM.
Test: Run with strace and observe no mmap/munmap around readlinkat().
Test: Measure average linker time of starting cameraserver on a Go
device and see ~3% speed-up.
Bug: 132783386
Change-Id: I600cc7a92be316ef67440a9a28c05d18de229f6c
getpwnam_r() and getpwuid_r() clobber the storage used by getpwnam()
and getpwuid(). This isn't likely to be a big issue, but since we do
this right for the group functions, fix this as well as add a test.
Both use more space in buf than is actually required, but well below
their sysconf() suggested values, so we accept that to keep the code
concise.
Add tests for dealing with unaligned input buffers, particularly for
getgrnam_r() and getgrgid_r(), as they require alignment but this
wasn't being tested.
Refactor common initialization code for both passwd and group state
structs.
Remove extraneous null pointer checks; the values they were testing
were offsets of a previous pointer, so guaranteed to never actually be
null. If the underlying pointer is actually null, we're beyond repair
anyway, so accept that we'll crash.
Test: pwd/grp unit tests
Change-Id: I60c4d00e9ab3cf55daf8314c5029fd914025b696
When building the bionic tests, we use -fno-builtins, which turns off
clang's recognition of vfork as a magical function that can return
twice. Explicitly annotate our returns_twice functions to ensure that
we generate correct code even in -fno-builtins (and while we're at it,
annotate the no_return functions as well, so we generate faster code).
Bug: http://b/131856005
Test: treehugger
Change-Id: I465f8042a965f0c7c03caa5f17af67deea8f5d9d
This patch decreases created threads to 90 (instead of 100)
on devices with 2 cores CPU. This test can fail with timeout
on such devices.
Bug: b/129924384
Test: Run CtsBionic module on 2 core device with command
"run cts -m CtsBionicTestCases"
Change-Id: Ic770006a324748d7d6dfbe8d4fb301e21e494ff9
Signed-off-by: Dmytro Chystiakov <dmytro.chystiakov@intel.com>
Given that we have both linker and linker64, I didn't really want to have
to have ldd and ldd64, so this change just adds the --list option to the
linkers and a shell script wrapper "ldd" that calls the appropriate
linker behind the scenes.
Test: adb shell linker --list `which app_process32`
Test: adb shell linker64 --list `which date`
Test: adb shell ldd `which app_process32`
Test: adb shell ldd `which date`
Change-Id: I33494bda1cc3cafee54e091f97c0f2ae52d1f74b
Added get_malloc_leak_info and free_malloc_leak_info for arm 32 bit
only so that the kindle app will continue to run.
Bug: 132175052
Test: Ran kindle app, read pdf file. Verified libKindleReaderJNI.so
Test: is loaded in memory properly.
Change-Id: Ib1ea3a37b3729f9bcc2739c5f3a584ea8f66d200
Merged-In: Ib1ea3a37b3729f9bcc2739c5f3a584ea8f66d200
(cherry picked from commit 235f35a266)
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
Without pulling in <linux/fs.h>, the UAPI source of these constants,
because it's full of pollution, in particular a macro called BLOCK_SIZE
that breaks a lot of stuff.
Test: treehugger
Change-Id: I7258ec57e91c67645c2b4d0ce44850d757c4bb12
