0001110: Return requirements for error on dlclose too restrictive for implementors.

Austin Group Defect Tracker

Aardvark Mark IV

Viewing Issue Simple Details [ Jump to Notes ]

[ Issue History ] [ Print ]

Category

Severity

Type

Date Submitted

Last Update

0001110

[1003.1(2016/18)/Issue7+TC2] System Interfaces

Editorial

Enhancement Request

2016-12-23 17:49

2018-06-14 15:07

Reporter

carlos

View Status

public

Assigned To

Priority

normal

Resolution

Withdrawn

Status

Closed

Name

Carlos O'Donell

Organization

User Reference

Section

dlclose

Page Number

unknown

Line Number

unknown

Interp Status

---

Final Accepted Text

Summary

0001110: Return requirements for error on dlclose too restrictive for implementors.

Description

The normative text under the return value for dlclose() contains:
~~~
If handle does not refer to an open symbol table handle or if the symbol table handle could not be closed, dlclose() shall return a non-zero value.
~~~

The effect of the "shall" means that every dlopen must retain enough global state to track all previously dlclose'd handles and return non-zero if they do not refer to an open symbol table handle.

For example in the GNU C Library (glibc) the implementation aims to support an unlimited number of dlopen/dlclose pairings and therefore dynamically allocates the space required for the global state information during dlopen and subsequently frees it during dlclose. This makes it impossible to detect a dlclose on an already closed handle since such a handle no longer has any associated global state. Therefore glibc cannot meet the requirements of the standard (given the current implementation).

At a theoretical level the only storage that is valid for the entire duration of the possible calls to dlclose is that of the void* returned to the user. An implementation that honours the POSIX wording would have to place all the global state information into that global pointer. For example you could use an identifier stored in the void* to track opened objects. That has an unacceptable limit that after you exhaust the identifiers available you have to restart, creating an ABA problem.

Therefore no good theoretical solution appears to present itself that meets the wording of the standard.

Desired Action

Change the 'shall' to 'may'.

e.g.
~~~
If handle does not refer to an open symbol table handle or if the symbol table handle could not be closed, dlclose() *may* return a non-zero value.
~~~

The change to 'may' allows an implementation to adopt a hardening strategy with regards to double-dlclose() tracking. A non-perfect solution can be adopted to detect this condition which is arguably a misuse of the API.

The suggested void* as an identifier solution becomes possible since the ABA condition now becomes allowed under the standard, and it would be an unlikely condition in an environment where void* is 64-bits wide. Allowing the ABA error is no worse than what currently happens in implementations where the handle is a pointer to dynamically allocated storage that may be freed by dlclose.

I understand that this request is effectively about quality of implementation and error detection. However, I feel that the standard as it is today prevents the implementer from deciding how to tradeoff error detection vs unlimited dlopen/dlclose pairings.

Tags

No tags attached.

Attached Files

Relationships

duplicate of

0000639

Closed

ajosey

1003.1(2008)/Issue 7

dlsym, dlclose handling of invalid handles

Notes
(0003527) carlos (reporter) 2016-12-24 03:36	It was pointed out to me that Rich Felker filed a similar issue in 2013: http://austingroupbugs.net/view.php?id=639 [^]

(0003543) carlos (reporter) 2017-01-14 00:12	The confusion is over the meaning of "does not refer to an open symbol table" and if a previously used and closed handle can be reused by the system and thus _not_ result in an error at dlclose() time. For example thread A dlopens a library, then dlcloses it, thread B eventually dlopens a library and gets the same handle as thread A had. A bug in thread A causes it to dlclose the same library again which succeeds, even though thread A's handle was previously closed (but now happens to refer again to an open symbol table). It appears that POSIX would allow this behaviour, which means that an implementation can be made with unlimited calls to dlopen/dlclose. Therefore there is no issue in implementing the POSIX standard as worded. I suggest the issue be closed.

Issue History
Date Modified	Username	Field	Change
2016-12-23 17:49	carlos	New Issue
2016-12-23 17:49	carlos	Name	=> Carlos O'Donell
2016-12-23 17:49	carlos	Section	=> dlclose
2016-12-23 17:49	carlos	Page Number	=> unknown
2016-12-23 17:49	carlos	Line Number	=> unknown
2016-12-23 17:51	Florian Weimer	Issue Monitored: Florian Weimer
2016-12-24 03:36	carlos	Note Added: 0003527
2017-01-04 12:16	geoffclare	Relationship added	duplicate of 0000639
2017-01-14 00:12	carlos	Note Added: 0003543
2018-06-14 15:04	Don Cragun	Interp Status	=> ---
2018-06-14 15:04	Don Cragun	Resolution	Open => Withdrawn
2018-06-14 15:07	geoffclare	Status	New => Closed

Mantis 1.1.6[^]