All Projects FPC fpcprojects fpprofilerfpGUI Lazarus Packages PatchesLazarus CCR Mantis pas2js

View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0023647FPCFCLpublic2013-01-14 11:432013-01-21 14:17
Reportersilvioprog Assigned ToMarco van de Voort  
PrioritynormalSeverityminorReproducibilityhave not tried
Status closedResolutionfixed 
Product Version2.7.1 
Fixed in Version3.0.0 
Summary0023647: DaemonApp leak?
DescriptionHi,

Please just open and test the demo in attached. It will generate this output:

Heap dump by heaptrc unit
99 memory blocks allocated : 3531/3744
89 memory blocks freed : 3147/3352
10 unfreed memory blocks : 384
True heap size : 360448 (112 used in System startup)
True free heap : 359168
Should be : 359304
Call trace for block $0159EB68 size 16
  $0041ED4D
  $0041C8AA
  $0041C637
  $0041BC57
  $0041EE4B
  $0041AD9B
  $0042D894
  $004017F4 main, line 12 of project1.lpr
Call trace for block $015A5BB8 size 36
  $0041C637
  $0041BC57
  $0041EE4B
  $0041AD9B
  $0042D894
  $004017F4 main, line 12 of project1.lpr
  $0040E58F
Call trace for block $015BD860 size 56
  $0041BC57
  $0041EE4B
  $0041AD9B
  $0042D894
  $004017F4 main, line 12 of project1.lpr
  $0040E58F
Call trace for block $0159EB08 size 16
  $0040A418
  $0041BC48
  $0041EE4B
  $0041AD9B
  $0042D894
  $004017F4 main, line 12 of project1.lpr
  $0040E58F
Call trace for block $015DD800 size 80
  $0041EE4B
  $0041AD9B
  $0042D894
  $004017F4 main, line 12 of project1.lpr
  $0040E58F
Call trace for block $0159EAA8 size 16
  $0040A418
  $004239C3
  $0041BE96
  $004192BC TBROOKHTTPDAEMONMAPPER__CREATE, line 112 of daemon.pas
  $0041AD9B
  $0042D894
  $004017F4 main, line 12 of project1.lpr
  $0040E58F
Call trace for block $0159EA48 size 16
  $004233A3
  $004239C3
  $0041BE96
  $004192BC TBROOKHTTPDAEMONMAPPER__CREATE, line 112 of daemon.pas
  $0041AD9B
  $0042D894
  $004017F4 main, line 12 of project1.lpr
  $0040E58F
Call trace for block $0159E9E8 size 16
  $0041ED4D
  $0041BA28
  $0041BD82
  $0041BE86
  $004192BC TBROOKHTTPDAEMONMAPPER__CREATE, line 112 of daemon.pas
  $0041AD9B
  $0042D894
  $004017F4 main, line 12 of project1.lpr
Call trace for block $015A5B48 size 36
  $0041BD82
  $0041BE86
  $004192BC TBROOKHTTPDAEMONMAPPER__CREATE, line 112 of daemon.pas
  $0041AD9B
  $0042D894
  $004017F4 main, line 12 of project1.lpr
  $0040E58F
Call trace for block $015D57F8 size 96
  $0041AD9B
  $0042D894
  $004017F4 main, line 12 of project1.lpr
  $0040E58F

Thank you!
TagsNo tags attached.
Fixed in Revision23480
FPCOldBugId
FPCTarget
Attached Files

Activities

2013-01-14 11:43

 

daemon.zip (2,279 bytes)

silvioprog

2013-01-14 12:09

reporter   ~0064876

Last edited: 2013-01-14 12:10

 Full source code of BrookFCLHTTPDaemonBroker.pas:

https://github.com/silvioprog/brookframework/issues/11

Thank you!

Thaddy de Koning

2013-01-14 16:35

reporter   ~0064878

Last edited: 2013-01-14 16:38

 That seems to be in the call to DaemonDefs.Add in the constructor.
String allocations that keep at least a refcount of one and class allocations w/o free.
This is normally not a problem for a Daemon, because the memory will be free'd once the Daemon is uninstalled.

*edit*
Although not very elegant, I think this is by design.

silvioprog

2013-01-16 21:48

reporter   ~0064927

But its possible to solve it?

Thaddy de Koning

2013-01-17 06:22

reporter   ~0064933

Last edited: 2013-01-17 13:49

 Yes. f.e. add an interface to DaemonDefs and instantiate it through the interface. This will not break existing code and gets rid of the "leaks".

btw: nice work that brookframework! But plz provide clear links to dependency packages on the website.

Thaddy de Koning

2013-01-17 08:29

reporter   ~0064938

Last edited: 2013-01-17 13:51

 The problem is that you can not safely call the destructor on DaemonDefs, because this may give hard to predict results, so the design simply does not call it at all.. In this case adding the free call to a finalization section may lead to problems because the order in which the finalization sections are processed is by definition undefined.
A iinterface solves this. In its simplest form you only have to add IInterface, instantiate through the interface and hardcast back to the DaemonDefs class type. The marshalling ensures the destructor gets called at a convenient time.

I am not sure it is warranted to provide a patch (not everybody likes interfaces) but it is trivial and I am happy to do so if the maintainers of the code wish.

silvioprog

2013-01-17 15:24

reporter   ~0064953

> Yes. f.e. add an interface to DaemonDefs and instantiate it through the interface. This will not break existing code and gets rid of the "leaks".

Can you send me a sample code?

> btw: nice work that brookframework! But plz provide clear links to dependency packages on the website.

Thank you. :)
We can create a file "DEPENDENCIES.txt" with the text "All dependencies used in this project", and below all links of it.

silvioprog

2013-01-17 15:25

reporter   ~0064954

>I am not sure it is warranted to provide a patch (not everybody likes interfaces) but it is trivial and I am happy to do so if the maintainers of the code wish.

Feel totally free to implement it. :)

After done, send your patch to this issue:

https://github.com/silvioprog/brookframework/issues/11

Thank you!

silvioprog

2013-01-20 18:08

reporter   ~0065040

News? :)

2013-01-21 12:14

 

daemonapp.pp-20120121-0844.patch (380 bytes)    
Index: packages/fcl-extra/src/daemonapp.pp
===================================================================
--- packages/fcl-extra/src/daemonapp.pp	(revision 23467)
+++ packages/fcl-extra/src/daemonapp.pp	(working copy)
@@ -929,6 +929,7 @@
 begin
   if assigned(FEventLog) then
     FEventLog.Free;
+  inherited Destroy;
 end;
 
 procedure TCustomDaemonApplication.DoRun;
daemonapp.pp-20120121-0844.patch (380 bytes)   

silvioprog

2013-01-21 12:16

reporter   ~0065055

Guys, I solved the problem.

In attached the patch that eliminates the memory leak.

Thank you!

Marco van de Voort

2013-01-21 13:54

manager   ~0065057

Committed, thanks

silvioprog

2013-01-21 14:17

reporter   ~0065058

Working like a charm, thank you!

Issue History

Date Modified Username Field Change
2013-01-14 11:43 silvioprog New Issue
2013-01-14 11:43 silvioprog File Added: daemon.zip
2013-01-14 12:09 silvioprog Note Added: 0064876
2013-01-14 12:10 silvioprog Note Edited: 0064876
2013-01-14 16:35 Thaddy de Koning Note Added: 0064878
2013-01-14 16:38 Thaddy de Koning Note Edited: 0064878
2013-01-14 16:38 Thaddy de Koning Note Edited: 0064878
2013-01-16 21:48 silvioprog Note Added: 0064927
2013-01-17 06:22 Thaddy de Koning Note Added: 0064933
2013-01-17 08:29 Thaddy de Koning Note Added: 0064938
2013-01-17 08:34 Thaddy de Koning Note Edited: 0064938
2013-01-17 08:37 Thaddy de Koning Note Edited: 0064938
2013-01-17 08:38 Thaddy de Koning Note Edited: 0064938
2013-01-17 09:11 Thaddy de Koning Note Edited: 0064938
2013-01-17 09:19 Thaddy de Koning Note Edited: 0064938
2013-01-17 09:19 Thaddy de Koning Note Edited: 0064938
2013-01-17 09:35 Thaddy de Koning Note Edited: 0064933
2013-01-17 09:35 Thaddy de Koning Note Edited: 0064933
2013-01-17 13:49 Thaddy de Koning Note Edited: 0064938
2013-01-17 13:49 Thaddy de Koning Note Edited: 0064933
2013-01-17 13:51 Thaddy de Koning Note Edited: 0064938
2013-01-17 15:24 silvioprog Note Added: 0064953
2013-01-17 15:25 silvioprog Note Added: 0064954
2013-01-20 18:08 silvioprog Note Added: 0065040
2013-01-21 12:14 silvioprog File Added: daemonapp.pp-20120121-0844.patch
2013-01-21 12:16 silvioprog Note Added: 0065055
2013-01-21 13:54 Marco van de Voort Fixed in Revision => 23480
2013-01-21 13:54 Marco van de Voort Status new => resolved
2013-01-21 13:54 Marco van de Voort Fixed in Version => 2.7.1
2013-01-21 13:54 Marco van de Voort Resolution open => fixed
2013-01-21 13:54 Marco van de Voort Assigned To => Marco van de Voort
2013-01-21 13:54 Marco van de Voort Note Added: 0065057
2013-01-21 14:17 silvioprog Status resolved => closed
2013-01-21 14:17 silvioprog Note Added: 0065058