delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/2015/10/01/09:56:25

X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f
X-Recipient: djgpp AT delorie DOT com
X-Original-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:content-type;
bh=dHwMKjZoddBgRJsYFjf6PLGDkAWAiFo8UgNL9ZU2Xgc=;
b=YrEcaN0EiVBp9kp1E2wves3xPLv+jFZVm5l0h/uXBTvvpIaQPEG+aM7swzpguj3qX9
L8B2eOfEEemB4AB8+aQw5D4lSXSGsT/V/eMAV74B9V14A21TUgwyMPXW7fh//rrFn7Z+
+C6IUsHnTpRuhHs1UiMXWDggyJ5tiIfUqe79YLNMWA8BmcUmTAqRrfhzXJLQVbd/HAe6
IelS+ydAujZ9oLrNsauHEzWDPiAPMGVwpZH6JG3HKKgCm8Yh9aEzHyjur4EWxyca1bjJ
ovEAVsleAxk/fgLbQh7PCoVZsk7nzNp7VVqNB44nbNMWAf+3P8wHwXiUPBNIRe3lv34Y
aB4A==
MIME-Version: 1.0
X-Received: by 10.107.17.206 with SMTP id 75mr13014674ior.140.1443707770300;
Thu, 01 Oct 2015 06:56:10 -0700 (PDT)
In-Reply-To: <952a68b4-223b-4222-b456-35514bb8b7eb@googlegroups.com>
References: <CAA2C=vAwcH9pHN63=Mskr9L016yAAJ6KkMPeuO9o_2cV7Pd0Kw AT mail DOT gmail DOT com>
<CAA2C=vDDN8UqGpbAzkba19Syq-1mLsBPAuSzSPWue_S2TYf_XQ AT mail DOT gmail DOT com>
<b8759e89-e375-4647-a9eb-64543cc49748 AT googlegroups DOT com>
<CAA2C=vDSknbCKHzUA954weavLj16nXuDyP_Ggi+SmLJ_e-U_KA AT mail DOT gmail DOT com>
<CAA2C=vAdzu+ebq1mEsoqwkxJcYR+2EZdKJ3d5XxOZRCytL6z8w AT mail DOT gmail DOT com>
<952a68b4-223b-4222-b456-35514bb8b7eb AT googlegroups DOT com>
Date: Thu, 1 Oct 2015 16:56:10 +0300
Message-ID: <CAA2C=vA0sYw19muvCeX-mY3hegXnpt2P76wn73+fbdJfdj+DwQ@mail.gmail.com>
Subject: Re: dlclose not removing dependency dxes
From: "Ozkan Sezer (sezeroz AT gmail DOT com) [via djgpp AT delorie DOT com]" <djgpp AT delorie DOT com>
To: djgpp AT delorie DOT com
Reply-To: djgpp AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com

On 10/1/15, Juan Manuel Guerrero (juan DOT guerrero AT gmx DOT de) [via
djgpp AT delorie DOT com] <djgpp AT delorie DOT com> wrote:
> On Thursday, October 1, 2015 at 9:35:24 AM UTC+2, Ozkan Sezer
> (sezeroz AT gmail DOT com) [via djgpp AT delorie DOT com] wrote:
>> On 9/27/15, Ozkan Sezer <sezeroz AT gmail DOT com> wrote:
>> > On 9/26/15, Juan Manuel Guerrero (juan DOT guerrero AT gmx DOT de) [via
>> > djgpp AT delorie DOT com] <djgpp AT delorie DOT com> wrote:
>> >> On Friday, September 25, 2015 at 7:21:47 PM UTC+2, Ozkan Sezer
>> >> (sezeroz AT gmail DOT com) [via djgpp AT delorie DOT com] wrote:
>> >>> On 9/25/15, Ozkan Sezer <sezeroz AT gmail DOT com> wrote:
>> >>> > AFAICS, dlclose()ing of a dxe doesn't remove its dependency dxes
>> >>> > along
>> >>> > with it, which will result in unnecessarily occupied memory which
>> >>> > may
>> >>> > prove fatal upon multiple dlopen()/dlclose() of a dxe with deps.
>> >>> > This
>> >>> > needs addressing.
>> >>> >
>> >>>
>> >>> My last argument was inaccurate and misleading. Here's better:
>> >>>
>> >>> One has a.dxe and b.dxe; a.dxe depends on b.dxe.  Do dlopen a.dxe
>> >>> and b.dxe is opened implicitly.  Do dlcose a.dxe, and b.dxe stays
>> >>> open still occupying its memory.  The memory occupied by the unused
>> >>> b.dxe might be needed by the app but will be unavailable to it.
>> >>> Further dlopen calls for a.dxe will increment the refcount for b.dxe
>> >>> which never gets decremented.
>> >>
>> >>
>> >> Can you provide a minimal sample code to demonstrate the issue?
>> >>
>> >> Regards,
>> >> Juan M. Guerrero
>> >>
>> >
>> > =======================================
>> >
>> > $ cat 12.c
>> > extern int my_func2();
>> > int my_func1() {
>> >   return my_func2();
>> > }
>> > $ gcc -c 12.c
>> > $ dxe3gen -o a.dxe -P b.dxe -U 12.o
>> > $ dxe3gen --show-exp a.dxe
>> > _my_func1
>> > $ dxe3gen --show-dep a.dxe
>> > b.dxe
>> >
>> > =======================================
>> >
>> > $ cat 13.c
>> > int my_func2() {
>> >   return -1;
>> > }
>> > $ gcc -c 13.c
>> > $ dxe3gen -o b.dxe 13.o
>> > $ dxe3gen --show-exp b.dxe
>> > _my_func2
>> >
>> > =======================================
>> >
>> > $ cat 11.c
>> > #include <dlfcn.h>
>> > #include <stdio.h>
>> >
>> > void *my_dxe1;
>> > int (*my_f)();
>> >
>> > int main (void) {
>> >   my_dxe1 = dlopen("a.dxe",0);
>> >   if (!my_dxe1) {
>> >     printf("dlopen() failed\n");
>> >     return 1;
>> >   }
>> >   dlclose(my_dxe1);
>> >
>> >   my_f = dlsym(RTLD_DEFAULT,"_my_func1");
>> >   if(!my_f) {
>> >     printf("a.dxe not loaded\n");
>> >   }
>> >   else {
>> >     printf("a.dxe:my_func1(): %p\n",my_f);
>> >   }
>> >
>> >   my_f = dlsym(RTLD_DEFAULT,"_my_func2");
>> >   if(!my_f) {
>> >     printf("b.dxe not loaded\n");
>> >   }
>> >   else {
>> >     printf("b.dxe:my_func2(): %p\n",my_f);
>> >     printf("b.dxe:my_func2() returns: %d\n",my_f());
>> >   }
>> >
>> >   return 0;
>> > }
>> >
>> > $ gcc -Wall -W 11.c
>> >
>> > =======================================
>> >
>> > $ a.exe > a.log
>> > $ cat a.log
>> > a.dxe not loaded
>> > b.dxe:my_func2(): 95830
>> > b.dxe:my_func2() returns: -1
>> >
>>
>> PING? Any ideas? (Sorry that I brought the issue
>> but have no patch for it myself.)
>
>
> An inspection of your sample code and dldemo.cpp shows that it seems to be
> that it is the user's responsibility to explicitly dlclose every dlopen'ed
> modules.

The thing is, the dependency dxe, i.e. b.dxe in my example,
is implicitly dlopen()ed and I won't ever have the handle for it.

> This is what an inspection of dldemo.cpp shows.
> This may not be what you expected from unix but I assume that no DJGPP
> developer has really promised that the behaviour would be identical to unix
> behaviour.
> Neither less I will inspect the issue during week-end but I do not promise
> that a fix will be possible.
>

Thanks.

--
O.S.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019