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.


Attachment: signature.asc
Description: OpenPGP digital signature

Warzone-dev mailing list

Reply via email to