GNU bug report logs -
#38364
Previous Next
Reported by: kris <cq.personal <at> gmail.com>
Date: Mon, 25 Nov 2019 21:33:36 UTC
Severity: normal
Tags: notabug
Merged with 38368
Done: Stefan Kangas <stefan <at> marxist.se>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 38364 in the body.
You can then email your comments to 38364 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#38364
; Package
emacs
.
(Mon, 25 Nov 2019 21:33:36 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
kris <cq.personal <at> gmail.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Mon, 25 Nov 2019 21:33:37 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
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.
Merged 38364 38368.
Request was from
Glenn Morris <rgm <at> gnu.org>
to
control <at> debbugs.gnu.org
.
(Mon, 25 Nov 2019 23:14:01 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#38364
; Package
emacs
.
(Tue, 26 Nov 2019 01:28:01 GMT)
Full text and
rfc822 format available.
Message #10 received at 38364 <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#38364
; Package
emacs
.
(Tue, 31 Dec 2019 10:49:01 GMT)
Full text and
rfc822 format available.
Message #13 received at 38364 <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#38364
; Package
emacs
.
(Tue, 31 Dec 2019 10:50:02 GMT)
Full text and
rfc822 format available.
Message #16 received at 38364 <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#38364
; Package
emacs
.
(Tue, 31 Dec 2019 10:54:01 GMT)
Full text and
rfc822 format available.
Message #19 received at 38364 <at> debbugs.gnu.org (full text, mbox):
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
Added tag(s) notabug.
Request was from
Stefan Kangas <stefan <at> marxist.se>
to
control <at> debbugs.gnu.org
.
(Tue, 31 Dec 2019 10:54:02 GMT)
Full text and
rfc822 format available.
bug closed, send any further explanations to
38364 <at> debbugs.gnu.org and kris <cq.personal <at> gmail.com>
Request was from
Stefan Kangas <stefan <at> marxist.se>
to
control <at> debbugs.gnu.org
.
(Tue, 31 Dec 2019 10:54:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#38364
; Package
emacs
.
(Wed, 01 Jan 2020 11:00:03 GMT)
Full text and
rfc822 format available.
Message #26 received at 38364 <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#38364
; Package
emacs
.
(Tue, 07 Jan 2020 21:17:01 GMT)
Full text and
rfc822 format available.
Message #29 received at 38364 <at> debbugs.gnu.org (full text, mbox):
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.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Wed, 05 Feb 2020 12:24:06 GMT)
Full text and
rfc822 format available.
This bug report was last modified 4 years and 81 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.