Per Inge Mathisen schreef: > On 4/4/07, The Watermelon <[EMAIL PROTECTED]> wrote: >> MSVC debug build is detecting massive memory leaks in the latest >> rev,which >> didnt happen in previous revs iirc(previous version only had few minor >> 'legacy' leaks in resource_lexer).Seems almost all memory >> allocations in >> frame.c are detected as 'memory leaks' upon exit.Maybe it has >> something to >> do with the removal of block.c and mem.c? > That is exactly what I would expect, since I suspected that the old > memory system was hiding memory leaks, and we can now see them more > clearly. Pumpkin's self-made memory leak detection code is no match > for modern memory debuggers. Well, actually I do not directly see any reason why memory leaks would now occur. Since all the previous MALLOC/FREE implementations did was allocating some additional memory (padding before and after the returned memory location) to detect out-of-bound writes, i.e. segmentation faults. I don't see however how this would relate to memory leaks since if the call to FREE isn't made before ripping out that memory system it wouldn't be made after?
That is to say, there will most certainly be _no_more_leaks_. But since I'm not sure how these memory debuggers work, (scanning for pointers I guess, like a garbage collector), I can't say whether ripping that out will affect detection of memory leaks. If it is like a garbage collector (scanning for pointers, and mark all non-referenced areas of memory as leaks) then I'd guess that the additional debugging information stuffed in the front of the allocated memory might look like pointers (in fact, part of it were pointers) and as such might confuse the debugger. -- Giel
Description: OpenPGP digital signature
_______________________________________________ Warzone-dev mailing list Warzoneemail@example.com https://mail.gna.org/listinfo/warzone-dev