Sun Workshop 5.0, though I also have Sun Studio 9 demo compilers.  With
Studio 9 I don't  have a gui, so I have to use ddd as front end for
debugger.

I have a daemon which seems to have a memory leak, as its size has
tripled over the last 4 days.

Does anyone have any experience in detecting memory leaks in
daemons/servers/long-running-process?

Any tips on hunting down a leak?  I don't have time to step through a
debugger for 2 days.  Getting a core, and analyzing it doesn't really
help, as I can't see lost memory (that I know of). I am not sure if a
memcheck in the the debugger would work or not, as the process never
really ends.  I tried print statements in all Constructor/Destructors,
and it appears to be 1:1, so I must be missing something elsewhere.

Any ideas would be great.

~Shea M.

[ Post a follow-up to this message ]

Shea Martin wrote:
> Sun Workshop 5.0, though I also have Sun Studio 9 demo compilers.  With
> Studio 9 I don't  have a gui, so I have to use ddd as front end for
> debugger.
>
> I have a daemon which seems to have a memory leak, as its size has
> tripled over the last 4 days.
>
> Does anyone have any experience in detecting memory leaks in
> daemons/servers/long-running-process?
>
> Any tips on hunting down a leak?  I don't have time to step through a
> debugger for 2 days.  Getting a core, and analyzing it doesn't really
> help, as I can't see lost memory (that I know of). I am not sure if a
> memcheck in the the debugger would work or not, as the process never
> really ends.  I tried print statements in all Constructor/Destructors,
> and it appears to be 1:1, so I must be missing something elsewhere.
>
> Any ideas would be great.
>
> ~Shea M.
>

I should mention that the daemon opens 3 files for writing.  My process
has grown from 2.5 MB to 6.2 MB, and the total size of the 3 files is
only 9k.

~S

[ Post a follow-up to this message ]

Shea Martin <smartin@arcis.com> writes:

> Shea Martin wrote: 
>
> I should mention that the daemon opens 3 files for writing.  My process
> has grown from 2.5 MB to 6.2 MB, and the total size of the 3 files is
> only 9k.

I have found tools like Purify to be useful for finding memory
leaks on Solaris, especially the subtler ones. More info on
Purify is at www.rational.com (which redirects to IBM now).

-SEan

[ Post a follow-up to this message ]

Sean Burke wrote:
>
> Purify is at www.rational.com (which redirects to IBM now).
>
> -SEan
>

When did that happen? Does that increase the chances of seeing Pufify
for AIX? Pardon me if that's a stupid question.

Carl

[ Post a follow-up to this message ]

Shea Martin wrote:
> Shea Martin wrote:
> 
>
> I should mention that the daemon opens 3 files for writing.  My process
> has grown from 2.5 MB to 6.2 MB, and the total size of the 3 files is
> only 9k.
>
> ~S
>

If your daemon does a lot of memory allocation and deallocation, you may
be seeing a normal result of an allocator that does not do "garbage
collection".  Whenever the allocator cannot find an appropriate block to
allocate, rather than looking for adjacent unallocated blocks to fill
the request, it will request more memory from the system.  However, at
some point you tend to reach an equilibrium, but not necessarily.
Sometimes it helps a great deal to allocate large chunks, and re-use
those chunks yourself, only going to the allocator if you need more
memory.  An example would be: if you are maintaining a dynamically sized
table, get 64 entries at a time instead of the single entry you need.
You have to keep count of the usage yourself.

--

Fletcher Glenn

[ Post a follow-up to this message ]

carl mcguire <abuse@spamcop.net> writes:
 
>
> When did that happen?

PureAtria was aquired by Rational in April of 1997.
Rational was aquired by IBM in February of 2003.

> Does that increase the chances of seeing Pufify for AIX?

I've heard that it is "in the works".

Purify competitors on AIX are Insure++ from ParaSoft and ZeroFault
from ZeroFault Group. Rather than waiting for Purify, you may want
to give competition a try.

Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.

[ Post a follow-up to this message ]

Paul Pluzhnikov wrote:


> Purify competitors on AIX are Insure++ from ParaSoft and ZeroFault
> from ZeroFault Group. Rather than waiting for Purify, you may want
> to give competition a try.
>
> Cheers,

Already have done (both), but it's a political problem when developing
across AIX, Solaris, HP, Linux etc. It is difficult enough to get budget
approval for one of these tools, let alone two. Plus, we are partnered
with IBM ;-)

Thanks.

[ Post a follow-up to this message ]

carl mcguire <abuse@spamcop.net> writes:

> but it's a political problem when developing across AIX, Solaris,
> HP, Linux etc.

Insure supports all of the above (on all processors). Purify doesn't.

> Plus, we are  partnered with IBM ;-)

If your memory leak can wait; sure, go for it.

> It is difficult enough to get budget approval for one of these tools

This looks like a red herring to me: you tell your manager:

We have a problem [describe the problem and its effects] (if you
only have *one* problem, good for you).

I can look for it "by hand", and it will only take me a couple
of days to find (if I am lucky). And I would not know if I
introduced any new ones by fixing the ones I find.

Or I can use automation, find problems like this in an hour,
and *know* the problem is fixed. That will cost $X,000

Any manager in his right mind will make a quick calculation,
multiply savings by the number of developers, and make the right
decision :-)

Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.

[ Post a follow-up to this message ]

Paul Pluzhnikov wrote:
> carl mcguire <abuse@spamcop.net> writes:

[SNIP]

>=20
>=20 
>=20
>=20
> This looks like a red herring to me: you tell your manager:
>=20
>   We have a problem [describe the problem and its effects] (if you
>   only have *one* problem, good for you).
>=20
>   I can look for it "by hand", and it will only take me a couple
>   of days to find (if I am lucky). And I would not know if I
>   introduced any new ones by fixing the ones I find.
>=20
>   Or I can use automation, find problems like this in an hour,
>   and *know* the problem is fixed. That will cost $X,000
>=20
> Any manager in his right mind will make a quick calculation,
> multiply savings by the number of developers, and make the right
> decision :-)
>=20
> Cheers,

Paul,

1. First, you assume that a manager has a mind 

2. There are situations in certain business climates
where the bean counters have edicted "Thou shalt not purchase
ANYTHING without a 'business case' and executive level approval."

Often, by the time you get that (sometimes weeks), the
current problem has been solved and there is no longer
a perceived need for the product ... until the next time
it (in this case a memory leak) happens.

As the old saying goes, "penny wise and pound foolish."


--=20
=D1
"It is impossible to make anything foolproof because fools are so=20
ingenious" - A. Bloch

[ Post a follow-up to this message ]

Paul Pluzhnikov wrote:
> carl mcguire <abuse@spamcop.net> writes:
>
> 
>
>
> Insure supports all of the above (on all processors). Purify doesn't.
>
> 
>
>
> If your memory leak can wait; sure, go for it.
>
> 
>
>
> This looks like a red herring to me: you tell your manager:
>
>   We have a problem [describe the problem and its effects] (if you
>   only have *one* problem, good for you).
>
>   I can look for it "by hand", and it will only take me a couple
>   of days to find (if I am lucky). And I would not know if I
>   introduced any new ones by fixing the ones I find.
>
>   Or I can use automation, find problems like this in an hour,
>   and *know* the problem is fixed. That will cost $X,000
>
> Any manager in his right mind will make a quick calculation,
> multiply savings by the number of developers, and make the right
> decision :-)
>
> Cheers,
As I junior developer, I am worried that my manager (not a programmer) would
feel that I am not good enough to find it by hand, and a poor programmer to 
find
the leak in the first place.
~S

[ Post a follow-up to this message ]