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
If the callback function for a timer did a timer_delete, the function
would never return. The problem was that the timer_delete function would try
to wait until the timer thread has finished. Waiting for yourself to finish
doesn't work very well.
Bug: 13397340
Change-Id: Ica123a5bafbc8660c8a4a909e5c2dead55ca429d
This is a much simpler implementation that lets the kernel
do as much as possible.
Co-authored-by: Jörgen Strand <jorgen.strand@sonymobile.com>
Co-authored-by: Snild Dolkow <snild.dolkow@sonymobile.com>
Change-Id: Iad19f155de977667aea09410266d54e63e8a26bf
In order to be able to generate a list of tests for cts, the same set of
tests must exist across all platforms. This CL adds empty tests where a
test was conditionally compiled out.
This CL creates a single library libBionicTests that includes all of
the tests found in bionic-unit-tests-static.
Also fix a few missing include files in some test files.
Tested by running and compiling the tests for every platform and
verifying the same number of tests are on each platform.
Change-Id: I9989d4bfebb0f9c409a0ce7e87169299eac605a2
I've mailed the tz list about this, and will switch to whatever upstream
fix comes along as soon as it's available.
Bug: 10310929
Change-Id: I36bf3fcf11f5ac9b88137597bac3487a7bb81b0f
In the old code, the index was a file to itself, so it made sense to
read until you hit the end of the file. In the new code, the index is
followed by hundreds of KiB of data, so we need to just search the
index.
Bug: 8368791
Change-Id: Icf5f8b5516cf3a93679fa849c9f6cd1cb100e0f1
