From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24237 invoked by alias); 30 May 2011 19:56:30 -0000 Received: (qmail 24226 invoked by uid 22791); 30 May 2011 19:56:29 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-bw0-f47.google.com (HELO mail-bw0-f47.google.com) (209.85.214.47) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 30 May 2011 19:56:14 +0000 Received: by bwz5 with SMTP id 5so3849015bwz.20 for ; Mon, 30 May 2011 12:56:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.74.68 with SMTP id t4mr4642684bkj.22.1306785373197; Mon, 30 May 2011 12:56:13 -0700 (PDT) Received: by 10.204.154.216 with HTTP; Mon, 30 May 2011 12:56:13 -0700 (PDT) In-Reply-To: <520738.2569.qm@web161012.mail.bf1.yahoo.com> References: <520738.2569.qm@web161012.mail.bf1.yahoo.com> Date: Mon, 30 May 2011 23:19:00 -0000 Message-ID: Subject: Re: dlclose() doesn't unload any .so that uses Boost From: J To: paulTolk@yahoo.com Cc: gcc-help@gcc.gnu.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org X-SW-Source: 2011-05/txt/msg00432.txt.bz2 On Mon, May 30, 2011 at 9:12 PM, Pavel Tolkachev wrote: > It actually doesn't. It just confirms there were one or more references c= ounts 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 explic= itly calling dlclose() anyway, why don't you allocate your signal object in= free storage via operator new and call something like MyDlclose() (or chil= dClose()) instead of it where you would first delete this object (and all o= thers 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 #include 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 =3D 0x8938020 host: Unloading libchild.so... host: Unloaded. host: (nil) child: Destructor This pretty much looks like a bug to me. Thanks.