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 summa
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 double-
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 t
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
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..
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 about.
