threads/151767: pthread_mutex_init returns success with bad attributes; SUBSEQUENT operations fail

Mark Terribile materribile at yahoo.com
Tue Oct 26 23:20:07 UTC 2010


>Number:         151767
>Category:       threads
>Synopsis:       pthread_mutex_init returns success with bad attributes; SUBSEQUENT operations fail
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    freebsd-threads
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Oct 26 23:20:06 UTC 2010
>Closed-Date:
>Last-Modified:
>Originator:     Mark Terribile
>Release:        7.2
>Organization:
>Environment:
FreeBSD gold.local 7.2-RELEASE FreeBSD 7.2-RELEASE #3: Mon Nov 16 12:48:52 EST 2009     toor at silver.local:/usr/obj/usr/src/sys/SMP-GONDOLIN  i386

>Description:
1) A pthread_mutexattr_t is initialized and then parameters are set.  Some are unsupported or invalid, as shown below.  All the operations return success.

2) The pthread_mutex_attr_t is used in the initialization of a pthread_mutex_t.  The pthread_mutex_init returns success.

3) A subesequent operation (pthread_mutex_lock, pthread_mutex_destroy) on the mutex in question returns EINVAL.

This delayed reporting makes finding an error very difficult, and is probably not correct.  Can the pthread_mutex_init be said to succeed if the mutex cannot be used for anything without generating an EINVAL?

I understand that 7.2 is not a supported release, but this problem does not seem to appear in the bug reports so it is likely also present in later releases.  An upgrade at this site right now is not feasible; I need a very stable environment underneath me.


>How-To-Repeat:
Please refer to the code below.  All operations up to the #if return 0.  If the lock/unlock code is #if'd out, the pthread_mutex_destroy returns 22.  If the lock/unlock code is #if'd in, the pthread_mutex_lock returns 22, the pthread_mutex_unlock returns 2 (probably correct, given the other errors) and the pthread_mutex_destroy still returns 22.


#include <stdio.h>
#include <pthread.h>

int main()
{
	pthread_mutexattr_t ma;

	int r = pthread_mutexattr_init( &ma );

	printf( "mutexattr init %d\n", r );

	r = pthread_mutexattr_setprotocol( &ma, PTHREAD_PRIO_PROTECT );

	printf( "mutexattr setprotocol %d\n", r );

	r = pthread_mutexattr_settype( &ma, PTHREAD_MUTEX_ERRORCHECK );

	printf( "mutexattr settype %d\n", r );

	r = pthread_mutexattr_setprioceiling( &ma, 2 );

	printf( "mutexattr setprioceiling %d\n", r );

	pthread_mutex_t mtx;

	r = pthread_mutex_init( &mtx, &ma );

	printf( "mutex init %d\n", r );

#if 0
	r = pthread_mutex_lock( &mtx );

	printf( "mutex lock %d\n", r );

	r = pthread_mutex_unlock( &mtx );

	printf( "mutex unlock %d\n", r );
#endif

	r = pthread_mutex_destroy( &mtx );

	printf( "mutex destroy %d\n", r );

	return 0;
}

>Fix:


>Release-Note:
>Audit-Trail:
>Unformatted:


More information about the freebsd-threads mailing list