unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: kris <cq.personal@gmail.com>
To: 38368@debbugs.gnu.org
Subject: bug#38368: gcc/ dlclose() documentation feedback
Date: Mon, 25 Nov 2019 02:58:42 +0100	[thread overview]
Message-ID: <CACTzTFAPK2hpEyQpA6vhgRhcKMarD=cOOkwQHyMcpOvDb1kFPw@mail.gmail.com> (raw)

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.





             reply	other threads:[~2019-11-25  1:58 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-25  1:58 kris [this message]
2019-11-26  1:27 ` bug#38368: gcc/ dlclose() documentation feedback 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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CACTzTFAPK2hpEyQpA6vhgRhcKMarD=cOOkwQHyMcpOvDb1kFPw@mail.gmail.com' \
    --to=cq.personal@gmail.com \
    --cc=38368@debbugs.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).