This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Problems with the POSIX clocks and timers tests from HRT
- From: George Anzinger <george at mvista dot com>
- To: libc-alpha at sources dot redhat dot com
- Date: Fri, 22 Apr 2005 18:37:03 -0700
- Subject: Problems with the POSIX clocks and timers tests from HRT
- Organization: MontaVista Software
- Reply-to: george at mvista dot com
In running the tests in the HRT support package I found several cases where
glibc code generated segment faults. As the tests were written, mainly, to
verify the kernel part of the POSIX clocks and timers, it may be that some of
these problems are not important. Here is what the tests found:
Clock_nanosleep() attempts to verify that the time being passed is normalized.
The segv happens when a bad pointer is passed (the tests pass 0 and 1 and
possibly others).
timer_delete() when given a bad pointer causes a segv. This is caused by the
glibc code assuming that the timer_id is a pointer. (I wonder about this as it
is passed to user code and he can do most anything. A fair amount of work went
into the kernel code to prevent bad timer ids from causing problems. This also
affects other things... see timer_get_overrun() below.
Clock_settime() is also trying to verify that the time is normalized and seg
faults on a bad pointer.
timer_get_overrun() fails when passed a timer id from the sig_info block. This
seems to me like a real problem. If a user writes a signal handler for timers
and wants to know which of several timers he is working with he should be able
to use the sig_info block timer_id to get this information. glibc, however,
prevents this by changing the timer_id into a pointer to a local bit of memory
which contains the real timer_id.
In the case of clock_nanosleep() and clock_settime() I think the best thing to
do is to just pass the stuff to the kernel and let it deal with it.
For timer_delete() and the timer indirection being done I need to guess. I
suspect that timer IDs are indirected to allow the "create thread on expire"
option to work. If this is the only reason, wouldn't it work just as well to
set the timer up with a local (to glibc) signal handler. Only such timers would
need the extra memory. I suppose I am missing something here.
For interested folks a version of the HRT tests that uses glibc (but only if
CLOCK_MONOTONIC is defined) is in the HRT sourceforge cvs at
http://cvs.sourceforge.net/viewcvs.py/high-res-timers/HRT/
The patch is common_hrt_tests.patch. (I just uploaded this and it takes a while
for sourceforge to put it on the viewable system, so be patient if you don't see
it.) This is a kernel patch which ONLY adds directories to the kernel tree
under Documentation/high-res-timers. The make file in the tests dir should make
all the tests. The script do_test runs those I consider an acceptance test
which brought the above problems to light. The tests detect the absence of the
high res clocks and do not attempt to test them.
Comments?
--
George Anzinger george@mvista.com
High-res-timers: http://sourceforge.net/projects/high-res-timers/