Memory leak in Delphi unit v4.1.9.0

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.

It returns the string to you. We don't dispose what you'll be using.

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;

Could you please confirm this ?Thank you.

Were looking into it

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;

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.

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

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).

Reply
Discard post