Operating System - HP-UX
1753427 Members
4947 Online
108793 Solutions
New Discussion юеВ

Re: Memory Leak in /lib/libCsup.2

 
Mohanraj.E.K
New Member

Memory Leak in /lib/libCsup.2

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

*********************************
3 REPLIES 3
Steven E. Protter
Exalted Contributor

Re: Memory Leak in /lib/libCsup.2

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
Steven E Protter
Owner of ISN Corporation
http://isnamerica.com
http://hpuxconsulting.com
Sponsor: http://hpux.ws
Twitter: http://twitter.com/hpuxlinux
Founder http://newdatacloud.com
MAUCCI_2
Frequent Advisor

Re: Memory Leak in /lib/libCsup.2

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
ranganath ramachandra
Esteemed Contributor

Re: Memory Leak in /lib/libCsup.2

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.
 
--
ranga
[i work for hpe]

Accept or Kudo