Troman schreef:
----- Original Message ----- From: "Christian Ohm" <[EMAIL PROTECTED]>
To: <>
Sent: Thursday, December 28, 2006 4:52 PM
Subject: Re: [Warzone-dev] MALLOC/FREE issues
On Thursday, 28 December 2006 at 15:37, Troman wrote:
The issue of MALLOC was already raised in some of the previous
messages, and there seems to be something wrong with those MALLOC/FREE
macros. I noticed a memory leak in the scripting engine, to find out
what is actually causing it I set up a (script) loop with 10k
iterations with nothing but a string assignment in the loop body.

Due to the nature of this loop the interpreter was pushing
string/non-string data to the stack interchangeably, hence
allocation/deallocationg memory for strings. The memory usage went up
by ~3mb after each 10k iterations. I couldn't stumble upon any flaws
in the code, looks like MALLOC/FREE are causing this.  Anyway, after
replacng MALLOC/FREE with malloc/free the memory leak is gone.

Apart from that I noticed WZ memory usage is increasing by about 35 mb
each time a skirmish game is restarted, it wouldn't surprise me if it
was due to MALLOC/FREE anomalies.  Do we actually have to rely on
those two, ar would it make sense to simply replace them with
malloc/free? I remember someone (I think Per) was trying to rewrite
some functionality that dealt with wz memory usage that turned out to
be a non-trivial task, I hope it is not related to MALLOC/FREE.

Is that what you meant? There were no actual problems mentioned.
That's probably it. I only caught the late resounding of this discussion.
A memory pool system has a few advantages: It's faster (ideally), it
prevents memory fragmentation (the underlying OS might try to do that as
well), and it can have some debugging functionality. Debugging could be
done by external tools like valgrind (though valgrind is sloooow).
Fragmentation is more a theoretical problem, and speed... well, malloc
is probably faster than a bad memory pool system.
I just had a quick look at wz memory management and if I got it right
wz marks FREEd memory and can reuse it whenever MALLOC is called
again, I don't quite understand why it consumed more and more memory,
even though at the time of my test there was nothing else that could
have requested it.
We could replace MALLOC/FREE with a new (proven, so we need to find a
working GPL implementation) memory pool system, but the only real
advantage is built-in debugging, as long as we don't run lots of
mallocs/frees per frame. So I guess just ripping out the current system
(and leaving debugging to valgrind and other tools) and just using
malloc/free is a good start.
AFAIK valgrind is not available on windows, I don't know if there are
any good free tools available for windows comparable to valgrind, if
there are some though, then this shouldn't be an issue.
@Troman, where you using a debug or release build when finding out about
that huge memory usage?

I'm not sure, as I was switching back and forth several times yesterday, but I think it was a debug build.

Because the debug and release builds have two different implementations
of MALLOC/FREE, the release one being rather small and manageable
functions, the debug one being awfully large and are far from nicely


Warzone-dev mailing list

Reply via email to