Anonymous | Login | 2024-05-16 16:26 UTC |
Main | My View | View Issues | Change Log | Docs |
Viewing Issue Simple Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||
ID | 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 | |||||||
|
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. |
Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group |