unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#38368: gcc/ dlclose() documentation feedback
@ 2019-11-25  1:58 kris
  2019-11-26  1:27 ` Lars Ingebrigtsen
       [not found] ` <handler.38368.B.157468668921327.ack@debbugs.gnu.org>
  0 siblings, 2 replies; 8+ messages in thread
From: kris @ 2019-11-25  1:58 UTC (permalink / raw)
  To: 38368

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.





^ permalink raw reply	[flat|nested] 8+ messages in thread
end of thread, other threads:[~2020-01-07 20:43 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-11-25  1:58 bug#38368: gcc/ dlclose() documentation feedback kris
2019-11-26  1:27 ` Lars Ingebrigtsen
2019-12-31 10:48   ` bug#38364: " Stefan Kangas
2019-12-31 10:49     ` Lars Ingebrigtsen
2019-12-31 10:53       ` Stefan Kangas
2020-01-01 10:58         ` Stefan Kangas
2020-01-07 20:43           ` bug#38368: " Carlos O'Donell
     [not found] ` <handler.38368.B.157468668921327.ack@debbugs.gnu.org>
2019-11-26  2:48   ` bug#38368: Acknowledgement (gcc/ dlclose() documentation feedback) kris

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).