Historically, Android defaulted to EXPLICIT but with a special case
because SCHED_NORMAL/priority 0 was awkward. Because the code couldn't
actually tell whether SCHED_NORMAL/priority 0 was a genuine attempt to
explicitly set those attributes (because the parent thread is SCHED_FIFO,
say) or just because the pthread_attr_t was left at its defaults.
Now we support INHERIT, we could call sched_getscheduler to see whether
we actually need to call sched_setscheduler, but since the major cost
is the fixed syscall overhead, we may as well just conservatively
call sched_setscheduler and let the kernel decide whether it's a
no-op. (Especially because we'd then have to add both sched_getscheduler
and sched_setscheduler to any seccomp filter.)
Platform code (or app code that only needs to support >= P) can actually
add a call to pthread_attr_setinheritsched to say that they just want
to inherit (if they know that none of their threads actually mess with
scheduler attributes at all), which will save them a sched_setscheduler
call except in the doubly-special case of SCHED_RESET_ON_FORK (which we
do handle).
An alternative would be "make pthread_attr_setschedparams and
pthread_attr_setschedprio set EXPLICIT and change the platform default
to INHERIT", but even though I can only think of weird pathological
examples where anyone would notice that change, that behavior -- of
pthread_attr_setschedparams/pthread_attr_setschedprio overriding an
earlier call to pthread_attr_setinheritsched -- isn't allowed by POSIX
(whereas defaulting to EXPLICIT is).
If we have a lot of trouble with this change in the app compatibility
testing phase, though, we'll want to reconsider this decision!
-*-
This change also removes a comment about setting the scheduler attributes
in main_thread because we'd have to actually keep them up to date,
and it's not clear that doing so would be worth the trouble.
Also make async_safe_format_log preserve errno so we don't have to be
so careful around it.
Bug: http://b/67471710
Test: ran tests
Change-Id: Idd026c4ce78a536656adcb57aa2e7b2c616eeddf
e210488e0d in 2013 added this, which seems
to have been a workaround for the linker at the time that was never removed.
Bug: N/A
Test: ran tests
Change-Id: I171c3f4b7c34638ab75b8e49616b3a9c24ab3fcb
Some declarations, like bitfield members, don't need identifiers.
Bug: https://github.com/android-ndk/ndk/issues/440
Test: ran versioner with -x c++ on a manually reduced <linux/timex.h>
Change-Id: Ic7eea780762cff653c54fdde4d10df203d630c25
PauseTiming and ResumeTiming are thread-local, and unbalanced calls to
them leads to obviously bogus results like:
Benchmark Time CPU Iterations
-----------------------------------------------------------------
BM_pthread_exit_and_join 212600 ns 59981418 ns 12
BM_pthread_create_and_run 212997341 ns -1569132344 ns 1000
Bug: http://b/68170209
Test: ran bionic benchmarks
Change-Id: Ia88cd6af9ff524443850d834a96cf5dd9c7f3ed9
And add more tests.
Bug: N/A (but I'm here because a recent test broke existing tests)
Test: ran tests
Change-Id: Ib78430f179b43484a49bb50ff447ea6870c1ee3a
Applications fopening files and then blindly trying to read are
widespread, leading to a recurring problem of SELinux tightening
resulting in segfaults. Add a friendly diagnostic for this case.
Bug: http://b/67455242
Test: bionic-unit-tests32/64 on sailfish
Change-Id: I1734fa94487c4eff9b55a02c6b01baf6b265d236
The only explanation for this and the unistd_test failures is that I
wasn't actually running the code I thought I was. There are some unrelated
netdb_test failures still to come...
Bug: N/A
Test: ran tests
Change-Id: I91af9d2d6a42f5433fa27e7cd8f5b903e1af36ba
A previous change added new assertions about these, but didn't remove
these old now-invalid assertions.
Bug: http://b/68133223
Test: ran tests
Change-Id: Ib6ce6e5f7abe143f2c871e074e7fd51faaf452ac
Added a test to make sure linker produces correct error message
when user attempts to load a library in a linked namespace and fails.
Bug: http://b/67866190
Bug: http://b/64950640
Bug: http://b/64888291
Test: bionic-unit-test --gtest_filter=dlext*
Change-Id: I5b5c2070d1388eff123118350b2b5c8fc7571a29
vector::erase(iterator) erases the element that that iterator points
to, vector::erase(iterator a, iterator b) erases the range [a, b), with
a == b being a no-op.
Test: LD_PRELOAD=libc.so sh
Change-Id: I6a85c1cfaa8eb67756cb75d421f332d5c9a43a33
The permitted and search paths should be changed according to VNDK
version for VNDK snapshot. So, {VNDK_VER} value is added in ld.config.txt
file and this value is set through the linker.
If ro.vndk.version is not set, search paths are vndk and vndk-sp as
before.
Bug: 66074376
Test: build & run
Change-Id: I266b66fe1bc95d8925053ef497db11ac0a57c082
