From: Pavel Tolkachev <paultolk@yahoo.com>
To: paulTolk@yahoo.com, J <j@jabster.pl>
Cc: gcc-help@gcc.gnu.org
Subject: Re: dlclose() doesn't unload any .so that uses Boost
Date: Tue, 31 May 2011 05:49:00 -0000 [thread overview]
Message-ID: <541024.25612.qm@web161018.mail.bf1.yahoo.com> (raw)
In-Reply-To: <BANLkTi==JP9Kka89dvg_QaMfCyDOYDpthg@mail.gmail.com>
--- On Mon, 5/30/11, J <j@jabster.pl> wrote:
> From: J <j@jabster.pl>
> Subject: Re: dlclose() doesn't unload any .so that uses Boost
> To: paulTolk@yahoo.com
> Cc: gcc-help@gcc.gnu.org
> Date: Monday, May 30, 2011, 11:56 PM
> On Mon, May 30, 2011 at 9:12 PM,
> Pavel Tolkachev <paultolk@yahoo.com>
> wrote:
> > It actually doesn't. It just confirms there were one
> or more references counts to the library and it decreased
> their count by 1 (see man dlclose).
>
> Yes, I've read man dlclose:
>
> "If the same library is loaded again with dlopen(), the
> same file
> handle is returned. The dl library maintains reference
> counts for
> library handles, so a dynamic library is not deallocated
> until
> dlclose() has been called on it as many times as dlopen()
> has
> succeeded on it."
>
> I'm only calling dlopen() once and boost doesn't call
> dlopen() at all,
> so following this manpage my dlclose() should close the
> library. If
> the refcount can be increased by something else then maybe
> this
> manpage needs updating?
>
> Besides, RTLD_NOLOAD paragraph states this:
>
> "This can be used to test if the library is already
> resident (dlopen()
> returns NULL if it is not, or the library's handle if it
> is
> resident)."
>
> While library is clearly still resident dlopen( RTLD_NOLOAD
> ) returns
> NULL; another bug either in the code or in the manpage.
>
> > On remediation side, if you are comfortable with the
> client code's explicitly calling dlclose() anyway, why don't
> you allocate your signal object in free storage via operator
> new and call something like MyDlclose() (or childClose())
> instead of it where you would first delete this object (and
> all others of the kind) and then call dlclose()? This won't
> increase the degree of client code cooperation needed to use
> your library.
>
> Unfortunately, this doesn't work, e.g. this is enough to
> make a .so
> impossible unload:
>
> delete ( new boost :: signal< void () > );
>
> Oh and, I've just noticed that this code doesn't really
> even have to
> run. Consider:
>
> // child.cpp
> // compile with: g++ -lboost_signals child.cpp -shared
> -fPIC -o libchild.so
> #include <stdio.h>
> #include <boost/signals.hpp>
>
> void __attribute__ ( ( constructor ) ) ctor()
> {
> printf( "child: Constructor\n" );
> }
>
> void __attribute__ ( ( destructor ) ) dtor()
> {
> printf( "child: Destructor\n" );
> }
>
> void a_function_that_does_not_get_called()
> {
> new boost :: signal< void () >();
> }
>
> The result:
>
> host: Loading libchild.so...
> child: Constructor
> host: so = 0x8938020
> host: Unloading libchild.so...
> host: Unloaded.
> host: (nil)
> child: Destructor
>
> This pretty much looks like a bug to me.
I admit I spoke too soon, assumed before actually trying your code. After I have tried (both 1st and 2nd versions), the code gave different output to me:
host: Loading libchild.so...
child: Constructor
host: so = 0x8db4020
host: Unloading libchild.so...
child: Destructor
host: Unloaded.
host: (nil)
Which seems correct (dlclose() calls the dtor()). I used
gcc version 4.4.5
libdl-2.12.1.so
boost 1.45.0
Linux kernel 2.6.35-28
libc-2.12.1.so
Hope this helps,
-Pavel
>
> Thanks.
>
next prev parent reply other threads:[~2011-05-30 23:10 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-30 0:24 J
2011-05-30 5:23 ` David Hagood
2011-05-30 18:53 ` J
2011-05-31 6:01 ` Ian Lance Taylor
2011-05-31 12:30 ` J
2011-05-31 17:19 ` Ian Lance Taylor
2011-05-30 23:10 ` Pavel Tolkachev
2011-05-30 23:19 ` J
2011-05-31 5:49 ` Pavel Tolkachev [this message]
2011-05-31 5:54 ` J
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=541024.25612.qm@web161018.mail.bf1.yahoo.com \
--to=paultolk@yahoo.com \
--cc=gcc-help@gcc.gnu.org \
--cc=j@jabster.pl \
/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.
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).