Trying to send even 0 bytes to closed socket leads to
broken pipe error. Sometimes property service is just
quick enough and closes the socket between send(valuelen)
and send(value) in the case where valuelen is 0.
Bug: http://b/34670529
Test: adb reboot 20 times and make sure phone service did not fail
Test: run bionic-unit-tests --gtest_filter=prop*
Change-Id: I96f90ca6fe1790614e7efd3015bffed1ef1e9040
This change introduces new __system_property_read_callback
method to use in place of deprecated __system_property_read
__system_property_set() and get() should just work but now
do not have limit on system property names.
Bug: http://b/33926793
Test: boot device, run adb shell propget
Test: boot device with old version of init (protocol v1)
Test: run bionic-unit-tests --gtest_filter=prop*
Change-Id: I619fb5a7e27a272aac30011579665f6160888bc7
These functions are supposed to be used only by the
property service.
__system_property_find_nth is deprecated and no longer part
of NDK. Call to this function will result in abort for apps
targeting Android O.
Bug: http://b/34114501
Test: bionic-unit-tests --gtest_filter=prop*
Change-Id: I9846965bf248e2ddf45cd7b293618245bbd87145
Don't allow processes to read the contents of the directory
/dev/__properties__. This is an implementation detail of the properties
system that processes shouldn't be concerned with.
Test: Device boots and no problems reading individual properties.
Test: ls -la /dev/__properties__ fails
Change-Id: I00130fe4529525935654bff91e3cc59253b86e26
To support upcoming disk usage calculation optimizations, this change
creates a new GID for each app that will be used to mark its cached
data. We're allocating these unique GIDs so that we can use
quotactl() to track cached data on a per-app basis.
Test: builds, boots, tests pass
Bug: 27948817
Change-Id: Ic00c39ccedc23d5d43988029e9921679126f8f2d
Some of the function pointer types were wrong, and x86 cares if you
say `int` when you meant `int8_t` (because it feels at liberty to
leave the top bits dirty and ignore them, both sides need to agree
which they're dealing with).
Also slightly improve the wcstoimax and wcstoumax tests, since my
investigation started there.
Bug: http://b/33451822
Test: tests pass on x86, arm, and arm64
Change-Id: I553193962f0cb993666f9f8e415990bba5b669e1
Generate the android_ids array and include into the
build.
Test: The bionic is built and that core AIDs work as
expected with commands like chown, mkdir and init services
and builtins.
Bug: 27999086
Change-Id: Ib575bf85326c91801c5674db475dcb9cf44c00dc
Signed-off-by: William Roberts <william.c.roberts@intel.com>
<sys/limits.h> shouldn't even exist, but leave it in for backwards
compatibility.
Everything that seems legit moves to <limits.h>, though it still seems
like a lot of that ought to come from the compiler instead (there's even
an angry rant in the clang header to that effect).
Unfortunately, we've long exposed [a copy and paste of] the contents
of <float.h> from <limits.h> and <sys/limits.h>. This patch preserves
that for backwards compatibility, but at least switches us over to
using the real <float.h> instead.
Bug: http://b/32776472
Test: builds
Change-Id: I2d5b3b5237b3a0442195e99bb967c076ce484f35
Some PoS internal system can't cope with more than 4 stack frames,
so the fact that our abort(3) implementation takes 4 frames by itself
makes it useless.
Re-reading POSIX, it only says "behaves as if", so the previous
implementation chain wasn't mandatory and we can just go straight to
calling tgkill...
Before:
#00 pc 0000000000069be4 /system/lib64/libc.so (tgkill+8)
#01 pc 0000000000066d50 /system/lib64/libc.so (pthread_kill+64)
#02 pc 0000000000028110 /system/lib64/libc.so (raise+24)
#03 pc 000000000001d4ec /system/lib64/libc.so (abort+52)
After:
#00 pc 0000000000069bc8 /system/lib64/libc.so (tgkill+8)
#01 pc 000000000001d4c8 /system/lib64/libc.so (abort+80)
#02 pc 0000000000001494 /system/xbin/crasher64 (_ZL9do_actionPKc+872)
#03 pc 00000000000010e0 /system/xbin/crasher64 (main+88)
This is less useful on 32-bit ARM because there there's an extra trampoline
from an assembler abort(3) implementation, so you'll still only get one
meaningful stack frame. But every other architecture will now get two!
But wait!
It turns out that the assembler hack isn't needed any more. Here we are
unwinding just fine all the way through the 32-bit ARM crasher:
Before (with direct call to tgkill but still using the assembler):
#00 pc 00049e7c /system/lib/libc.so (tgkill+12)
#01 pc 00019c6f /system/lib/libc.so (__libc_android_abort+50)
#02 pc 000181f8 /system/lib/libc.so (abort+4)
#03 pc 00001025 /system/xbin/crasher (_ZL9do_actionPKc+656)
#04 pc 00017721 /system/lib/libc.so (__libc_init+48)
#05 pc 00000b38 /system/xbin/crasher (_start+96)
After:
#00 pc 00049e6c /system/lib/libc.so (tgkill+12)
#01 pc 00019c5f /system/lib/libc.so (abort+50)
#02 pc 00001025 /system/xbin/crasher (_ZL9do_actionPKc+656)
#03 pc 00017721 /system/lib/libc.so (__libc_init+48)
#04 pc 00000b38 /system/xbin/crasher (_start+96)
(As you can see, the fact that we see __libc_init rather than main was true
with the assembler stub too, so that's not a regression even if it does seem
odd...)
Bug: N/A
Test: ran crasher64
Change-Id: I9dd5b214c495604c8b502c7ec0de3631080d8c29
Let the caller know when libc has an entropy source and arc4random is safe.
This is useful for the callers that want entropy, but don't absolutely need it.
Bug: http://b/27729263
Test: booted angler-userdebug w/ safestack
Change-Id: Iab3050bd19f23518e1676629573eebc656ba1090
Pretty useless, because the POSIX APIs are useless for actually
internationalization, but it lets us put this to bed for good.
Bug: http://b/18492914
Test: bionic tests
Change-Id: I4dd0aff66c44b5547039be3ffea806c865b9014a
By default getrandom() blocks if the entropy pool has not yet been initialized.
This will be an issue when init was first executed in some kernels.
This CL makes a check of getrandom readyness, by adding the GRND_NONBLOCK flag.
In such case, getrandom() does not block returns -1 with errno set to EAGAIN.
Test: on M/S devices
Bug: 33059407
Change-Id: I2a2ba8372a5e1c336852ba2ab77cdaac03c90389
POSIX locale only, as usual.
The GNU YESSTR and NOSTR extensions return the empty string in the C locale,
so I haven't bothered supporting them.
Bug: http://b/1401872
Test: bionic tests
Change-Id: I6846839e4f9f1812344ed5dce0b93f83c0c20eb3
Previously malloc debug can be enabled only using global settings
accessible to the root user only. This CL adds a new option to enable
it using environment variables making it possible to use it with pure
native (shell) applications on production builds (from shell user) and
prepares it for using it from logwrapper on production devices.
Remove the old environment variable and property since they are not
necessary.
Test: Enable malloc debug using environment variable and verify
Test: that it only affects the commands launched from the shell.
Test: Enable malloc debug using the property variable and verify
Test: that it affects all commands.
Test: Run all unit tests in 32 bit and 64 bit.
Change-Id: Iecb75a3471552f619f196ad550c5f41fcd9ce8e5
For some program implementation, the pattern like below, calling
pthread_atfork to register atfork interfaces.
pthread_atfork(&atfork_prepare, &atfork_parent, &atfork_child);
When the program is expected to reopen the shared library's handle
inherited from parent in child process. Maybe, dlclose is called in
atfork_child to release the shared library handle before reopen it.
Then, dlclose will indrectly call _cxa_finalize and finaly call
__unregister_atfork when dso is not NULL.
atfork_child() -> dlclose() -> __on_dlclose()
-> __cxa_finalize() -> __unregister_atfork(dso)
In __unregister_atfork, firstly, it try to hold the g_atfork_list_mutex
lock to operate the g_atfork_list. Due to the registered atfork_child is
executed before resetting g_atfork_list_mutex lock in child, the child
process will be blocked here because of deadlock.
Test: bionic-unit-tests32 --gtest_filter=pthread.pthread_atfork_child_with_dlclose
without the fixing, the test will be timeout.
Change-Id: I35d3001682c836e0955d6d681bc5f9297fad0c7b
Signed-off-by: Mingwei Shi <mingwei.shi@intel.com>
Signed-off-by: Qiming Shi <qiming.shi@intel.com>
Signed-off-by: Chao Xie <chao.xie@intel.com>
This was previously done only in fork() and pthread_create(), but this left raw
clone() with an invalid cached tid. Since the tid is used for pthread routines,
this led to unstable behavior after clone().
Test: ltp clone01 (see bug for more)
Test: mmma bionic/tests
Test: bionic-unit-tests-static --gtest_filter=*fork*:*clone*
Bug: 32612735
Bug: 32305649
Change-Id: I30eae5a8024b4c5da65476fcadfe14c6db35bb79
The tid is cached in the pthread_internal_t and is properly re-set after fork()
and pthread_create(). But after a plain clone() the value is stale from the
parent.
Test: mmma bionic/tests
Test: bionic-unit-tests-static --gtest_filter=*fork*:*clone*
Test: m checkbuild tests
Test: angler boots
Bug: 32305649
Change-Id: I026d416d1537484cd3e05c8493a35e5ed2acc8ed
"ls -q" (or "adb shell -tt ls") was mangling non-ASCII because mbrtowc
was returning multibyte characters as their individual bytes. This was
because toybox asks for "" rather than "C.UTF-8", and for some reason
we were interpreting that as "C" rather than "C.UTF-8".
Test: bionic tests, ls
Change-Id: Ic60e3b90cd5fe689e5489fad0d5d91062b9594ed
