Hi guys, it's me again

Sorry but I'll post again about how to trace memory leaks using heaptrc. Installation: Vista 32, Lazarus 1.1 2012/11/15 SVN rev. 39279, FPC 2.6.1 WinCE X-compiler installed.

Debug output is checked, but whatever the link configuration could be (automatic, stabs, Dwarf gives termination exceptions) with or without external dbg file, the only output I get from feaptrc is this: D:\Compiled\Lazarus\i386-win32\Leonidas.exe
Heap dump by heaptrc unit
70122 memory blocks allocated : 32813701/32985056
70078 memory blocks freed : 32813049/32984256
44 unfreed memory blocks : 652
True heap size : 1048576
True free heap : 1044224
Should be : 1044960
Call trace for block $001EA898 size 28
$0060787C IDSTACK_init, line 937 of
D:/Programmes/LazPk/Indy10_5_8/Lib/System/IdStack.pas $0040DBB4
$004120D1
$BAADF00D
$BAADF00D
$BAADF00D
$BAADF00D
$BAADF00D
Call trace for block $001E2FF0 size 10
$004233DF
$00423D5F
$004120D1
$BAADF00D
$BAADF00D
$BAADF00D
$BAADF00D
$BAADF00D
Call trace for block $001E30B0 size 17
$004233DF
$00423D5F
$004120D1
$BAADF00D
$BAADF00D
$BAADF00D
$BAADF00D
$BAADF00D
Call trace for block $001E3050 size 14
$004233DF
...
Leak view does not give more explanations. BTW, what kind of file is requested by the button "Resolve" ?

Any help would be appreciated.

Antonio.

Al 22/11/12 14:48, En/na Antonio Fortuny ha escrit:

Debug output is checked, but whatever the link configuration could be (automatic, stabs, Dwarf gives termination exceptions) with or without external dbg file, the only output I get from feaptrc is this:

Since I have the same problem and I use external dbg files, I wrote a quick'n'dirty python script that invokes gdb and adds the missing information. You have to call it like this:

python gdbleak.py < heaptrace.log > new_heaptrace.log

------------------------------------------------------------------- from subprocess import Popen,PIPE,STDOUT
import sys

class gdb:
def __init__(self, exe):
self._gdb=Popen(['gdb',exe],stdin=PIPE,stdout=PIPE,stderr=STDOUT) def __del__(self):
self._gdb.terminate()
def read(self):
s=''
while s[-5:]!='(gdb)':
s=s+self._gdb.stdout.read(1)
return s.split('\r\n')[:-1]
def write(self,command):
#print command
self._gdb.stdin.write(command+'\r\n')
return self.read()

g=None
while True:
linea=sys.stdin.readline()
if not linea:
sys.exit()
linea=linea.rstrip()
printlinea=linea
if linea.startswith('Heap dump by heaptrc unit'):
progname=prevlinea.split()[0]
if g:
del g
g=gdb(progname)
g.read()
if linea.startswith(' $'):
if g and len(linea.split())==1:
r=' '.join(g.write('info line'+linea.replace('$','*0x'))) if r.startswith(' Line'):
kk=r.split('starts')

lineinfo=kk[0].strip().replace('"','').replace("Line","line") funcname='unkn'
if len(kk)==2:
funcname=kk[1].split('<')[1].split('+')[0].split('>')[0] printlinea="%s %s, %s" % (linea,funcname,lineinfo) prevlinea=linea
print printlinea

Hi Luca.

Sorry but I don't know (yet) Python.

I've downloaded and installed Pyton 2.7.3 and it runs so far. When submitting ly file I get an error on every line: D:\Compiled\Lazarus\i386-win32>"c:\Program Files\Python\python.exe" < leonidas.mlk > leonidas.ht
File "<stdin>", line 1
D:\Compiled\Lazarus\i386-win32\Leonidas.exe
^
SyntaxError: invalid syntax
...
D:\Compiled\Lazarus\i386-win32>"c:\Program Files\Python\python.exe" < leonidas.mlk > leonidas.ht
File "<stdin>", line 1
Heap dump by heaptrc unit
^
SyntaxError: invalid syntax
...
D:\Compiled\Lazarus\i386-win32>"c:\Program Files\Python\python.exe" < leonidas.mlk > leonidas.ht
File "<stdin>", line 1
$006074FC IDSTACK_init, line 937 of
D:/Programmes/LazPk/Indy10_5_8/Lib/Sys
tem/IdStack.pas
^
IndentationError: unexpected indent
... removed dall header lines start with first address: D:\Compiled\Lazarus\i386-win32>"c:\Program Files\Python\python.exe" < leonidas.mlk > leonidas.ht
File "<stdin>", line 1
$0040DBB4
^
IndentationError: unexpected indent

... remove all leading spaces:
D:\Compiled\Lazarus\i386-win32>"c:\Program Files\Python\python.exe" < leonidas.mlk > leonidas.ht
File "<stdin>", line 1
$0040DBB4
^
SyntaxError: invalid syntax

Al 22/11/12 15:40, En/na Antonio Fortuny ha escrit:

For your convenience I attached the script instead of puttin it inline. Save it somewhere, make sure the correct gdb is in your PATH, then call it like this

"c:\Program Files\Python\python.exe" c:\wherever\you\saved\it\gdbleak.py < leonidas.mlk > leonidas.ht

Bye

Lazarus has a leak viewer (tools menu).

It also has an ability to resolve traces, but I am not sure, if it deals with external dbg files

Lazarus has a leak viewer (tools menu).

Yep, I know but it does not give more information about addresses

It also has an ability to resolve traces, but I am not sure, if it deals

What kind of file does it expect ?

The "Resolve" button, asks for the exe.

not sure if the dbg nill be found from there, or if the dbg could be specified...

Le 22/11/2012 16:20, Luca Olivetti a ?crit :

Ok Luca, it works but the result file is identical to the source file except the first new line: no additionnal information found or added

El 22/11/2012 14:48, Antonio Fortuny escribi?:

Hello,

Call trace for block $001EA898 size 28 $0060787C IDSTACK_init, line 937 of D:/Programmes/LazPk/Indy10_5_8/Lib/System/IdStack.pas

This is clear ;)

$0040DBB4 $004120D1

This two may come from Windows OS libraries, or maybe the fpc RTL functions (more probably).

$BAADF00D

This comes from an already freed object (BAD FOOD), so the first step could be to change all object.free by FreeAndNil(object).

Le 23/11/2012 12:37, Jos? Mejuto a ?crit :

Obviously and it is known memory leak

Annoying but can cope with it

Ouaou ! This means a lot of search !

Al 23/11/12 08:56, En/na Antonio Fortuny ha escrit:

> "c:\Program Files\Python\python.exe" c:\wherever\you\saved\it\gdbleak.py < leonidas.mlk > leonidas.ht Ok Luca, it works but the result file is identical to the source file except the first new line: no additionnal information found or added

Well, either gdb doesn't find any information or my script doesn't parse correctly the log (after all it's a quick and dirty hack). For example, if there are spaces in the path leading to the executable, it won't parse it correctly. You can try by running manually "gdb \path\to\the\exe" and then issuing manually

info line *0x0040dbb4

(it's just an example, use the addresses in the stack trace changing '$' to '*0x'). You should repeat it for every address in the stack trace, that's why I wrote a script in the first place.

El 23/11/2012 12:46, Antonio Fortuny escribi?:

Just to be sure you can load your project and run procexp (process explorer) which could show you the base address for the loaded DLLs, quite sure one would be loaded in the "00400000" address, which is the path to arrive the offending function (maybe sockets related).

Not that much, but the problem is that many code runs fine due that bug, using a freed object (not intentionally). Maybe some regexp replaces will help you.

You can review only code that deals with Indy activities.

i've done it actually. It took a reasonable time to explore and surprisingly, there is no Something.Free but only FreeAndNil(Others)

Even when I get a map out of the compilation process I'm not able to point out where the rubbish blocks could hide themselves.

I have to apologize because the memory leaks I was looking for wasn't a bug or malfunction. In fact what was worrying me were those $BAADFOOD block pointers which seem to point to memory locations that the program wants to free more than once.

Tanks to you all anyway for your time and help. When generating TRUE memomry leaks the debugger outputs all what is needed to point them out. I was wrong, sorry for that.

Anyway, there is still a question: is it any way to search and get rid of such multiple freed blocks ?

Antonio.

Al 23/11/12 15:27, En/na Antonio Fortuny ha escrit:

When generating TRUE memomry leaks the debugger outputs all what is needed to point them out.

Really? I never managed to get anything more than the address when using an external dbg file.

Bye

Le 23/11/2012 17:40, Luca Olivetti a ?crit :

Some weeks ago, I was probably misusing the debugger and heaptrc switches. In any case, when the code I've written generates memory leaks, heaptrc detects them and shows the code chain leading to all of them, EXCEPT for those generated either by any system unit or package for which the only data showed are lists af addreses. But even in this case I guess that with a corresponding prior compilation that would work too.

Antonio.

Bye