Fw: dlopen Solaris memory leaks

[Ben Goodwin]

Sending again, I didn't get any responses...

----- Original Message -----
From: "Ben Goodwin" <ben@atomicmatrix.net>
To: <gcc-bugs@gcc.gnu.org>
Sent: Wednesday, September 04, 2002 11:24 PM
Subject: dlopen Solaris memory leaks


> I've been hunting down a memory leak that my library, which gets
> dlopened/closed numerous times in any given instance of a program, seems
to
> incurr.  I've been able to recreate the leak with minimal code.  At first
I
> thought it was a Solaris bug, but I tried compiling the same code with
> SUNWspro (sun's cc) and the leak goes away.  So, naturally, I come here.
> Basically the program 'tst' dlopens 'tstlib', runs a routine called 'doit'
> from 'tstlib', dlcloses 'tstlib', and repeats.  This causes a memory leak
in
> 'tst'.  I've reproduced this with gcc 2.95.3, 3.0.2, and 3.1 on Solaris
> 8/x86, Solaris 8/sparc, and Solaris 9/sparc.  Again, SUNWspro (version
info
> below) doesn't produce a leaking executeable/dlopen library.  Perhaps I'm
> doing something wrong (and as such, so is libtool), or perhaps there's
> really a bug here.  I'm using the system's 'ld' linker (like libtool
does),
> though I've tried using gcc -shared with the same results.
> Note that not all routines cause this memory leak.  The only one I *know*
> about is getservbyname(), but I also know there are others, as dlopening
> MySQL (and running mysql_init/close) causes leaks even if I comment out
all
> getservbyname() calls.  Before I paste version info/code, I'd like to
state
> I'm willing to do more debugging here, but this goes beyond my immediate
> know-how.  Please let me know how I can help more, if necessary.
> Note also that this leak does not occur on my RedHat 7.3/intel machine.
> I'm attaching the *.i* files as well.
> Thanks!
>
>     -=| Ben
>
> ====
>
> SUNWspro 'cc -V' output
>
>  > cc -V
> ucbcc: Sun WorkShop 6 update 1 C 5.2 2000/09/11
> ld: Software Generation Utilities - Solaris Link Editors: 5.8-1.275
>
> Serveral gcc versions; The Solaris 9 box was wiped so I don't have that
info
> handy - but it was a Sun FreeWare installation.
>
>  /* Sourceforge compile farm - From the path name it's obvious this is a
Sun
> FreeWare installation.  I don't know anything else about how it was
> configured/installed. */
>  > gcc -v
> Reading specs from /opt/sfw/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3/specs
> gcc version 2.95.3 20010315 (release)
>
>  > gcc -v
> Reading specs from /usr/local/lib/gcc-lib/i386-pc-solaris2.8/3.1/specs
> Configured with:
>
../configure --with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld --disable-n
> ls
> Thread model: posix
> gcc version 3.1
>
> > gcc -v
> Reading specs from /usr/local/lib/gcc-lib/sparcv9-sun-solaris2/3.0.2/specs
> Configured with:
> ../gcc-3.0.2/configure --prefix=/usr/local --enable-languages=all
> sparcv9-sun-solaris2
> Thread model: posix
> gcc version 3.0.2
>
>
>
> Here's the code.
>
> /* tst.c */
> #include <stdio.h>
> #include <dlfcn.h>
>
> #define MYLIB "/export/home/ben/dl/tstlib.so.1"
>
> int main (void)
> {
>   void *handle;
>   int (*a)(void);
>   char *error;
>
>   while (1)
>     {
>       handle = dlopen (MYLIB, RTLD_LAZY);
>       if (!handle)
>         {
>           fputs (dlerror(), stderr);
>           exit (1);
>         }
>
>       a = dlsym (handle, "doit");
>       if ((error = dlerror ()) != NULL)
>         {
>           fprintf (stderr, "%s\n", error);
>           exit (1);
>         }
>         (*a)();
>
>       dlclose (handle);
>     }
> }
>
> /* tstlib.c */
>
>
> #include <stdio.h>
> #include <stdlib.h>
> #include <netdb.h>
>
> static struct servent *serv_ptr;
> static char *f;
>
> void doit (void)
> {
>    if ((serv_ptr = getservbyname("telnet", "tcp")) == NULL)
>      {
>         printf("oops\n");
>      }
> }
>
>
> /* Compiled with */
>
> gcc -g -o tst tst.c -ldl
> gcc -g -fPIC -DPIC -c tstlib.c -o tstlib.o
>
> /usr/ccs/bin/ld -G -h tstlib.so.1 -o tstlib.so.1 tstlib.o -lsocket -lnsl
>
> (or 'cc' - Sun's version)
>
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ifiles.zip
Type: application/x-zip-compressed
Size: 14929 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-bugs/attachments/20020913/34c5bf49/attachment.bin>