bug#38368: gcc/ dlclose() documentation feedback

bug#38368: gcc/ dlclose() documentation feedback

[kris]

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.

bug#38368: gcc/ dlclose() documentation feedback

[Lars Ingebrigtsen]

kris <cq.personal@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

bug#38368: Acknowledgement (gcc/ dlclose() documentation feedback)

[kris]

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!

bug#38364: bug#38368: gcc/ dlclose() documentation feedback

[Stefan Kangas]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> kris <cq.personal@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

bug#38364: bug#38368: gcc/ dlclose() documentation feedback

[Lars Ingebrigtsen]

Stefan Kangas <stefan@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

bug#38364: bug#38368: gcc/ dlclose() documentation feedback

[Stefan Kangas]

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

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Stefan Kangas <stefan@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

bug#38364: bug#38368: gcc/ dlclose() documentation feedback

[Stefan Kangas]

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

bug#38368: bug#38364: bug#38368: gcc/ dlclose() documentation feedback

[Carlos O'Donell]

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@sourceware.org to discuss the details
of the specific issue with developers.

-- 
Cheers,
Carlos.