Downloads  |  Buy

Memory leak in Delphi unit v4.1.9.0

Memory leak in Delphi unit v4.1.9.0

Postby jonjon » October 18th, 2019, 8:52 am

Hi,
It looks like there are multiple memory leaks in TA's Delphi units in v4.1.9.0: memory is allocated using StrAlloc() before various method calls, but StrDispose() is only called afterwards if the method returned an error. It should be called no matter what happened, preferably in a try / finally block.
Thank you.
jonjon
 

Re: Memory leak in Delphi unit v4.1.9.0

Postby Wyatt » October 18th, 2019, 9:19 am

It returns the string to you. We don't dispose what you'll be using.
User avatar
Wyatt
Site Admin
 
Posts: 6384
Joined: July 11th, 2007, 10:30 pm
Location: New Hampshire

Re: Memory leak in Delphi unit v4.1.9.0

Postby jonjon » October 18th, 2019, 9:29 am

Well, I believe that you are wrong because you are assigning the newly allocated string to the result so it needs to be freed first. Delphi compiler magic already handles the "Result" variable string so you'll need to take care of the extraData that you manually allocated first.
See the following methods for example, your code is basically ReturnString_WITH_LEAK when it should be ReturnString_OK:

function ReturnString_OK: string;
var
extraData : PWideChar;
begin
extraData := StrAlloc(10);
try
Result := extraData;
finally
StrDispose(extraData);
end;
end;

function ReturnString_WITH_LEAK: string;
var
extraData : PWideChar;
begin
extraData := StrAlloc(10);
Result := extraData;
if (False) then StrDispose(extraData);
end;
jonjon
 

Re: Memory leak in Delphi unit v4.1.9.0

Postby jonjon » October 25th, 2019, 3:15 am

Could you please confirm this ?
Thank you.
jonjon
 

Re: Memory leak in Delphi unit v4.1.9.0

Postby Wyatt » October 25th, 2019, 5:11 am

We’re looking into it
User avatar
Wyatt
Site Admin
 
Posts: 6384
Joined: July 11th, 2007, 10:30 pm
Location: New Hampshire

Re: Memory leak in Delphi unit v4.1.9.0

Postby pauven » November 13th, 2019, 1:59 pm

I agree with Wyatt. When a Function has to allocate or create the Result, what is created is passed to the calling Procedure. It is always the responsibility of the calling Procedure to free what is returned by the Function.

If you free the Result before the Function ends, then that causes an Allocation Exception error, plus the Result value never gets passed to the calling Procedure. So your example Function "ReturnString_OK" would not work as you expect.

Instead:

procedure TestRoutine();
var str: string;

begin
str := ReturnString_WITH_LEAK;
try
if str = 'Hello World!' then
IAmGoingToDisneyWorld(True);
finally
StrDispose(str);
end;
end;
pauven
 
Posts: 4
Joined: November 3rd, 2018, 11:25 am

Re: Memory leak in Delphi unit v4.1.9.0

Postby jonjon » February 17th, 2020, 10:34 am

Hi,

This doesn't make any sense, particularly in the
function TurboActivate.GetFeatureValue because the calling code cannot know if it receives the default value (which must not be freed), or the proper value (which must be freed).

See my previous code for a proper way to properly handle all cases and fix this long standing issue.

Thank you.
jonjon
 

Re: Memory leak in Delphi unit v4.1.9.0

Postby jonjon » February 20th, 2020, 3:54 am

Any comments ?
This is problematic as we have a memory leak due to this behavior.
Thanks.
jonjon
 

Re: Memory leak in Delphi unit v4.1.9.0

Postby Wyatt » February 20th, 2020, 7:39 am

This is on our radar, but it's lower priority right now. What you're saying makes sense (if you have to sometimes free the value, and it's ambiguous *when*, then that's not great behavior).

A workaround in the meantime is to not use the default value and instead catch the exception when the custom license field is not present. Then either handle that exception or free the value (after you do something with it, of course).
User avatar
Wyatt
Site Admin
 
Posts: 6384
Joined: July 11th, 2007, 10:30 pm
Location: New Hampshire


Return to LimeLM, TurboActivate, & TurboFloat Support