🚀 go-pugleaf

purify is an excellent commercial tool for this purpose.  But it is not
cheap.

Bob

wroot@my-deja.com wrote:

> Hi!
>
> I have asked this question in Linux newsgroups, but got no answer. I'm
> trying to see how much memory my program allocates (at its highest) and
> whether it deallocates all of it by the time the program finishes or
> leaks memory. Are there any tools for that?
>
> Thanks
>
> Wroot
>
> Sent via Deja.com
> http://www.deja.com/

In article <3A611A23.C9AA59AD@home.com>,
	Robert Anderson <rwa511@home.com> writes:
>wroot@my-deja.com wrote:
>> I have asked this question in Linux newsgroups, but got no answer. I'm
>> trying to see how much memory my program allocates (at its highest) and
>> whether it deallocates all of it by the time the program finishes or
>> leaks memory. Are there any tools for that?
>
>purify is an excellent commercial tool for this purpose.  But it is not
>cheap.

Electric fence is another, and free. I don't know for sure if it works
on Linux, but I would think it's quite likely to.

Some unixs ship with debugging malloc libraries - again I don't know
about Linux - might depend on your distribution.

-- 
Andrew Gabriel                              Andrew@cucumber.demon.co.uk
Consultant Software Engineer

wroot@my-deja.com writes:

> I have asked this question in Linux newsgroups, but got no answer. I'm
> trying to see how much memory my program allocates (at its highest) and
> whether it deallocates all of it by the time the program finishes or
> leaks memory. Are there any tools for that?

Recently I came across

  http://www.cbmamiga.demon.co.uk/mpatrol/

It was a little bit tedious to install for me, but it works very much
like purify or insure++ and is free software.

  Harald Kirsch.

-- 
----------------+------------------------------------------------------
Harald Kirsch   | kirschh@lionbioscience.com | "How old is the epsilon?"
LION Bioscience | +49 6221 4038 172          |        -- Paul Erd�s
       *** Please do not send me copies of your posts. ***

Andrew Gabriel wrote:
> 
> In article <3A611A23.C9AA59AD@home.com>,
>         Robert Anderson <rwa511@home.com> writes:
> >wroot@my-deja.com wrote:
> >> I have asked this question in Linux newsgroups, but got no answer. I'm
> >> trying to see how much memory my program allocates (at its highest) and
> >> whether it deallocates all of it by the time the program finishes or
> >> leaks memory. Are there any tools for that?
> >
> >purify is an excellent commercial tool for this purpose.  But it is not
> >cheap.
> 
> Electric fence is another, and free. I don't know for sure if it works
> on Linux, but I would think it's quite likely to.
> 
> Some unixs ship with debugging malloc libraries - again I don't know
> about Linux - might depend on your distribution.
> 
> --
> Andrew Gabriel                              Andrew@cucumber.demon.co.uk
> Consultant Software Engineer
Purify isn't available for Linux unfortunately. However there is
Insure++ from Parasoft which is similar and is available for Linux. It's
also more expensive than Purify. 

The problem I've found with tools like ElectricFence and dmalloc is that
they're useless on anything but a trivial application. For a real-world
application they make it so fat and slow as to be unusable.

David Peter <dave.peter@eu.citrix.com> writes:

...
> The problem I've found with tools like ElectricFence and dmalloc is
> that they're useless on anything but a trivial application. For a
> real-world application they make it so fat and slow as to be
> unusable.

Sure, because they have great features.  You normally have different
kinds of builds:

      debugging -- the binaries contain info for the debugger

                   maybe lots of memory-checking stuff

      production - the binaries may be stripped

                   memory leaks and problems have been debugged, so no
                   linking against dmalloc 

... if you're using autoconf you can provide a user option like
"--enable-debug" to turn on the debugging build that is not the
default.

-- 
--Ed Cashin                     integrit file-verification system:
  ecashin@coe.uga.edu           http://integrit.sourceforge.net/

    Note: If you want me to send you email, don't munge your address.

Ed L Cashin wrote:
> 
> David Peter <dave.peter@eu.citrix.com> writes:
> 
> ...
> > The problem I've found with tools like ElectricFence and dmalloc is
> > that they're useless on anything but a trivial application. For a
> > real-world application they make it so fat and slow as to be
> > unusable.
> 
> Sure, because they have great features.  You normally have different
> kinds of builds:
> 
>       debugging -- the binaries contain info for the debugger
> 
>                    maybe lots of memory-checking stuff
> 
>       production - the binaries may be stripped
> 
>                    memory leaks and problems have been debugged, so no
>                    linking against dmalloc
> 
> ... if you're using autoconf you can provide a user option like
> "--enable-debug" to turn on the debugging build that is not the
> default.
> 
> --
> --Ed Cashin                     integrit file-verification system:
>   ecashin@coe.uga.edu           http://integrit.sourceforge.net/
> 
>     Note: If you want me to send you email, don't munge your address.
Sure, I know all about debug and production builds - I'm a software
engineer. But as an SE I spend most of my time working with debug builds
and tools like dmalloc, good in principal though they may be, don't
really help if one's application ends up running 20 times slower than
normal.

David Peter wrote:

> Sure, I know all about debug and production builds - I'm a software
> engineer. But as an SE I spend most of my time working with debug builds
> and tools like dmalloc, good in principal though they may be, don't
> really help if one's application ends up running 20 times slower than
> normal.

	Why? For most applications, you should be able to just start it going
with automation and go to sleep.

	DS

David Schwartz <davids@webmaster.com> writes:

> David Peter wrote:
> 
> > Sure, I know all about debug and production builds - I'm a software
> > engineer. But as an SE I spend most of my time working with debug builds
> > and tools like dmalloc, good in principal though they may be, don't
> > really help if one's application ends up running 20 times slower than
> > normal.
> 
> 	Why? For most applications, you should be able to just start it going
> with automation and go to sleep.

Anyway, twenty times slower is nothing like my experience with
dmalloc.  It's not a human-noticable speed difference when I use it,
and there's a significant amount of malloc-demalloc'ing in the code
I'm thinking of.

Maybe the dmalloc mailing list would help.

-- 
--Ed Cashin                     integrit file-verification system:
  ecashin@coe.uga.edu           http://integrit.sourceforge.net/

    Note: If you want me to send you email, don't munge your address.

David Schwartz wrote in message <3A64168B.631CD17C@webmaster.com>...
>
>David Peter wrote:
>
>> Sure, I know all about debug and production builds - I'm a software
>> engineer. But as an SE I spend most of my time working with debug builds
>> and tools like dmalloc, good in principal though they may be, don't
>> really help if one's application ends up running 20 times slower than
>> normal.
>
> Why? For most applications, you should be able to just start it going
>with automation and go to sleep.

  Plenty of realtime applications have tight latencies and slowing down all
their operations by a significant amount means that the system will behave
in entirely different ways or fail altogether.  The usual example to quote
at this point would be image analysis software in a missile guidance
system...

            DaveK
--
They laughed at Galileo.  They laughed at Copernicus.  They laughed at
Columbus. But remember, they also laughed at Bozo the Clown.

Dave Korn wrote:
> 
> David Schwartz wrote in message <3A64168B.631CD17C@webmaster.com>...
> >
> >David Peter wrote:
> >
> >> Sure, I know all about debug and production builds - I'm a software
> >> engineer. But as an SE I spend most of my time working with debug builds
> >> and tools like dmalloc, good in principal though they may be, don't
> >> really help if one's application ends up running 20 times slower than
> >> normal.
> >
> > Why? For most applications, you should be able to just start it going
> >with automation and go to sleep.
> 
>   Plenty of realtime applications have tight latencies and slowing down all
> their operations by a significant amount means that the system will behave
> in entirely different ways or fail altogether.  The usual example to quote
> at this point would be image analysis software in a missile guidance
> system...
> 
>             DaveK
> --
> They laughed at Galileo.  They laughed at Copernicus.  They laughed at
> Columbus. But remember, they also laughed at Bozo the Clown.
Well, the application I mainly work on isn't realtime, but it is very
graphics intensive using X/Motif. Purify and Insure show a lot of
malloc/free operations.

Dave Korn wrote:

>   Plenty of realtime applications have tight latencies and slowing down all
> their operations by a significant amount means that the system will behave
> in entirely different ways or fail altogether.  The usual example to quote
> at this point would be image analysis software in a missile guidance
> system...

	If you're debugging a system like that for memory leaks, 99% chance
your input and output are going to and from a simulator. I don't think
you'd put a memory-leak detector onboard a missle. You'd have to get its
final analysis off the missile pretty quickly. ;)

	DS

David Schwartz wrote in message <3A66BFA0.18F71B8@webmaster.com>...
>
>Dave Korn wrote:
>
>>   Plenty of realtime applications have tight latencies and slowing down
all
>> their operations by a significant amount means that the system will
behave
>> in entirely different ways or fail altogether.  The usual example to
quote
>> at this point would be image analysis software in a missile guidance
>> system...
>
> If you're debugging a system like that for memory leaks, 99% chance
>your input and output are going to and from a simulator. I don't think
>you'd put a memory-leak detector onboard a missle. You'd have to get its
>final analysis off the missile pretty quickly. ;)

  Black box flight recorder! Black box flight recorder!

       DaveK
--
They laughed at Galileo.  They laughed at Copernicus.  They laughed at
Columbus. But remember, they also laughed at Bozo the Clown.