Am Donnerstag, 28. Dezember 2006 20:10 schrieb Giel van Schijndel: > 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.htm > >>l > >> > >> 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 think there are also parts which try to workaround a bug in debug build, but crash in release build... Should be the other way round actually. I think that also happened in the memory part.
--Dennis
pgpAXN3liRoKg.pgp
Description: PGP signature
_______________________________________________ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev