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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 38368 in the body.
You can then email your comments to 38368 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: kris <cq.personal <at> gmail.com>
Cc: 38364 <at> debbugs.gnu.org, 38368 <at> debbugs.gnu.org
Subject: Re: bug#38368: gcc/ dlclose() documentation feedback
Date: Tue, 26 Nov 2019 02:27:25 +0100

kris <cq.personal <at> gmail.com> writes:

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

This bug report landed in the Emacs bug tracker -- perhaps because of
the debbugs.gnu.org outage yesterday?

What package was this bug report meant for?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: kris <cq.personal <at> gmail.com>
To: 38368 <at> debbugs.gnu.org
Subject: Re: bug#38368: Acknowledgement (gcc/ dlclose() documentation feedback)
Date: Tue, 26 Nov 2019 03:48:59 +0100

hello.
apart from making the mistake of titling 'gcc' rather than 'glibc', on
revue I was also vague about what I saw as the ambiguity in the
documentation.
to wit: on the one hand the docs state dlclose() does NOT guarantee unloading
of the object.
on the other a means is provided for determining if an object is
resident (RTLD_NOLOAD).
having done that once and dlclose()ed as needed (twice if the handle
was non-null),
if a 2nd attempt to dlopen() returns null then that is indeed
confirmation of unloading.
so, in this way, a guarantee is obtained of unloaded status and it was
done via a combination of dlopen() and dlclose() (multiple).
my contention is that the mention of  dlclose() being 'not guaranteed'
could be qualified by indicating how to go about it.

that said, I methodically went through getting this confirmation of
unloaded status for
a recursive chain, and still found that data obtained through a
dlsym() on the re-opened chain-head object did not correspond to the
content of the refreshed disk file.
I am totally confused about that!

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

From: Stefan Kangas <stefan <at> marxist.se>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: kris <cq.personal <at> gmail.com>, 38364 <at> debbugs.gnu.org, 38368 <at> debbugs.gnu.org
Subject: Re: bug#38364: bug#38368: gcc/ dlclose() documentation feedback
Date: Tue, 31 Dec 2019 11:48:14 +0100

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> kris <cq.personal <at> gmail.com> writes:
>
>> I think there is some ambiguity in the man page for dlclose().
>
> This bug report landed in the Emacs bug tracker -- perhaps because of
> the debbugs.gnu.org outage yesterday?
>
> What package was this bug report meant for?

This seems to be intended for glibc, but they do not use debbugs
according to:  https://sourceware.org/glibc/wiki/FilingBugs

I can't figure out how to forward a bug to them without creating an
account here:  https://sourceware.org/bugzilla/enter_bug.cgi

The original submitter of the bug is in the best position to file a
bug using their web interface, but has unfortunately not reported back
here within 5 weeks.  I'm therefore not sure how to best proceed here.

Best regards,
Stefan Kangas

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: kris <cq.personal <at> gmail.com>, 38364 <at> debbugs.gnu.org, 38368 <at> debbugs.gnu.org
Subject: Re: bug#38364: bug#38368: gcc/ dlclose() documentation feedback
Date: Tue, 31 Dec 2019 11:49:03 +0100

Stefan Kangas <stefan <at> marxist.se> writes:

> The original submitter of the bug is in the best position to file a
> bug using their web interface, but has unfortunately not reported back
> here within 5 weeks.  I'm therefore not sure how to best proceed here.

It should probably be closed in the Emacs bug tracker, anyway.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Stefan Kangas <stefan <at> marxist.se>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: kris <cq.personal <at> gmail.com>, 38364 <at> debbugs.gnu.org, 38368 <at> debbugs.gnu.org
Subject: Re: bug#38364: bug#38368: gcc/ dlclose() documentation feedback
Date: Tue, 31 Dec 2019 11:53:41 +0100

tags 38364 + notabug
tags 38368 + notabug
close 38364
close 38368
thanks

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> Stefan Kangas <stefan <at> marxist.se> writes:
>
>> The original submitter of the bug is in the best position to file a
>> bug using their web interface, but has unfortunately not reported back
>> here within 5 weeks.  I'm therefore not sure how to best proceed here.
>
> It should probably be closed in the Emacs bug tracker, anyway.

Closed.

If anyone knows how to go about forwarding this bug to glibc, then
please help do so.

Best regards,
Stefan Kangas

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

From: Stefan Kangas <stefan <at> marxist.se>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: kris <cq.personal <at> gmail.com>, 38364 <at> debbugs.gnu.org,
 libc-maintainers <at> gnu.org, 38368 <at> debbugs.gnu.org,
 Richard Stallman <rms <at> gnu.org>
Subject: Re: bug#38364: bug#38368: gcc/ dlclose() documentation feedback
Date: Wed, 1 Jan 2020 11:58:45 +0100

Dear libc-maintainers,

There was a submisson to the Emacs bug tracker which seems to relate
to glibc.  We have closed the bug report in our own bug tracker, but
you might like to take note of it.

You can find the details here:

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=38364
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=38368

Best regards,
Stefan Kangas

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

From: Carlos O'Donell <codonell <at> redhat.com>
To: Stefan Kangas <stefan <at> marxist.se>, Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: kris <cq.personal <at> gmail.com>, 38364 <at> debbugs.gnu.org,
 libc-maintainers <at> gnu.org, 38368 <at> debbugs.gnu.org,
 Richard Stallman <rms <at> gnu.org>
Subject: Re: bug#38364: bug#38368: gcc/ dlclose() documentation feedback
Date: Tue, 7 Jan 2020 15:43:19 -0500

On 1/1/20 5:58 AM, Stefan Kangas wrote:
> Dear libc-maintainers,
> 
> There was a submisson to the Emacs bug tracker which seems to relate
> to glibc.  We have closed the bug report in our own bug tracker, but
> you might like to take note of it.
> 
> You can find the details here:
> 
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=38364
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=38368

Thank you for bringing this to our attention.

I recommend you file a bug in the glibc bug tracker here:
https://sourceware.org/bugzilla/

Or email libc-help <at> sourceware.org to discuss the details
of the specific issue with developers.

-- 
Cheers,
Carlos.

Previous Next

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