Austin Group Defect Tracker

Aardvark Mark IV


Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
ID Category Severity Type Date Submitted Last Update
0001404 [1003.1(2016/18)/Issue7+TC2] System Interfaces Editorial Clarification Requested 2020-09-24 00:44 2021-03-08 15:19
Reporter dalias View Status public  
Assigned To
Priority normal Resolution Accepted As Marked  
Status Applied  
Name Rich Felker
Organization musl libc
User Reference
Section pthread_mutex_destroy
Page Number (page or range of pages)
Line Number (Line or range of lines)
Interp Status ---
Final Accepted Text Note: 0005232
Summary 0001404: Is there a requirement to destroy mutex before object lifetime ends?
Description The specification of pthread_mutex_destroy establishes conditions under which behavior of call to pthread_mutex_destroy is undefined, but does not cover whether there are conditions under which failure to call it is undefined. If the lifetime of a pthread_mutex_t object with automatic or allocated storage duration (or mmap/MAP_ANON) ends (end of execution of block, call to free, munmap, etc.) without a call to pthread_mutex_destroy, is or should the behavior be undefined?

I tend to believe it should be undefined, because the intent of having init/destroy functions seems to be to allow implementation flexibility that would include things like keeping a linked list of all existant objects for error-checking (necessary for diagnostic of double init, etc.), using allocation in pthread_mutex_init (in which failure to call pthread_mutex_destroy is a memory leak, which although not inherently fatal, is bad), and so on.
Desired Action Possibly add text to description:

"If the lifetime of an initialized pthread_mutex_t object ends without a call to pthread_mutex_destroy, the behavior is undefined."

It's likely that this proposal needs further discussion, particularly for the case of process-shared objects living in MAP_SHARED (and maybe also MAP_ANON) memory where the end of the object lifetime is not well-defined, and where it may be desirable to allow omission of pthread_mutex_destroy because of software that relies on the shared memory ceasing to exist when the last user unmaps it.

If an action is taken on this, similar actions are probably needed for other pthread object types.
Tags tc3-2008
Attached Files

- Relationships

-  Notes
(0005232)
geoffclare (manager)
2021-02-11 16:37

On page 471 line 16206 section 2.1.1, change:
If an argument to a function has an invalid value (such as a value outside the domain of the function, or a pointer outside the address space of the program, or a null pointer), the behavior is undefined.
to:
If an argument to a function has an invalid value, such as a value outside the domain of the function, a pointer to an object whose lifetime has ended (even if a new object now has the same address), a pointer outside the address space of the program, or a null pointer, the behavior is undefined.

- Issue History
Date Modified Username Field Change
2020-09-24 00:44 dalias New Issue
2020-09-24 00:44 dalias Name => Rich Felker
2020-09-24 00:44 dalias Organization => musl libc
2020-09-24 00:44 dalias Section => pthread_mutex_destroy
2020-09-24 00:44 dalias Page Number => (page or range of pages)
2020-09-24 00:44 dalias Line Number => (Line or range of lines)
2021-02-11 16:37 geoffclare Note Added: 0005232
2021-02-11 16:38 geoffclare Interp Status => ---
2021-02-11 16:38 geoffclare Final Accepted Text => Note: 0005232
2021-02-11 16:38 geoffclare Status New => Resolved
2021-02-11 16:38 geoffclare Resolution Open => Accepted As Marked
2021-02-11 16:38 geoffclare Tag Attached: tc3-2008
2021-03-08 15:19 geoffclare Status Resolved => Applied


Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker