Graeme.
If you're using Lazarus, you'd probably be interested in using LeakView
package.
If you write out HeapTrc output into separate file, then LeakView dialog
will allow you to read the file, and present the the leaks in compact
tree-view style. Also, it will allow you to quick jump by
On 11/5/08, dmitry boyarintsev [EMAIL PROTECTED] wrote:
If you're using Lazarus, you'd probably be interested in using LeakView
package.
I started using it 10 minutes after it was committed to trunk. :-)
LeakView is very handy indeed!
One small suggestion though. Can you include the summary
On Mon, Nov 3, 2008 at 8:17 PM, Jonas Maebe [EMAIL PROTECTED] wrote:
3) I should trace the information from the bottom line to the top line...
It's a backtrace, like when an exception or run time error occurs. The top
line is the actual place where the allocation happened, the next is the
Sorry, but I know the output below is going to wrap horribly. I'm
self-taught when it comes to understanding the heaptrc output. I also
couldn't find clear documentation explaining the output.
From the information below, I gathered the following information. But
a few points I'm not sure
On 03 Nov 2008, at 15:10, Graeme Geldenhuys wrote:
1) Every Call trace for block is a memory leak, correct?
Yes.
2) Each Call trace for block is where the memory was allocated
(start being used)?
Allocated.
3) I should trace the information from the bottom line to the top
line...
Hello Graeme,
Monday, November 3, 2008, 3:10:49 PM, you wrote:
GG 1) Every Call trace for block is a memory leak, correct?
Yes, but take care, two strings in a non freed object (in example)
will produce three memory blocks. 1 for the object and one for each
string.
GG 2) Each Call trace for
