topic Re: Memory Leak in /lib/libCsup.2 in Operating System - HP-UX

Memory Leak in /lib/libCsup.2

Mohanraj.E.K — Mon, 11 Sep 2006 11:02:23 GMT

We have noticed memory leak occuring in one of our Application Servers. Majorly the leaks are occuring in two shared libraries, firstly oracle specific shared library libclntsh.sl.9.0 and secondly in /lib/libCsup.2. Attached is the WDB 5.3 memory leak report.

We are not able to ascertain the cause of these leaks at our code level. It would be helpful to have the following info.

1. If this is a known problem?
2. If this is indeed a known problem, then do we have some patch for this?
3. Are any workarounds available for this problem?
4. Do we have any references to a similar problem occured in the past?

Environment:
HP-UX 11.11, aCC version A.03.60, RogueWave Library 7.3

*********************************

Re: Memory Leak in /lib/libCsup.2

Steven E. Protter — Mon, 11 Sep 2006 11:10:14 GMT

Shalom,

Normally memory leaks have more to do with bad application programmer code than with the libraries themselves.

I do recommend having your system to the June 2006 bi-annual patch set and having the most current aCC version installed that is compatible with your RogueWave Library.

SEP

Re: Memory Leak in /lib/libCsup.2

MAUCCI_2 — Wed, 13 Sep 2006 15:59:43 GMT

Hi,

you can't figure out where the leaks come from because the stack height is not big enough to hold it full

You should rerun your gdb session with
set heap-check frame-count 32

(32 should be enough;-)
Then please repost your new report.

++Cyrille

Re: Memory Leak in /lib/libCsup.2

ranganath ramachandra — Thu, 21 Sep 2006 02:01:47 GMT

you are looking at the topmost (#0) frame of the stack trace in each leak. this is not the best way to look at the leak trace.

you will see that in each case where the top frame is in libCsup.2, the bottom most frame is in liborb.sl.

gdb is reporting where malloc got called. as you would expect, the libCup.2 new operator implementation calls malloc. the real problem is with whoever is calling new so many times and not calling delete (directly or indirectly).

this is why cyrille is asking you to increase the stack frame count.