GNU bug report logs - #38368
gcc/ dlclose() documentation feedback

Previous Next

Full log

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: kris <cq.personal <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: gcc/ dlclose() documentation feedback
Date: Mon, 25 Nov 2019 02:58:42 +0100

hello

I think there is some ambiguity in the man page for dlclose().

***********
A  successful return from dlclose() does not guarantee that the
symbols associated with handle are removed from the caller's address
space.  In addition to references  resulting  from  explicit  dlopen()
 calls, a shared object may have been implicitly loaded (and reference
counted) because of dependencies in other shared objects.  Only when
all references have been released can the shared object be removed
from the address space.
********

that strikes me as undermining the docs for RTLD_NOLOAD in the same page which
say that residency CAN be tested.
i do the following to ensure the object is unloaded:
void *handle = dlopen(path,RTLD_NOW | RTLD_NOLOAD);
if(handle){
  return(dlclose(handle) || dlclose(handle) );
}
... it appears to take 2 calls to achieve the unload which I presume
means the refcount got incremented by this dlopen() despite the
RTLD_NOLOAD.
then I test again this way and the 2nd dlclose() fails and confirms
the object is unloaded.
or so I thought.
this worked until I came to recursively load a chain of objects (not
automatically)
and then tried reloading the 1st in the chain.
despite doing the above closing sequence on the chain in reverse order
and finally
on the head of the chain, before doing another dlopen() with a new
version of the disk file,
I found that extracting the data from the address returned from a
dlsym() yielded old data. I have to conclude that the object unload
does NOT happen and that the above dlopen(RTLD_NOLOAD)/dlclose()  test
is erroneous (at least in this layered arrangement).

so getting back to the original ambiguity claim, the passage mentions
removing symbols in the first instance then switches to 'references
being released' the next.  what are 'references' (symbols?) and how
does one determine anything about them or rather enough to 'release'
them so as to circumvent the lack of a guarantee from dlclose() ?
I have scoured the available docs and can find no more on how to
ascertain what prevents unloading or how such can be addressed.

I hope you agree there is at least a lack of clarity.
thanks for reading.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.