We saw crashes from pthread_exit+debuggerd on LP32
(https://issuetracker.google.com/72291624), and it seems like the
equivalent problem should exist with system(3). I fixed posix_spawn(3)
as part of that bug, so the easiest fix is probably to reuse that.
Bug: http://b/72470344
Test: ran tests
Change-Id: I05f838706f2b4a14ac3ee21292833e6c8579b0d4
For aarch64 only.
Once we activate support for vdso call for clock_getres, we also will
have to deal with kernel bugs in the implementation. If the kernel is
prior to the vdso unification of arm, aarch64 and aarch32, estimated
to land in 4.15, then the assembler implementation for aarch64 will
need two upstream kernel fixes e1b6b6ce and c80ed088. We report the
required url for the upstream kernel fixes upon test failure.
Test: bionic-unit-tests --gtest_filter=time.*
Bug: 20045882
Bug: 63737556
Bug: 69626243
Change-Id: Id93056f432491679e349545cbd1d682074634c58
Add clock_getres test combinations. Add clock_gettime_unknown test
to ensure the errno is propagated correctly for that call as well.
Test: bionic-unit-tests --gtest_filter=time.*
Bug: 63737556
Bug: 69626243
Change-Id: I0256b7f03ac7e57bc5b36069b13fe576c29b9c75
The newest of these clocks was added in Linux 2.6.12, so no need for runtime
checks.
Add CTS tests that we can actually use the various clocks.
Bug: http://b/67458266
Test: ran tests
Change-Id: I3cfd7982043d6f8d4ebdc2b29e8722334f443ce5
Another release, another attempt to remove the global thread list.
But this time, let's admit that it's not going away. We can switch to using
a read/write lock for the global thread list, and to aborting rather than
quietly returning ESRCH if we're given an invalid pthread_t.
This change affects pthread_detach, pthread_getcpuclockid,
pthread_getschedparam/pthread_setschedparam, pthread_join, and pthread_kill:
instead of returning ESRCH when passed an invalid pthread_t, if you're
targeting O or above, they'll abort with the message "attempt to use
invalid pthread_t".
Note that this doesn't change behavior as much as you might think: the old
lookup only held the global thread list lock for the duration of the lookup,
so there was still a race between that and the dereference in the caller,
given that callers actually need the tid to pass to some syscall or other,
and sometimes update fields in the pthread_internal_t struct too.
(This patch replaces such users with calls to pthread_gettid_np, which
at least makes the TOCTOU window smaller.)
We can't check thread->tid against 0 to see whether a pthread_t is still
valid because a dead thread gets its thread struct unmapped along with its
stack, so the dereference isn't safe.
Taking the affected functions one by one:
* pthread_getcpuclockid and pthread_getschedparam/pthread_setschedparam
should be fine. Unsafe calls to those seem highly unlikely.
* Unsafe pthread_detach callers probably want to switch to
pthread_attr_setdetachstate instead, or using
pthread_detach(pthread_self()) from the new thread's start routine
rather than doing the detach in the parent.
* pthread_join calls should be safe anyway, because a joinable thread
won't actually exit and unmap until it's joined. If you're joining an
unjoinable thread, the fix is to stop marking it detached. If you're
joining an already-joined thread, you need to rethink your design.
* Unsafe pthread_kill calls aren't portably fixable. (And are obviously
inherently non-portable as-is.) The best alternative on Android is to
use pthread_gettid_np at some point that you know the thread to be
alive, and then call kill/tgkill directly.
That's still not completely safe because if you're too late, the tid
may have been reused, but then your code is inherently unsafe anyway.
Bug: http://b/19636317
Test: ran tests
Change-Id: I0372c4428e8a7f1c3af5c9334f5d9c25f2c73f21
Another release, another attempt to fix this bug.
This change affects pthread_detach, pthread_getcpuclockid,
pthread_getschedparam/pthread_setschedparam, pthread_join, and pthread_kill:
instead of returning ESRCH when passed an invalid pthread_t, they'll now SEGV.
Note that this doesn't change behavior as much as you might think: the old
lookup only held the global thread list lock for the duration of the lookup,
so there was still a race between that and the dereference in the caller,
given that callers actually need the tid to pass to some syscall or other,
and sometimes update fields in the pthread_internal_t struct too.
We can't check thread->tid against 0 to see whether a pthread_t is still
valid because a dead thread gets its thread struct unmapped along with its
stack, so the dereference isn't safe.
Taking the affected functions one by one:
* pthread_getcpuclockid and pthread_getschedparam/pthread_setschedparam
should be fine. Unsafe calls to those seem highly unlikely.
* Unsafe pthread_detach callers probably want to switch to
pthread_attr_setdetachstate instead, or using pthread_detach(pthread_self())
from the new thread's start routine rather than doing the detach in the
parent.
* pthread_join calls should be safe anyway, because a joinable thread won't
actually exit and unmap until it's joined. If you're joining an
unjoinable thread, the fix is to stop marking it detached. If you're
joining an already-joined thread, you need to rethink your design.
* Unsafe pthread_kill calls aren't portably fixable. (And are obviously
inherently non-portable as-is.) The best alternative on Android is to
use pthread_gettid_np at some point that you know the thread to be alive,
and then call kill/tgkill directly. That's still not completely safe
because if you're too late, the tid may have been reused, but then your
code is inherently unsafe anyway.
If we find too much code is still broken, we can come back and disable
the global thread list lookups for anything targeting >= O and then have
another go at really removing this in P...
Bug: http://b/19636317
Test: N6P boots, bionic tests pass
Change-Id: Ia92641212f509344b99ee2a9bfab5383147fcba6
Times before 1901-12-13 *underflow* on LP32, making the year 1900 a bad
choice for success case.
Bug: http://b/31305222
Change-Id: I20d4885c80b57707225580db044abc8948a55fdc
POSIX makes "the CPU-time clock of the calling thread" (i.e.,
CLOCK_THREAD_CPUTIME_ID) a special case which returns EINVAL instead of
ENOTSUP.
However, the clock_nanosleep syscall treats this clock just like any
other, and returns -EOPNOTSUPP to indicate an unimplemented nanosleep
handler. So we need to handle this ourselves in userspace.
This change fixes the LTP clock_nanosleep01 testcase.
Change-Id: If3bed940d276834bcd114d8c17f96197e9384711
Signed-off-by: Greg Hackmann <ghackmann@google.com>
This is a common thing for people to want to do, snprintf requires
a lot of stack for itself, and PTHREAD_STACK_MIN should be usable
for realistic code.
Change-Id: Ib09cfb4e0beec1c69ee0944c3ea4c5d03a94c491
Upstream tzcode said "On platforms with tm_zone, strftime.c now assumes it
is not NULL". Which is fine for any struct tm generated by tzcode, but not
necessarily true of a struct tm constructed by arbitrary code. In particular,
Netflix on Nexus Player was failing to start because they format "%Z" with
a struct tm whose tm_zone is null (the other fields are valid, but, yeah,
that's probably not intentional).
glibc takes a null tm_zone to mean "the current time zone", so let's do that
too. (Historically Android would use the empty string, and POSIX doesn't
clarify which of this is the appropriate behavior when tm_zone is null.)
Bug: http://b/25170306
Change-Id: Idbf68bfe90d143aca7dada8607742905188b1d33
If TIMER_ABSTIME is used in timer_settime(), the timer is always fired
immediately, which is not the intent of the tests.
Change-Id: I76047dbeb2bdded272ee6d028630b53bfd7d8514
It is partically cherry-pick from https://android-review.googlesource.com/#/c/123410/.
And as lollipop-mr1-cts-dev still uses stlport, <stdatomic.h> is used instead of <atomic>.
Bug: 20677618
Change-Id: I952a6fd074facc4227c955fecf3ecbfbbaec4193
1. Don't prevent calling callback when SIGEV_THREAD timers are disarmed by timer_settime.
As in POSIX standard: The effect of disarming or resetting a timer with pending
expiration notifications is unspecified. And glibc didn't prevent in this situation, so I
think it is fine to remove the support.
2. Still prevent calling callback when SIGEV_THREAD timers are deleted by timer_delete.
As in POSIX standard: The disposition of pending signals for the deleted timer is unspecified.
However, glibc handles this (although that is not perfect). And some of our tests in
time_test.cpp depend on this feature as described in b/18039727. so I retain the support.
3. Fix some flaky test in time_test.cpp, and make "time*" test pass on bionic-unit-tests-glibcxx.
Bug: 18263854
Change-Id: I8ced184eacdbfcf433fd81b0c69c38824beb8ebc
There is a possible race if a timer is set to trigger at nearly the same
time as it is set. Since nobody uses the timers like this, modify the test
so this doesn't happen. The race that this can provoke has been fixed in
aosp.
Bug: 19423618
Change-Id: I21084c99da5ae46f404936d673dae6bad7c82caa
The mktime API returned an uncorrect time when TZ is set as empty.
A timezone UTC/GMT+0 should be implied in the empty case. However
mktime keeps previous information about timezone. If mktime was called
with a timezone which has DST before, the "defaulttype" member of
"state" structure wouldn't be 0. Then it would be used next time,
even though UTC/GMT+0 doesn't have DST.
Added initialization of the "defaulttype" in the empty TZ case.
Change-Id: Ic480c63c548c05444134e0aefb30a7b380e3f40b
When setting a repeat timer using the SIGEV_THREAD mechanism, it's possible
that the callback can be called after the timer is disarmed or deleted.
This happens because the kernel can generate signals that the timer thread
will continue to handle even after the timer is supposed to be off.
Add two new tests to verify that disarming/deleting doesn't continue to
call the callback.
Modify the repeat test to finish more quickly than before.
Refactor the Counter implementation a bit.
Bug: 18039727
(cherry pick from commit 0724132c32)
Change-Id: I135726ea4038a47920a6c511708813b1a9996c42
When setting a repeat timer using the SIGEV_THREAD mechanism, it's possible
that the callback can be called after the timer is disarmed or deleted.
This happens because the kernel can generate signals that the timer thread
will continue to handle even after the timer is supposed to be off.
Add two new tests to verify that disarming/deleting doesn't continue to
call the callback.
Modify the repeat test to finish more quickly than before.
Refactor the Counter implementation a bit.
Bug: 18039727
Change-Id: I73192c915cdacf608521b1792c54e5af14a34907
Add the missing prototypes, fix the existing prototypes to use clockid_t
rather than int, fix clock_nanosleep's failure behavior, and add simple
tests.
Bug: 17644443
Bug: https://code.google.com/p/android/issues/detail?id=77372
Change-Id: I03fba369939403918abcabae9551a7123953d780
Signed-off-by: Haruki Hasegawa <h6a.h4i.0@gmail.com>
Unlike times(), clock_gettime() is implemented as a vDSO on many architectures.
So, using clock_gettime() will return a more accurate time and do so with less
overhead because it does have the overhead of calling into the kernel.
It is also significantly more accurate because it measures the actual time in
nanoseconds rather than the number of ticks (typically 1 millisecond or more).
Bug: 17814435
Change-Id: Id4945d9f387330518f78669809639952e9227ed9
This way it's a lot harder for us to screw up (since we should always
be including <sys/cdefs.h> anyway).
Bug: 14659579
Change-Id: I23070fff3296b0d1c683bb5e3a6e214146327d53
