[1003.1(2013)/Issue7+TC1 0000851]: pthread_atfork orphans handlers in unloaded shared libraries

[Austin Group Bug Tracker]

The following issue has been SUBMITTED.
======================================================================
http://austingroupbugs.net/view.php?id=851
======================================================================
Reported By: dancol
Assigned To:
======================================================================
Project: 1003.1(2013)/Issue7+TC1
Issue ID: 851
Category: System Interfaces
Type: Omission
Severity: Comment
Priority: normal
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:
======================================================================
Date Submitted: 2014-06-26 23:34 UTC
Last Modified: 2014-06-26 23:34 UTC
======================================================================
Summary: 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.
======================================================================

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)
======================================================================

[Austin Group Bug Tracker]

A NOTE has been added to this issue.
======================================================================
http://austingroupbugs.net/view.php?id=851
======================================================================
Reported By: dancol
Assigned To:
======================================================================
Project: 1003.1(2013)/Issue7+TC1
Issue ID: 851
Category: System Interfaces
Type: Omission
Severity: Comment
Priority: normal
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:
======================================================================
Date Submitted: 2014-06-26 23:34 UTC
Last Modified: 2014-06-27 01:09 UTC
======================================================================
Summary: pthread_atfork orphans handlers in unloaded shared
libraries
======================================================================

----------------------------------------------------------------------
(0002286) eblake (manager) - 2014-06-27 01:09
http://austingroupbugs.net/view.php?id=851#c2286
----------------------------------------------------------------------
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?

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
======================================================================

[Austin Group Bug Tracker]

A NOTE has been added to this issue.
======================================================================
http://austingroupbugs.net/view.php?id=851
======================================================================
Reported By: dancol
Assigned To:
======================================================================
Project: 1003.1(2013)/Issue7+TC1
Issue ID: 851
Category: System Interfaces
Type: Omission
Severity: Comment
Priority: normal
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:
======================================================================
Date Submitted: 2014-06-26 23:34 UTC
Last Modified: 2014-06-27 09:32 UTC
======================================================================
Summary: pthread_atfork orphans handlers in unloaded shared
libraries
======================================================================

----------------------------------------------------------------------
(0002287) geoffclare (manager) - 2014-06-27 09:32
http://austingroupbugs.net/view.php?id=851#c2287
----------------------------------------------------------------------
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 <i>fork</i>() call in a multi-threaded process leads to a <i>child</i>
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 <i>pthread_atfork</i>() was for
the <i>prepare</i> fork handler to lock mutexes and other locks, and for
the <i>parent</i> and <i>child</i> 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 <i>pthread_atfork</i>()
function in order to maintain application invariants across <i>fork</i>()
calls.

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
======================================================================

[Austin Group Bug Tracker]

A NOTE has been added to this issue.
======================================================================
http://austingroupbugs.net/view.php?id=851
======================================================================
Reported By: dancol
Assigned To:
======================================================================
Project: 1003.1(2013)/Issue7+TC1
Issue ID: 851
Category: System Interfaces
Type: Omission
Severity: Comment
Priority: normal
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:
======================================================================
Date Submitted: 2014-06-26 23:34 UTC
Last Modified: 2014-06-27 14:43 UTC
======================================================================
Summary: pthread_atfork orphans handlers in unloaded shared
libraries
======================================================================

----------------------------------------------------------------------
(0002291) dalias (reporter) - 2014-06-27 14:43
http://austingroupbugs.net/view.php?id=851#c2291
----------------------------------------------------------------------
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.

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
======================================================================