Solaris dlopen-related memory leak (C API)

Solaris dlopen-related memory leak (C API)

am 27.08.2002 21:57:43 von Ben

>Description:
dlopen libmysqlclient, mysql_init, mysql_close, dlclose, repeat.
This will cause the process' memory footprint to quickly grow.
This doesn't appear to happen on my RedHat 7.3 i86 linux box.
I've tried this with gcc 2.95.2 and (this report) 3.1
This is causing memory leaks with an NSS module I'm writing which
must be dlopened.
>How-To-Repeat:
Here's the C code

============================================================ ================
#include
#include
#include

#define MYLIB "/usr/local/lib/mysql/libmysqlclient.so"

int main (void)
{
void *handle;
int *iptr, (*open)(MYSQL *), (*close)(MYSQL *);
MYSQL link;
char *error;

while (1)
{
handle = dlopen (MYLIB, RTLD_LAZY);
if (!handle)
{
fputs (dlerror(), stderr);
exit (1);
}

open = dlsym (handle, "mysql_init");
if ((error = dlerror ()) != NULL)
{
fprintf (stderr, "%s\n", error);
exit (1);
}
close = dlsym (handle, "mysql_close");
if ((error = dlerror ()) != NULL)
{
fprintf (stderr, "%s\n", error);
exit (1);
}

(*open)(&link);
(*close)(&link);

dlclose (handle);
}
}
============================================================ ================
Compiled with 'gcc -g -I /usr/local/include/mysql -o tst tst.c -ldl'

Run the command, watch its consumption in another window.
Ctrl-c before it eats your system alive :-)

>Fix:
Unknown. My guess is there's a one-time init (IE mysql_once_init() ?)
thing going on that's not getting freed with mysql_close.
If you force dlclose to be ineffective by linking the executable with
"-z nodelete", the leak stops, indicating it's related to unreleased
memory at the time of dlclose(). However, "-z nodelete" isn't an
appropriate fix.
I've even found that memset'ing link to all 0's and calling ONLY
mysql_close (*close in the example) causes leaks. I can't figure
out what in libmysql.c (and related) is causing it. I'm also
perplexed at how this doesn't happen in Linux - however I don't
yet see an indication that this is a Solaris bug, as I can, instead
of mysql_init/mysql_close, use malloc/free, and the leak does NOT
occur.


>Submitter-Id: Ben Goodwin
>Originator: Ben Goodwin
>Organization: None
>MySQL support: none
>Synopsis: Solaris dlopen-related memory leak (C API)
>Severity: serious
>Priority: medium
>Category: mysql
>Class: sw-bug
>Release: mysql-3.23.52 (Source distribution)
>Server: /usr/local/bin/mysqladmin Ver 8.23 Distrib 3.23.52, for pc-solaris2.8
on i386
Copyright (C) 2000 MySQL AB & MySQL Finland AB & TCX DataKonsult AB
This software comes with ABSOLUTELY NO WARRANTY. This is free software,
and you are welcome to modify and redistribute it under the GPL license

Server version 3.23.52
Protocol version 10
Connection Localhost via UNIX socket
UNIX socket /tmp/mysql.sock
Uptime: 10 hours 20 min 21 sec

Threads: 2 Questions: 15759 Slow queries: 0 Opens: 8 Flush tables: 1 Open t
ables: 2 Queries per second avg: 0.423
>Environment:
x86 Solaris 8 box. Patched with 8/21/02 Recommended set.

System: SunOS foo 5.8 Generic_108529-15 i86pc i386 i86pc
Architecture: i86pc

Some paths: /usr/bin/perl /usr/ccs/bin/make /usr/local/bin/gmake /usr/local/bin
/gcc
GCC: 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/l
d --disable-nls
Thread model: posix
gcc version 3.1
Compilation info: CC='gcc' CFLAGS='' CXX='g++' CXXFLAGS='' LDFLAGS=''
LIBC:
-rw-r--r-- 1 root bin 1589264 Aug 21 11:32 /lib/libc.a
lrwxrwxrwx 1 root root 11 May 27 13:44 /lib/libc.so -> ./libc.so.
1
-rwxr-xr-x 1 root bin 944544 Aug 21 11:32 /lib/libc.so.1
-rw-r--r-- 1 root bin 1589264 Aug 21 11:32 /usr/lib/libc.a
lrwxrwxrwx 1 root root 11 May 27 13:44 /usr/lib/libc.so -> ./libc
..so.1
-rwxr-xr-x 1 root bin 944544 Aug 21 11:32 /usr/lib/libc.so.1
Configure command: ./configure --with-debug
Perl: This is perl, version 5.005_03 built for i86pc-solaris


------------------------------------------------------------ ---------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)

To request this thread, e-mail bugs-thread12419@lists.mysql.com
To unsubscribe, e-mail

Re: Solaris dlopen-related memory leak (C API)

am 30.08.2002 13:19:15 von Sinisa Milivojevic

ben@atomicmatrix.net writes:
> >Description:
> dlopen libmysqlclient, mysql_init, mysql_close, dlclose, repeat.
> This will cause the process' memory footprint to quickly grow.
> This doesn't appear to happen on my RedHat 7.3 i86 linux box.
> I've tried this with gcc 2.95.2 and (this report) 3.1
> This is causing memory leaks with an NSS module I'm writing which
> must be dlopened.
> >How-To-Repeat:
> Here's the C code
>
> ============================================================ ================
> #include
> #include
> #include
>
> #define MYLIB "/usr/local/lib/mysql/libmysqlclient.so"
>
> int main (void)
> {
> void *handle;
> int *iptr, (*open)(MYSQL *), (*close)(MYSQL *);
> MYSQL link;
> char *error;
>
> while (1)
> {
> handle = dlopen (MYLIB, RTLD_LAZY);
> if (!handle)
> {
> fputs (dlerror(), stderr);
> exit (1);
> }
>
> open = dlsym (handle, "mysql_init");
> if ((error = dlerror ()) != NULL)
> {
> fprintf (stderr, "%s\n", error);
> exit (1);
> }
> close = dlsym (handle, "mysql_close");
> if ((error = dlerror ()) != NULL)
> {
> fprintf (stderr, "%s\n", error);
> exit (1);
> }
>
> (*open)(&link);
> (*close)(&link);
>
> dlclose (handle);
> }
> }
>=========================================================== =================

[skip]


Judging by info supplied, leak is more probable to happen in Solaris
dlclose() then in our library.

If it does not leak on RedHat and if it does not leak if you call in
the loop

while (1)
{
mysql_init();
mysql_close();
}

Then it is not our leak.

--
Regards,
__ ___ ___ ____ __
/ |/ /_ __/ __/ __ \/ / Mr. Sinisa Milivojevic
/ /|_/ / // /\ \/ /_/ / /__ MySQL AB, Fulltime Developer
/_/ /_/\_, /___/\___\_\___/ Larnaca, Cyprus
<___/ www.mysql.com


------------------------------------------------------------ ---------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)

To request this thread, e-mail bugs-thread12438@lists.mysql.com
To unsubscribe, e-mail

Re: Solaris dlopen-related memory leak (C API)

am 30.08.2002 18:26:57 von Ben Goodwin

> Judging by info supplied, leak is more probable to happen in Solaris
> dlclose() then in our library.

It seems that way, but I've been unable to prove it. Can you recommend a
tool I could use to track this leak down with? I've been unsuccessful at
finding one that gives me what I need.

> If it does not leak on RedHat and if it does not leak if you call in
> the loop
[snip]
> Then it is not our leak.

That also makes sense. The only reason I continue down the possibility of
something wrong with MySQL is that the library gets compiled differently
(#ifdef's).

At this point I'll resume attempting to trace the location of the leak.
Again, if you're aware of a nice way to do this, I'd love to hear about it.

Thanks for replying!

-=| Ben



------------------------------------------------------------ ---------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)

To request this thread, e-mail bugs-thread12451@lists.mysql.com
To unsubscribe, e-mail

Re: Solaris dlopen-related memory leak (C API)

am 30.08.2002 19:27:41 von Sinisa Milivojevic

Ben Goodwin writes:
> > Judging by info supplied, leak is more probable to happen in Solaris
> > dlclose() then in our library.
>
> It seems that way, but I've been unable to prove it. Can you recommend a
> tool I could use to track this leak down with? I've been unsuccessful at
> finding one that gives me what I need.
>

You can try Purify, but I am donno if it will locate leaks in shared
libs.

> That also makes sense. The only reason I continue down the possibility of
> something wrong with MySQL is that the library gets compiled differently
> (#ifdef's).
>
> At this point I'll resume attempting to trace the location of the leak.
> Again, if you're aware of a nice way to do this, I'd love to hear about it.
>
> Thanks for replying!
>
> -=| Ben
>
>
>

--
Regards,
__ ___ ___ ____ __
/ |/ /_ __/ __/ __ \/ / Mr. Sinisa Milivojevic
/ /|_/ / // /\ \/ /_/ / /__ MySQL AB, Fulltime Developer
/_/ /_/\_, /___/\___\_\___/ Larnaca, Cyprus
<___/ www.mysql.com


------------------------------------------------------------ ---------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)

To request this thread, e-mail bugs-thread12453@lists.mysql.com
To unsubscribe, e-mail

UPDATE: Solaris dlopen-related memory leak (C API)

am 02.09.2002 22:18:51 von Ben Goodwin

I believe I've located the problem. It appears that using getservbyname()
in a dlopen/dlclose situation in Solaris causes a memory leak. A standalone
(no dlopen/dlclose) app does NOT leak. I'll submit a bug report to Sun now.
Thanks for letting me waste your time :-)

-=| Ben





------------------------------------------------------------ ---------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)

To request this thread, e-mail bugs-thread12471@lists.mysql.com
To unsubscribe, e-mail