Re: g_print memory leak according to mtrace v2.3.2

["David Necas (Yeti)" <yeti physics muni cz>]

On Thu, Sep 09, 2004 at 01:57:33PM -0500, Kurt Newman wrote:
> 
> When I do another g_print() test within a loop, the output mtrace
> logging increases in size (I'm not sure if this indicates more memory
> leaks or just memory tracing).  I'm not really experienced enough to dump
> this to stdout with some sort of debugging tool to see what portions of
> "the leak" are in certain areas of memory (e.g. stack or wherever).

I'd recommend valgrind.  It can show nice stack traces, but
in this simple case a summary is enough, so just run

valgrind --tool=memcheck --leak-check=yes ./ghelloworld

for both single "Hello world!" and a loop and you'll see:
- valgrind thinks all memory is `still reachable' at the end,
  that's good
- the amount of `leaked' but reachable memory is the same in
  both cases, that's good too

So unless you have serious suspicion there's really a memory
leak, this could placate you.

You can see all the gory details with just a few more
valgrind options...

> With that said, I believe mtrace is supposed to latch itself onto hooks
> within libc's malloc, realloc, and free functions.  Thus, static
> memory shouldn't even be an issue.

Static was used in the `allocated once in program lifetime'
sense.

Yeti


--
Do not use tab characters. Their effect is not predictable.