Troman schreef: > ----- Original Message ----- From: "Christian Ohm" <[EMAIL PROTECTED]> > To: <warzone-dev@gna.org> > 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. >> https://lists.berlios.de/pipermail/warzone-dev/2005-September/000538.html >> >> 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 written. -- Giel
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
