Hi everybody,

The program:
program memleak;
{$mode objfpc}{$H+}
uses
  cthreads;
begin
end.

If I run the program using valgrind I get the following output: ==1944== Invalid free() / delete /
delete[]
==1944== at 0x4025DFA: free
(vg_replace_malloc.c:323)
==1944== by 0x4171664: (within /lib/tls/i686/cmov/libc-2.9.so) ==1944== by 0x4020422: _vgnU_freeres (vg_preloaded.c:60) ==1944== by 0x40E5B23: _Exit (in /lib/tls/i686/cmov/libc-2.9.so) ==1944== by 0x405C77C: (below main) (in /lib/tls/i686/cmov/libc-2.9.so) ==1944== Address 0xffffffff is not stack'd, malloc'd or (recently) free'd

==1944== LEAK SUMMARY:
==1944== definitely lost: 0 bytes in 0 blocks.
==1944== possibly lost: 0 bytes in 0 blocks.
==1944== still reachable: 1,094 bytes in 5 blocks. ==1944== suppressed: 0 bytes in 0 blocks.

I use Kubuntu 9.04, fpc 2.2.4

Can I log this as a bug?

Regards
Wimpie

Wimpie Nortje wrote

If I run the program using valgrind I get the following output:

When I run it with heaptrc unit (-gh) enabled, I get the following output. Showing no memory leaks. I'm using Linux (Ubuntu 8.04.2) and FPC 2.2.5.

I don't know how valgrind works, so I actually have no clue. ;-) I just thought I would mention the heaptrc results.

=====================================
$ ./memleak
Heap dump by heaptrc unit
4 memory blocks allocated : 54/64
4 memory blocks freed : 54/64
0 unfreed memory blocks : 0
True heap size : 65536
True free heap : 65536
=====================================

Regards,
- Graeme -

I doubt it, since the error seems to occur in the C library. If you run with heaptrc, you should see that FPC does no allocations which it didn't free:

gru: >fpc -glh testh.pp
gru: >./testh
Heap dump by heaptrc unit
4 memory blocks allocated : 1023/1040
4 memory blocks freed : 1023/1040
0 unfreed memory blocks : 0
True heap size : 360448
True free heap : 360448
gru: >

Michael.

Something different. Why does yours allocate so much more memory? 54 vs 1023?

$ ./project1
Heap dump by heaptrc unit
4 memory blocks allocated : 54/64
4 memory blocks freed : 54/64
0 unfreed memory blocks : 0
True heap size : 65536
True free heap : 65536

Regards,
- Graeme -

Version 2.3.1 has a per-thread memory manager and some other features, I expect this causes some overhead.

Michael.

This invalid free is probably the reason for the memory leak.

It even happens for this program:

{$linklib c}
begin
end.

There is probably some error in FPC's startup code (the code in fpc/ rtl/linux/i386/cprt0.as) which doesn't initialise some libc pointer. You should indeed report a bug about this.

To Graeme and Michael: heaptrc is useless/irrelevant to analyse memory leaks reported inside libc. Such errors can always be due to wrong usage of the C library from within FPC code.

Jonas

Correct.

I just wanted to show that it is not due to FPC reserving some memory and not freeing it.

Michael.

OK it is logged.

Peter Popov wrote

Since you mentioned cprt0, you could try checking the order of initialization of libc and libgcc. This may have something to do with it, see alsohttp://bugs.freepascal.org/view.php?id=14265

Indeed, that may very well be the reason.

Jonas

In our previous episode, Jonas Maebe said:

I've been looking at this, and I think the link ordering can be easily expanded with a group concept.

It already has -XLAc=c,gcc,gcc_eh syntax that could be used to define a group.

I'll see if I can do this in the coming days, it could be enough to explore the concept till there is a definite solution. Note that this only works for libs, not for the .o files.

Since you mentioned cprt0, you could try checking the order of initialization of libc and libgcc. This may have something to do with it, see also http://bugs.freepascal.org/view.php?id=14265

Peter