Any idea how can I prevent Memory leaks?
lazarus / 34-Windows

----------------------------------------------------------------------
Joachim · 2019-12-11 08:41

Hello Friends,

Any idea how can I prevent memory leaks? It's causing great issue for
me.

----------------------------------------------------------------------
marcov · 2019-12-11 09:09

Quote from: Joachim on December 11, 2019, 09:41:37 amAny idea how can
I prevent memory leaks? It's causing great issue for me.

Deallocate the relevant classes and other allocations. If you have
problems with a specific case, you need to specify more about it.

----------------------------------------------------------------------
PaulRowntree · 2019-12-13 03:41

Quote from: Joachim on December 11, 2019, 09:41:37 amHello Friends,

Any idea how can I prevent memory leaks? It's causing great issue for
me.
If itis an  object based leak, you should carefully review your
Destructor codes ... something is not being released properly.
Do you do any memory allocation, or do you suspect underlying provided
codes?

----------------------------------------------------------------------
Zvoni · 2019-12-13 08:25

Quote from: Joachim on December 11, 2019, 09:41:37 amHello Friends,

Any idea how can I prevent memory leaks? It's causing great issue for
me.

Use proper sealing.....

----------------------------------------------------------------------
howardpc · 2019-12-13 11:03

In the Options for Project: xxx dialog for your project, click the
Debugging node and make sure in the Other debugging info section that
you have checked the Use Heaptrc unit (check for mem-leaks) (-gh)
checkbox.
This gives you a dialog (on Windows) or console listing after your
program runs and exits. If there are leaks, the list will help you
identify which lines in your code are giving rise to them.

----------------------------------------------------------------------
wp · 2019-12-13 11:58

Maybe it is instructive to illustrate Howard's post by an example -
see attached project.

When the button is clicked a StringList is created, some items are
added, and the StringList is assigned to the Items of a Listbox for
display.

The program runs fine, but it creates a memory leak because the List
is not destroyed at the end of the Button1Click method.

When "Use Heaptrc unit (check from mem-leaks) (-gh)" is checked in the
Project options / Debugging a long list of addresses is displayed when
the program ends. When you also have checked "Display line numbers in
run-time error backtraces (-gl)" information on the code lines are
displayed along with the addresses whenever possible.

The heaptrc output is displayed in the attached screenshot. It is a
bit overwhelming, I agree, because it contains all the locations
affected by the memory leak(s). But when you scan through the lines
you'll see "TFORM1_BUTTON1CLICK, line 37 of unit1.pas". This is
exactly where the memory leak was created: an object was created but
never destroyed.

When you add "List.Free" at the end of the procedure and run again
heaptrc reports "0 freed memory blocks" -- this is the success message
that the memory leak has been fixed (although the dialog is titled
"Error"...).

----------------------------------------------------------------------
PaulRowntree · 2019-12-13 15:11

I always thought that objects were automatically released when they
went out of scope.  Is this just Pascal Objects, and not instances of
a class (like the List object in your example)?

----------------------------------------------------------------------
mr-highball · 2019-12-13 15:21

class instances are not freed automatically when they go out of scope,
but old school "objects" are since they're stack allocated like
records (unless of course the new keyword is used)
see this for more info on that -> https://wiki.freepascal.org/Object

As far as the original question, heaptrc is always a good option, but
also designing libaries/applications using interfaces is a good way to
avoid leaks since they're automatically reference counted and once the
last reference goes out of scope, the destructor code is called.

----------------------------------------------------------------------
PaulRowntree · 2019-12-13 17:07

Quote from: mr-highball on December 13, 2019, 04:21:43 pmclass
instances are not freed automatically when they go out of scope, but
old school "objects" are since they're stack allocated like records
(unless of course the new keyword is used)
see this for more info on that -> https://wiki.freepascal.org/Object
Thanks mr-highball!  Time to review a lot of code ...

----------------------------------------------------------------------
marcov · 2019-12-13 17:23

Strictly speaking there are no automatically deallocated objects in
Pascal.

Yes, TP object declaration are autocleaning, but you can't use any
form of polymorphism when used statically, so even though called
"object", they aren't.

----------------------------------------------------------------------
howardpc · 2019-12-13 18:17

Quote from: PaulRowntree on December 13, 2019, 04:11:55 pmI always
thought that objects were automatically released when they went out of
scope.  Is this just Pascal Objects, and not instances of a class
(like the List object in your example)?
The LCL (based on the VCL model) does provide automatic release of a
particular group of classes provided:
The class descends from TComponentThe instance is given a non-Nil
Owner in its constructorWith those two provisos, the responsibility
for freeing the instance is passed to the instance's Owner, and the
programmer can forget about it.
Indeed, it is an error to manually Free such an instance.

----------------------------------------------------------------------
mr-highball · 2019-12-13 18:24

To add on my reference of using interfaces, I thought an example would
be good to demonstrate that even though automatic reference counting
frees the implementation class, forgetting to free class instances (in
this example a string list property) can still result in leaks.

Code: Pascal  [Select][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i {$Mode
delphi}program Project1;uses  Classes; type   { ITestInterface }  
ITestInterface = interface   
['{E634371B-7235-457C-A97C-2638F80F7680}']    //property methods   
function GetList: TStringList;     //properties    property List :
TStringList read GetList;  end;   { TLeakyTestInterfaceImpl }  
TLeakyTestInterfaceImpl = class(TInterfacedObject, ITestInterface) 
strict private    FList : TStringList;  private    function GetList:
TStringList;  public    property List : TStringList read GetList;    
constructor Create;    destructor Destroy; override;  end;   {
TPluggedLeakTestInterfaceImpl }   TPluggedLeakTestInterfaceImpl =
class(TInterfacedObject, ITestInterface)  strict private    FList :
TStringList;  private    function GetList: TStringList;  public   
property List : TStringList read GetList;     constructor Create;   
destructor Destroy; override;  end; { TPluggedLeakTestInterfaceImpl
} function TPluggedLeakTestInterfaceImpl.GetList: TStringList;begin 
Result := FList;end; constructor
TPluggedLeakTestInterfaceImpl.Create;begin  FList :=
TStringList.Create;end; destructor
TPluggedLeakTestInterfaceImpl.Destroy;begin  //unlike the leaky
example, this one properly frees the list  FList.Free;  inherited
Destroy;end; { TLeakyTestInterfaceImpl } function
TLeakyTestInterfaceImpl.GetList: TStringList;begin  Result :=
FList;end; constructor TLeakyTestInterfaceImpl.Create;begin  FList :=
TStringList.Create;end; destructor
TLeakyTestInterfaceImpl.Destroy;begin  //instead of freeing this
object, our "list" will be leaked  inherited Destroy;end; ////////////
//////////////////////////////////////////////////////////////////////
EXAMPLE//demonstration of using interfaces that will be freed
automatically once//all references go out of scope. we show that
proper destructor code//still needs to be used though, otherwise we
will leak memory//////////////////////////////////////////////////////
//////////////////////////var  LLeaky,  LPluggedLeak :
ITestInterface;begin  //initialize both types of implementations 
LLeaky := TLeakyTestInterfaceImpl.Create; //leaks List by not freeing
in destructor  LPluggedLeak := TPluggedLeakTestInterfaceImpl.Create;
//frees list in destructor   //after this "end" both interfaces
classes will be freed because  //there are no referencesend.

----------------------------------------------------------------------
MarkMLl · 2019-12-13 18:30

Quote from: PaulRowntree on December 13, 2019, 04:11:55 pmI always
thought that objects were automatically released when they went out of
scope.  Is this just Pascal Objects, and not instances of a class
(like the List object in your example)?

I'm afraid that that only applies to managed types such as strings and
dynamic arrays, not to objects (instances of classes) per se.

Objects are neither subject to deallocation when they go out of scope,
nor to periodic garbage collection when they are no longer referenced.

MarkMLl

----------------------------------------------------------------------
sash · 2019-12-14 17:50

Quote from: PaulRowntree on December 13, 2019, 04:11:55 pmI always
thought that objects were automatically released when they went out of
scope.
Pascal's objects are similar to C++'s class pointers: allocated on
heap.

Cons: you have to free them.
Pros: they can be passed across scopes (without pointer syntax).

----------------------------------------------------------------------
del · 2019-12-24 09:16

Quote from: PaulRowntree on December 13, 2019, 04:11:55 pmI always
thought that objects were automatically released when they went out of
scope.  Is this just Pascal Objects, and not instances of a class
(like the List object in your example)?
That's C++.

----------------------------------------------------------------------
sash · 2019-12-24 09:23

Quote from: del on December 24, 2019, 10:16:44 amQuote from:
PaulRowntree on December 13, 2019, 04:11:55 pmI always thought that
objects were automatically released when they went out of scope.  Is
this just Pascal Objects, and not instances of a class (like the List
object in your example)?
That's C++.
C++ does NOT release heap-allocated (myType* ptr = new myType())
memory automatically.

----------------------------------------------------------------------
del · 2019-12-24 09:33

Quote from: sash on December 14, 2019, 06:50:17 pm
Pascal's objects are similar to C++'s class pointers: allocated on
heap.

Cons: you have to free them.
Pros: they can be passed across scopes (without pointer syntax).
In C++ you avoid pointer syntax by using reference syntax.

----------------------------------------------------------------------
del · 2019-12-24 09:37

Quote from: sash on December 24, 2019, 10:23:26 amQuote from: del on
December 24, 2019, 10:16:44 amQuote from: PaulRowntree on December 13,
2019, 04:11:55 pmI always thought that objects were automatically
released when they went out of scope.  Is this just Pascal Objects,
and not instances of a class (like the List object in your example)?
That's C++.
C++ does NOT release heap-allocated (myType* ptr = new myType())
memory automatically.
Nobody said it did.