I'll look into the bug report the next days.

Hello Florian,

Thanks for fixing the first bug, but
i am afraid, that there exist other memory related problems in FPC 2.0.3 (fixes branch). Our applications are not memory stable. (Related Bugs 7174, 7209)

I am in the moment not able to reproduce the problems in a small non ZEOS dependent app, but as the program is memory stable with delphi and fpc 2.0.2 i think of an bug in fpc.

If memory is acquired through:

"Getmem(x,size)"
and Freed through
"Freemem(x,size)"

I have a leak because Getmem reserves occasionally more mem as specified in size?

Is
"Getmem(x,size)" Freemem(x) correct?

I tried to check the program with valgrind 3.2

But valgrind 3.2 brings weird errors (garbled strings), when i compile with something above 2.0.2 stable. (Tested 2.0.3 and 2.11). With 2.0.2 Valgrind output is ok - but the program also :-)

Is valgrind support broken or do
I have to do something beyond setting the valgrind compiler switch?

Any ideas ?

For the brave and interested I include the
test project, Makefile & settings.

Required: Linux, i386, fpc 202 fpc 204, mysql 5

Steps:
1) svn co svn://firmos.at/zeos/trunk
2) make a link to it under /z
(/z -> /svnwork/zeos/trunk/)
3) unpack the demo
4) make a link from fos_fpc to testing fpc_version (fos_fpc -> /usr/local/lib/fpc/2.0.2/ppc386)
5) execute make zeos_memhole2
6) Change the Database,Host,User ... in the sourcecode
7) Change the table name in the SQL to some table in your database
8) start the program / you see the leak
(depending on fpc version)

Maybe some config files must be adjusted.

Greets,

helmut

No. Well, it will round up all allocations to a multiple of X bytes (X depends on whether you're on a 32 or 64 bit platform), but the same happens when freeing. If you free with a wrong size, you get a run time error 204.

Is "Getmem(x,size)" Freemem(x) correct?

Yes.

Is valgrind support broken or do I have to do something beyond setting the valgrind compiler switch?

You don't have to do anything but compile all your program's units and the program itself with the -gv switch.

Jonas

Note: all includes the RTL.

Vincent

No, an RTL compiled without debugging information is also fine. What's important is that you don't have any units compiled with debugging info, but without the -gv set (because Valgrind cannot handle some kinds of debugging info we generate, and -gv works around that).

Jonas