Austin Group Defect Tracker

Aardvark Mark III


Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
ID Category Severity Type Date Submitted Last Update
0000851 [1003.1(2013)/Issue7+TC1] System Interfaces Comment Omission 2014-06-26 23:34 2014-07-17 16:18
Reporter dancol View Status public  
Assigned To
Priority normal Resolution Open  
Status New  
Name Daniel Colascione
Organization
User Reference
Section (section number or name, can be interface name)
Page Number (page or range of pages)
Line Number (Line or range of lines)
Interp Status ---
Final Accepted Text
Summary 0000851: pthread_atfork orphans handlers in unloaded shared libraries
Description pthread_atfork is used to register functions to be called before and after a fork operation. The intent of the facility is to ensure that the child receives consistent copies of mutexes and other pieces of shared state. If a process loads a shared library, registers pthread_atfork handlers for that library, then unloads the library, the process will likely segfault the next time it calls fork. Some implementations automatically unregister handlers in this scenario, but there is no requirement to do so, and many implementations malfunction in the way described above.
Desired Action Please either requirement dlclose to automatically unregister pthread_atfork handlers or provide an explicit interface for unregistering these handlers manually. I would prefer the explicit interface.
Tags No tags attached.
Attached Files

- Relationships

-  Notes
(0002286)
eblake (manager)
2014-06-27 01:09

The standard is already clear that pthread_atfork cannot usefully be used in multithreaded programs. "As explained, there is no suitable solution for functionality which requires non-atomic operations to be protected through mutexes and locks. This is why the POSIX.1 standard since the 1996 release requires that the child process after fork( ) in a multi-threaded process only calls async-signal-safe interfaces." (line 50303). Given that, is there any really reason to try and extend the requirements of an already broken-by-design interface?
(0002287)
geoffclare (manager)
2014-06-27 09:32
edited on: 2014-07-11 14:33

I don't think the standard currently does enough to warn application writers of the dangers of using this function. In addition to any change relating to dlclose() I would suggest making the following changes:

After line 50230 add a new paragraph:

If a fork() call in a multi-threaded process leads to a child fork handler calling any function that is not async-signal-safe, the behavior is undefined.

On line 50244 change the APPLICATION USAGE section from:

None.

to:

The original usage pattern envisaged for pthread_atfork() was for the prepare fork handler to lock mutexes and other locks, and for the parent and child handlers to unlock them. However, since all of the relevant unlocking functions are not async-signal-safe this usage results in undefined behavior in the child process.

On page 889 line 29741 section fork() delete:

Fork handlers may be established by means of the pthread_atfork() function in order to maintain application invariants across fork() calls.

[Update: these changes are now the subject of a separate bug: 0000858]

(0002291)
dalias (reporter)
2014-06-27 14:43

Regarding: "However, since all of the relevant unlocking functions are not async-signal-safe this usage results in undefined behavior in the child process."

This statement is not entirely true: sem_post is async-signal-safe. It's not clear to me whether the copy of a semaphore which exists in the child after fork is a valid argument for sem_post, but perhaps the issue should be clarified, since sem_post provides a seemingly-plausible way to use pthread_atfork while avoiding the design flaw.
(0002307)
eblake (manager)
2014-07-10 16:07

Is there existing practice for unregistering pthread_atfork() callbacks? Also, should we add the ability to unregister an atexit() callback?
(0002309)
joerg (reporter)
2014-07-17 15:08

There is existing practice in Solaris to auto-unregister functions for various
callbacks in case that dlclose() has been called for a library that contains
such a callback function.
(0002310)
dalias (reporter)
2014-07-17 16:18

Perhaps dlclose should be required either to unregister such handlers when unloading the library, or to refuse to unload any library for which such handlers have been registered. This would leave some flexibility with the implementation while ensuring that handlers which are no longer loaded do not get called.

- Issue History
Date Modified Username Field Change
2014-06-26 23:34 dancol New Issue
2014-06-26 23:34 dancol Name => Daniel Colascione
2014-06-26 23:34 dancol Section => (section number or name, can be interface name)
2014-06-26 23:34 dancol Page Number => (page or range of pages)
2014-06-26 23:34 dancol Line Number => (Line or range of lines)
2014-06-27 01:09 eblake Note Added: 0002286
2014-06-27 09:32 geoffclare Note Added: 0002287
2014-06-27 14:43 dalias Note Added: 0002291
2014-07-10 16:07 eblake Note Added: 0002307
2014-07-11 14:33 geoffclare Note Edited: 0002287
2014-07-17 15:08 joerg Note Added: 0002309
2014-07-17 16:18 dalias Note Added: 0002310


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