Re: shall we have a TRACE_MEMORY mode

<blockquote type="CITE"><pre>
<font color="#000000">> As I follow Relyea Mike's recent post of possible memory leak, I think that</font>
<font color="#000000">> we are lack of a good way of identifing memory usage. Maybe we should also</font>
<font color="#000000">> remember __FILE__, __LINE__ etc for better memory usage diagnose when</font>
<font color="#000000">> TRACE_MEMORY is on?</font>
</pre></blockquote><br /> I find __FILE__ and __LINE__ very helpful when debugging both leaks and corruption.  I also
adda per-context (AllocSetContext.callCount) "call counter".  Each time a new piece of memory is allocated from a
context,I bump the call counter and record the new value in the header for that chunk of memory
(AllocChunkData.callCount). That way, I can look at a chunk of memory and know that it was allocated the 42nd time that
Igrabbed a hunk of memory from that context.  The next time I run my test, I can set a conditional breakpoint (cond
callCounter==42)that stops at the correct allocation (and thus grab my stack dump).  The numbers aren't always exactly
thesame, but in most cases they are.<br /><br /> Obviously you're now writing 12 extra bytes of overhead to each
AllocChunkData(__FILE__, __LINE__, and callCount) and 4 bytes to each AllocSetContext (callCount).<br /><br /><br />
           -- Korry<br /><br /><br /><br />