Session memory leaks problem

[vg0005]

Dear IW developers:

 

First of all, thank you for your creative work and tireless efforts.

 

However, I have found a memory-leakage problem which occurs each time when IW destroys a session. Even if it is a web page with only one button or no user codes at all (including all of your demos), when a session is destroyed, it only releases 1/10 of the memory it has consumed(15.1.3 is a little better but still far from satisfactory). For instance, it consumes approximately 1mb memory when a session starts and it spits back only 0.1mb memory when the session is killed.

 

Please use any one of your demos and evaluate the memory ‘black holes’. I usually set the sessiontimeout time to 1 minute to quicken the process but 10 minutes made no difference. I sincerely hope you could fix up the memory problem ASAP.

 

Thank you for your atention.

Ps: I used one of your demos named ‘Guess’. The pic below shows what I had in my TASKMANAGER:

---

Sorry I forgot to tell you the pic shows what I experienced with one of your IW demos called 'Guess'. You created this demo so I didn't post it as an attachment.

[SorenJensen]

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

[Alexandre Machado]

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.

[SorenJensen]

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.