Re: Is memprof only caring about unfreed memory?



Owen Taylor [2007-08-22 14:57]:

Hi Owen,
I CC'ed the list, since this information can probably be useful to
others, too -- hope you don't mind :)

> On 8/21/07, Tilman Sauerbeck <tilman code-monkey de> wrote:
> > Hi,
> > I'm trying to use memprof to get some stats on which functions allocate
> > how much memory etc.
> >
> > The problem I'm having is that I can't get any profile at all for my
> > program. It's being executed just fine, but I can't get memprof to
> > generate a profile.
> >
> > That situation is reproducable with a program like this:
> >
> >   int main() {
> >     void *p = malloc(1024);
> >     free (p);
> >   }
> >
> > Once I remove the free() call and introduce a leak, memprof gives me a
> > profile. So it does seem as if memprof only keeps track of leaked memory.
> > Is it supposed to work that way, or did I stumble upon a bug?
> 
> I can't really respond to your particular problem ... I haven't even
> tried to compile memprof for years, much less use it. But to answer
> the general question, profiling and leak detection are separate
> functionality in memprof. When you create a profile, memprof shows you
> all memory that has been allocated and not freed, whether or not it's
> been leaked.

I was a bit sloppy with my language here. When I said "leaked" I
meant "not freed".

> Now, of course, in your example there is nothing to profile, so the
> best you are going to get is an empty list. But I wouldn't be

Okay, so memprof just doesn't provide the feature that I need:
For this silly example, I'd like it to tell me that main() allocated
1024 bytes in total.

From the description on http://www.gnome.org/projects/memprof/ I
understood that this was possible:
"It can generate a profile how much memory was allocated by each
function in your program."

> surprised if there was some bug in that corner case. And I also
> wouldn't be surprised if there was something wrong in general. My
> general experience is that when I was working on it, memprof only kept
> working until the next libc release, and then there was some new issue
> to debug.

Trunk seems to work as expected if I don't free the memory, so I
believe this is not what I'm seeing.

Thanks,
Tilman

-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Attachment: pgpORhHJpkKfP.pgp
Description: PGP signature



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]