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. _______________________________________________ gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list
