NPTL (Native POSIX Threading Library) Tests and Trace

This webpage contains a summary of the problems found in NPTL and the problems NOT found in NPTL (i.e. what is proved to work). All this information is extracted from the forum where more details can be found.

The tests results of our test campaigns can be found in this database.

 > Spotted problems

Disclaimer:

It cannot be expected to find an enormous bug in a library such as NPTL, which as been in use for several years now, and is included in several Linux distributions (Red Hat 9, Fedora,...). Features which are wildly used, such as mutex locks, have been stable and reliable for a long time.
What we are tracking here are the minor problems (divergences with the standard, strange behaviors), which most people will ignore, until someone get into the problem and get a headhache.

 > Tested features

Coverage Progress Indicator

The NPTL routines have been splitted into 4 groups, according to their priorities. More detailed information on the routines priority can be found here.

Click here for a graphical progress view.

Assertions coverage of conformance and stress tests

Click on the function name to get more information on assertions and coverage.

#1

For each routines, POSIX specifies some criterias that the routine must match (mandatory criterias) and some other that the routine may match (optionnal criterias). The routine is said to be compliant when at least all the mandatory criterias are matched. This column in the table shows the number of different assertions that POSIX requires as mandatory for the routine.

#2

This column shows the amount of POSIX assertions that are completly tested in the current Open POSIX Test Suite release. Some other assertion might be partially tested, but this is not reported here.

#3

This is the number of different assertions for which a least one test has been contributed by our project into the Open POSIX Test Suite.

Features coverage of scalability and stress tests

Cancelation:

Heavy threads cancelation does not break the system.

There is no problem when canceling a terminating thread.

Cond vars:

Condvar Initialization and destruction duration does not depend on the number of condvars in use in the system -- for any kind of condvar.

Condvar initialization then destruction does not consume any system resource -- for any kind of condvar.

Latency between pthread_cond_timedwait timeout parameter and function actual return does not depend on the number of threads waiting on the condvar -- whatever kind of condvar.

No condition signaling (signal or broadcast) is lost.

No condition signaling can happen after the function has released the mutex, and not be visible to the function.

No condition signaling is consumed when a thread waiting for the condvar is canceled.

Mutexes:

Mutex initialization and destruction duration does not depend on the number of mutex in use in the system -- for any type of mutex.

Mutex initialization then destruction does not consume any system resource (memory leak, ...) -- for any type of mutex.

With a large amount of threads contending for some mutexes (of several types) with pthread_mutex_lock, pthread_mutex_trylock and pthread_mutex_timedlock, there is never more than one thread owning the same mutex at the same time.

Other:

The process creation time in fork() does not depend on the number of running processes.

Scheduling:

pthread_getschedparam() always returns the scheduling parameters of the queried thread.

Semaphores:

The sem_getvalue always returns the value of the semaphore at a given time during the call into the sval argument.

The sem_init and sem_destroy duration does not depend on the number of opened unnamed semaphores.

The sem_open and sem_close duration does not depend on the number of opened semaphores.

Signals:

Heavy signal delivery with pthread_kill() does not break the system, and no unpending signal get lost.

Threads:

pthread_self() always returns a unique thread ID.

The init_routine argument of pthread_once is never called more or less than once.

The thread creation time does not depend on the amount of threads already present in the process.

When a thread exits or is joined (depending on its attributes), its resources are freed.

When pthread_create() fails because of a lack of resource, EAGAIN is returned.