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

[Szabolcs Nagy <nsz at port70 dot net>]

* 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.