Posts: 185
Threads: 55
Joined: Jul 2019
Reputation:
2
Location: Luxembourg
Hi VG0005,
I will not claim to know anything about any memory leak in IW but in a test I have created, where one form creates, show and destroy another form, where the purpose was to find out the order in which events appears, I have noticed a problem regarding destroying the main form.
In the simple application I add a line to the logfile, for every procedure or function called, and the general order is that I start the application, push a button on main form to create and show form2. On form2 I push a button to release form2 and return to form1. On form1 I then push a second button to terminate the application.
The logfile look like this:
11-08-2019 17:31:09
11-08-2019 17:31:09 UserSession.Create : 1
11-08-2019 17:31:09
11-08-2019 17:31:09 Unit1.FormCreate : 2
11-08-2019 17:31:09
11-08-2019 17:31:09 Unit1.FormShow : 3
11-08-2019 17:31:10
11-08-2019 17:31:10 Unit1.Button1.OnAsyncClick.BeforeCall : 4
11-08-2019 17:31:10
11-08-2019 17:31:10 Unit2.FormCreate : 5
11-08-2019 17:31:10
11-08-2019 17:31:10 Unit2.FormShow : 6
11-08-2019 17:31:10
11-08-2019 17:31:10 Unit1.Button1.OnAsyncClick.AfterCall : 7
11-08-2019 17:31:12
11-08-2019 17:31:12 Unit2.Button1.OnAsyncClick.BeforeCall : 8
11-08-2019 17:31:12
11-08-2019 17:31:12 Unit1.FormShow : 9
11-08-2019 17:31:12
11-08-2019 17:31:12 Unit2.Button1.OnAsyncClick.AfterCall : 10
11-08-2019 17:31:12
11-08-2019 17:31:12 Unit2.FormDestroy : 11
11-08-2019 17:31:13
11-08-2019 17:31:13 Unit1.Button2.Application.Terminate : 12
11-08-2019 17:31:13
11-08-2019 17:31:13 UserSession.Destroy : 13
Notice that "Unit1.FormDestroy" is missing. I appears as if formdestroy is not called for the main form, when terminating the application.
But the thing is, MainForm.Destroy IS called, but ONLY the first line of the procedure is executed. I made a number of tests confirming the behavior: second and subsequent lines are not processed.
Whether or not this leads to memory leaks I cannot say, but it do mean that whatever application activity you have put in (main)form.Destroy, only the first line of code is executed.
Regards
Soren
NB! If anybody wants the test application, please let me know and I'll add it as a zip file. It's build with IW 15.1.3 and Delphi 10.3.2 Rio
Posts: 2,261
Threads: 196
Joined: Mar 2018
Reputation:
86
Location: Auckland, New Zealand
Hi Soren,
I'm not sure how you are logging this data and how you are dealing with creation/destruction of your forms, but I don't think there is any memory leak, unless there is something unusual going on.
Any IW application destroys all owned forms and this has been extensively tested in all scenarios.
If you create an OnDestroy event for your forms and put a breakpoint on them I'm certain that you will see that they are being destroyed.
If you are somehow unable to recreate it, please send me your test application source code (with no external/3rd party dependencies) and I'll check what is happening.
BTW, Task manager is a terrible way to check memory consumption of your application.
FastMM4, the built-in memory manager used by all Delphi applications by default, won't return any allocated memory to the OS (in case of medium and small allocation blocks - which are usually almost all memory allocated by your application), unless the OS requests it.
From FastMM4 readme.txt:
"In an object oriented programming language like Delphi, most memory allocations and frees are usually for small objects. In practical tests with various Delphi applications it was found that, on average, over 99% of all memory operations involve blocks"
Meaning that FastMM 4, in practice, never returns any allocated memory to the OS, because it is *expensive*. Once allocated it is much better to keep it in its own pool and use it again. Again, the OS can still reclaim this memory back, and FastMM will return it back.
Usually, the allocated memory grows linearly up to a certain point and then gets stable. This "point" varies from application to application but can be easily seen in a stress test.
Posts: 185
Threads: 55
Joined: Jul 2019
Reputation:
2
Location: Luxembourg
Alexandre, sorry for the confusion my post caused. It had nothing to do with memory leaks, and after reading what you wrote, I realized I never tried debugging beyond that point. I turns out the second line in the procedure was a LogFileAppend command, and that caused an Access Violation. But because it was in the FormDestroy of mainform, I never noticed.