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?

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


Attachment: signature.asc
Description: OpenPGP digital signature

Warzone-dev mailing list

Reply via email to