Re: [Adonthell-devel] Memleaks!

[Kai Sterker]

On Sat, 28 Sep 2002 19:58:35 +0200 Alexandre Courbot wrote:

> What does that mean? It it's not freed at exit this means there is
> something wrong, either in one of our destructors, either in our
> Python references count management, no? Of course, as long as it
> doesn't mess up things during the gameplay, it's nearly ok.

I mean that some of those problems seem to come from the libs we use.
They seem to no clean up properly on exit, but I doubt that this affects
gameplay in any way. Guess a large part is our fault though, and I'll
try to track those down.


> Yeah, but you seem to say that Valgrind hasn't reported that as a
> memleak, which afraids me. It's a memleak, obviously! I guess we
> forget to py_decref it somewhere. Or maybe we could do a del in the
> Python even launched when we quit the menu (if any).

Well, depends how you define memleak ;). what we have is memory that is 
no longer used but not free'd. There is still a valid pointer to that
memory. With a "real" memleak, the memory would still be allocated, but
with no pointer to it. So in our case this means we gotta find those
pointers and delete them. And that's not so simple, 'cause with those
python scripts one has to make sure that stuff isn't deleted twice. It's
quite tricky. I already tried a few things, but either it didn't change
anything, or it crashed. But I'll keep on trying :). 


> Oh, I'll have a look at Valgrind myself, to see if it's that good! :)

>From all the tools I've tried so far (mtrace, memprof, mpatrol) it's
definately the best. memprof only finds "real" memleaks, mpatrol is damn
slow and mtrace does not really help locating the source of the leak.
So yeah, I like valgrind :).

Kai