Hi

Here is the result of a normal project

Call trace for block $0000007FF7FED2C0 size 8
$00000000004002F0 GETCUSTOMPENSTYLE, line 23 of project1.lpr
$00000000004003C0 COMPUTEPOLYLINE, line 33 of project1.lpr
$000000000040049C main, line 47 of project1.lpr
$0000000000400168

Regards

from bgracontrols.

Thank you , appriciate it

Regards

from bgracontrols.

Hello @John-Smith75

I am not sure what happens here that leads to a memory leak, though looking at the code, it seems it is a dynamic array that is temporarily created. It is in principle handled by the compiler, so I presume it is a bug in the compiler, maybe for this particular CPU.

One way to test it would be to check if the following code leads to a memory leak:

type
  TBGRAPenStyle = array Of Single; 

var
  FCustomPenStyle: TBGRAPenStyle; 

function DuplicatePenStyle(ACustomPenStyle: array of single): TBGRAPenStyle;
var
  i: Integer;
begin
  setlength(result,length(ACustomPenStyle));
  for i := 0 to high(result) do
    result[i]:= ACustomPenStyle[i];
end;

function GetCustomPenStyle: TBGRAPenStyle;
begin
  result := DuplicatePenStyle(FCustomPenStyle);
end;

procedure ComputeWidePolylinePoints(const penstyle: TBGRAPenStyle);
begin
  // do stuff
end;

procedure ComputePolyline;
begin
  ComputeWidePolylinePoints(GetCustomPenStyle);
end;

begin
  setlength(FCustomPenStyle,2);
  FCustomPenStyle[0] := 3;
  FCustomPenStyle[1] := 1;
  ComputePolyline;
end.

By the way, does adding const in the declaration of DuplicatePenStyle avoids the leak?

function DuplicatePenStyle(const ACustomPenStyle: array of single): TBGRAPenStyle;

Regards

from bgracontrols.

Hi,

Thank you for the reply , unfortunately I do not know how to fix it.
I have tried different Lazarus versions with the same result.

Pitty as this is a great component.

from bgracontrols.

Hi,

I invite you to try the sample code. For this, create a simple program with only the provided code. I suppose the memory leak would happen as it is the same structure of calls.

Is it that you are considering to not use the component if the memory leak remain?

Regards

from bgracontrols.

Hi , thanks, I will try the code.

the problem is for example on a pi 4 1 GB the pi runs out of memory in +- 2 days on a 64bit OS
Hope there is a solution as I would like to still use it. Like the component a lot

Regards

from bgracontrols.

Hi

$0000000000475D18 GETCUSTOMPENSTYLE, line 54 of unit1.pas
$0000000000475DE8 COMPUTEPOLYLINE, line 64 of unit1.pas

Issue here
function GetCustomPenStyle: TBGRAPenStyle;
begin
result := DuplicatePenStyle(FCustomPenStyle);
end;
same here
procedure ComputePolyline;
begin
ComputeWidePolylinePoints(GetCustomPenStyle);
end;

heaptrace
Call trace for block $0000007FF7FBC560 size 8
$0000000000475D18 GETCUSTOMPENSTYLE, line 54 of unit1.pas
$0000000000475DE8 COMPUTEPOLYLINE, line 64 of unit1.pas
$0000000000475EBC FORMCREATE, line 82 of unit1.pas
$000000000045D808 DOCREATE, line 922 of include/customform.inc
$000000000045B404 AFTERCONSTRUCTION, line 77 of include/customform.inc
$0000000000464B04 CREATE, line 3213 of include/customform.inc
$000000000046FF9C CREATEFORM, line 2243 of include/application.inc
$000000000041EECC main, line 31 of project1.lpr
$0000007FF73B6E18
$000000000041ED58
$000000000073EBA0 INITRESOURCECOMPONENT, line 804 of lresources.pp
$0000000000461200 PROCESSRESOURCE, line 2032 of include/customform.inc
$000000000046108C CREATE, line 2020 of include/customform.inc
$0000000000464AD0 CREATE, line 3212 of include/customform.inc
$000000000046FF9C CREATEFORM, line 2243 of include/application.inc
$000000000041EECC main, line 31 of project1.lpr

Regards

from bgracontrols.

I can also give you remote access to a pi using vnc

from bgracontrols.

Thank you very much for the detailed information.

Ok, so this confirms the bug is in the FPC compiler. It may be related to:
https://gitlab.com/freepascal.org/fpc/source/-/issues/40225

I've tried to reproduce the bug on my system but I didn't get the memory leak. I suggest we create the bug report together. Here is a draft below. Can you fill the system information?

I noted that you tested it on a project with a form. It would be better to test it on a "simple program". It is one of the option when creating a new project. It will give you a simple file which content can be replaced completely by the sample code I've provided.

This way it can be fixed by the FPC team without using Lazarus. The resulting log of Heaptrc would be slightly different. Can you provide what it produces with a simple program?

Here is the link to create the issue in FPC if you feel confident to do so:
https://gitlab.com/freepascal.org/fpc/source/-/issues/new

Issue

Memory leak with dynamic array passed as const parameter

Summary

A user of my library noticed a memory leak related to a dynamic array. It is passed as const parameter and does not seem to be freed afterwards. It may be related to #40225.

System Information

• Operating system:
• Processor architecture:
• Compiler version:
• Device:

Steps to reproduce

Run the project with heaptrc unit.

Example Project

type
  TBGRAPenStyle = array Of Single;

var
  FCustomPenStyle: TBGRAPenStyle;

function DuplicatePenStyle(ACustomPenStyle: array of single): TBGRAPenStyle;
var
  i: Integer;
begin
  setlength(result,length(ACustomPenStyle));
  for i := 0 to high(result) do
    result[i]:= ACustomPenStyle[i];
end;

function GetCustomPenStyle: TBGRAPenStyle;
begin
  result := DuplicatePenStyle(FCustomPenStyle);
end;

procedure ComputeWidePolylinePoints(const penstyle: TBGRAPenStyle);
begin
  // do stuff
end;

procedure ComputePolyline;
begin
  ComputeWidePolylinePoints(GetCustomPenStyle);
end;

begin
  setlength(FCustomPenStyle,2);
  FCustomPenStyle[0] := 3;
  FCustomPenStyle[1] := 1;
  ComputePolyline;
end.

What is the current bug behavior?

The dynamic array created by DuplicatePenStyle is not freed.

What is the expected (correct) behavior?

The dynamic array is supposed to be freed.

Relevant logs and/or screenshots

Call trace for block $0000007FF7FBC560 size 8
$0000000000475D18 GETCUSTOMPENSTYLE, line 54 of unit1.pas
$0000000000475DE8 COMPUTEPOLYLINE, line 64 of unit1.pas
$0000000000475EBC FORMCREATE, line 82 of unit1.pas
$000000000045D808 DOCREATE, line 922 of include/customform.inc
$000000000045B404 AFTERCONSTRUCTION, line 77 of include/customform.inc
$0000000000464B04 CREATE, line 3213 of include/customform.inc
$000000000046FF9C CREATEFORM, line 2243 of include/application.inc
$000000000041EECC main, line 31 of project1.lpr
$0000007FF73B6E18
$000000000041ED58
$000000000073EBA0 INITRESOURCECOMPONENT, line 804 of lresources.pp
$0000000000461200 PROCESSRESOURCE, line 2032 of include/customform.inc
$000000000046108C CREATE, line 2020 of include/customform.inc
$0000000000464AD0 CREATE, line 3212 of include/customform.inc
$000000000046FF9C CREATEFORM, line 2243 of include/application.inc
$000000000041EECC main, line 31 of project1.lpr

Possible fixes

I suppose the problem happen when passing the parameter to ComputeWidePolylinePoints.

from bgracontrols.

If you can upload a compiled binary then I can download , test it and send you the results.
Just to be sure if it is not my FPC or Lazarus

Best Regards

from bgracontrols.

The trace you've provided is fine, thank you very much.

Now what shall I put in the System Information paragraph?

Operating system:
Processor architecture: ARM 64
Compiler version:
Device:

from bgracontrols.

My pleasure and thank you

FPC 3.2.2
Lazarus 3.0
ARM 64

Best Regards

from bgracontrols.

The operating system is Linux? The device is a PC?

from bgracontrols.

Yes Linux Rasbiam Bullsey .
It is a raspberry pi device (Arm 64)

from bgracontrols.

Ok. With all the information I was able to file the bug report:
https://gitlab.com/freepascal.org/fpc/source/-/issues/40605

I invite you to log in the bugtracker and enable the notifications about the issue, so that you will know how it progresses.

from bgracontrols.