This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Problems with the POSIX clocks and timers tests from HRT


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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]