This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Detecting dlclose() on an already closed handle?
- From: Szabolcs Nagy <nsz at port70 dot net>
- To: Carlos O'Donell <carlos at redhat dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Thu, 22 Dec 2016 21:50:36 +0100
- Subject: Re: Detecting dlclose() on an already closed handle?
- Authentication-results: sourceware.org; auth=none
- References: <1df8e262-9163-55b4-7c3a-a5150a70fabc@redhat.com>
* Carlos O'Donell <carlos@redhat.com> [2016-12-22 11:56:45 -0500]:
> The only way to reliably test for an error would be, AFAICT, to store the
> information in the 'void*' whose storage is owned by the caller. You'd have
> to use an ID and then never recycle the IDs. For 32-bit the ABA happens
> pretty quickly if you're doing lots of dlopen/dlclose, and we could easily
> use a larger counter internally to allow the ABA, at the cost of loosing
> the ability to detect double dlclose() for a dlclose() that happened
> 4billion dlopen() calls ago.
>
> POSIX says:
> ~~~
> If the referenced symbol table handle was successfully closed, dlclose()
> shall return 0. 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. More detailed diagnostic information shall
> be available through dlerror().
> ~~~
...
> It appears that dlclose() should be able to detect the handle is not
> open or invalid. We only support that reliably in one scenario:
> where you recursively call dlclose() and we detect it. All other
if invalid handle detection is not reliable (because the handle
may be reused) then i think it can only be a hardening or debug
measure, but should not be part of the interface contract: it
must be the responsibility of the caller to use a valid handle.
(unloading a random module in case of double dlclose is not a
useful operation.)
so this seems to be a posix bug.