Memory leak in a shared library plugin

Brian Budge brian.budge@gmail.com
Wed Sep 30 06:17:00 GMT 2009


One possibility would be to make all memory allocations from a pool
that you control.  This would allow you to keep track of the memory
usage in plugin B.

Good luck,
  Brian

On Tue, Sep 29, 2009 at 10:42 PM, Cason, Kenny <kenny.cason@boeing.com> wrote:
> Howdy:
>
> I need help determining why memory continuously increases for a process that calls a shared library. Several sets of eyes have scanned the code for many months without success in stopping the memory leakage, if that's what it is. Your input on tools and/or advice are desperately needed.
>
> BTW: because the plugin described below does not run from the command line I have not had practical success with valgrind nor gdb. Purify is installed but hasn't been helpful either. I've heard rumors there might be a switch on the gcc compiler that will help but, if so, it's been elusive.
>
> Situation:
>
> Linux 2.6.9-89.0.9.ELsmp #1 SMP Wed Aug 19 08:07:15 EDT 2009 i686 i686 i386 GNU/Linux
> gcc/g++ 3.4.6
>
> Daemon A:
>  1) uses pPlugin B
>  2) is owned by a vendor and I have no source code
>  3) shows increasing memory usage when calling Plugin B, but not otherwise
>
>
> Plugin B:
>  1) written in-house so I have all the source code
>  2) is compiled and linked as a shared library
>  3) does not run from the command line so use of gdb and breakpoints is of little value
>
> The memory usage of Daemon A continuously increases while repeatedly calling Plugin B, which leads me to believe there is either a memory leak in Plugin B or in the mechanism used by Daemon A to call it. Using the command: ps -efl | grep <process> the memory size (SZ) shown every 5 seconds like this:
>
> F S UID        PID  PPID  C PRI  NI ADDR SZ WCHAN  STIME TTY          TIME CMD
> 4 S root     23129     1  0  78   0 - 59079 -      13:28 ?        00:00:39
> 4 S root     23129     1  0  78   0 - 59747 -      13:28 ?        00:00:40
> 4 S root     23129     1  0  78   0 - 59817 -      13:28 ?        00:00:40
> 4 S root     23129     1  0  78   0 - 59935 -      13:28 ?        00:00:41
> 4 S root     23129     1  0  78   0 - 60575 -      13:28 ?        00:00:42
> 4 S root     23129     1  0  78   0 - 60735 -      13:28 ?        00:00:44
> 4 S root     23129     1  0  78   0 - 61106 -      13:28 ?        00:00:45
> 4 S root     23129     1  0  78   0 - 61213 -      13:28 ?        00:00:46
> 4 S root     23129     1  0  78   0 - 61296 -      13:28 ?        00:00:47
> 4 S root     23129     1  0  78   0 - 61683 -      13:28 ?        00:00:48
> 4 S root     23129     1  0  78   0 - 61774 -      13:28 ?        00:00:49
> 4 S root     23129     1  0  78   0 - 61875 -      13:28 ?        00:00:50
> 4 S root     23129     1  0  78   0 - 61902 -      13:28 ?        00:00:51
>
> Target:
>
> Determine why the memory continuously increases (memory leak?) for Daemon A. If it's a memory leak is it in Daemon A or Plugin B.
>
>
> Proposed Solution:
>
> This is where I need someone smarter than me to elucidate the path to a solution. Please!!!
> As it is I have no visibility to where the memory is being eaten up nor why other than the "ps" command above.
>
>
> Thanks,
>
> -Kenny
>
> Information Security - Identity Management & Authorization Controls
> kenny.cason@boeing.com
> 206-550-0049
>
>
>



More information about the Gcc-help mailing list