This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Detecting dlclose() on an already closed handle?


On 26/04/2017 19:48, Rm Beer wrote:
> The problem of double dlclose() not is a bug. I read about of this in
> the listing and view that dlclose() seem has already everything the
> need for clean from the memory: check the recursive dlclose(), free
> memory, etc.
> 
> The problem is from the programmer, you known that where you
> close/free anything, in the memory have a garbage of the last data
> used. This garbage if not clean or replaced by any other new memory,
> have misleading datas.
> The programmer must check if already have execute a double dlclose().
> No POSIX, glibc or other libraries, only the programmer.
> 
> Can are confuse where saying all dlopen() have all dlclose(). Not
> confused this with double dlclose() for dlopen(). Where you use
> dlclose() for a dlopen(), the pair is complete. The (void*) of handler
> is now a garbage that must be forgotten.
> 
> Not is a bug.
> 

You must be referring to BZ#20990 and BZ#14989, which were the one we
talked about on IRC (BZ#20990 was recently closed since it was a
duplicate of BZ#14989).

The issue here is detecting dlclose on an invalid handler is a POSIX
requirement in current standard [1]:

"If handle does not refer to an open symbol table handle or if the symbol 
 table handle could not be closed"

It was raised two defects/clarification on Austin groups [2] [3].  The
first one, 639, asked to make the dlclose on invalid handler an undefined
behavior and it was reject by POSIX saying some application requires
this behaviour.  The second one, 1110, asked for slight change in returned
code both the faulty behaviour (dlclose must return a non-zero value
to may return a non-zero value) and Carlos in his last comment to close
this issue in the end.

In a short, with current decisions and clarification from Austin Group,
GLIBC implementation is non-conforming regarding POSIX.  The BZ#14989
is valid and we should aims to fix it.

[1] http://pubs.opengroup.org/onlinepubs/9699919799/ 
[2] http://austingroupbugs.net/view.php?id=639
[3] http://austingroupbugs.net/view.php?id=1110


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]