Memory leak only with IDE debugger

[Guest]

Hi everyone,

This simple code reports memory leak by enabling ReportMemoryLeaksOnShutdown or by using EurekaLog, and i saw it many times in the past and on different IDE's ( the following just tested with Delphi 2010 and Seattle)
To reproduce the leak do the following :
With new project use this code

type
  TStringClass = class
  private
    FString: string;
    function GetString: string;
  published
    property AString: string read GetString write FString;
  end;

{ TStringClass }

function TStringClass.GetString: string;
begin
  Result := FString;
end;

procedure TForm10.FormCreate(Sender: TObject);
var
  A: TStringClass;
begin
  A := TStringClass.Create;
  try
    A.AString := 'Hello';     //  <--- break point Here
  finally
    A.Free;                   //  <--- step here then hover the mouse on A.AString
  end;
end;

Enable ReportMemoryLeaksOnShutdown and put break point on that line, when debugger stops there move the mouse to make sure the tooltip with AString value is shown first it will be empty string ('') now press F8 and and move the mouse again to make sure the tooltip windows show the value as 'Hello', and that is it the leak happened!, and now FastMM will report a memory leak when application exits.

So what am i missing here? or is it a known bug mentioned somewhere? ,
and the more important question is : if the debugger can/might mess with application memory structure (or just auto referenced types ) what else does that ?
Debugger after all should not be altering the debugged application allocated memory without explicit user interaction.

Best regards

[David Heffernan 2345]

This is a known bug in the IDE / debugger. Nothing you can do about it. 

 

Evaluating certain expressions, often involving strings, seems to be what triggers it. 

[David Heffernan 2345]

1 hour ago, Kas Ob. said:

Debugger after all should not be altering the debugged application allocated memory without explicit user interaction.

That's not right. In order to evaluate expressions the debugger needs to execute code in the target process. Which may lead to allocations. 

 

It's a defect that the IDE / debugger leak such objects, but they can't do their job if they can't execute code and perform allocations in the target process. 

Edited September 24, 2019 by David Heffernan

[Guest]

13 hours ago, David Heffernan said:

This is a known bug in the IDE / debugger. Nothing you can do about it. 

Thank you David, known means not my wrong setup.

 

14 hours ago, David Heffernan said:

That's not right. In order to evaluate expressions the debugger needs to execute code in the target process. Which may lead to allocations. 

 

It's a defect that the IDE / debugger leak such objects, but they can't do their job if they can't execute code and perform allocations in the target process. 

You are right, for long time i used to believe that all Delphi compiled application has preallocated heap dedicated just for the debugger, on 32bit you can always see it at address $20000, the strange thing about this heap, it is not reported by GetProcessHeaps, and for what i know the Debugger always is injecting its code in that heap after making read/write/execute, for testing i just tried to enable DEP and attach the process, the debugger allocated different address, so no fixed heap !

 

[Guest]

There is a setting to allow "side effects" of debugging. If i am not mistaken (and i could be) that setting should stop evaluating stuff that allocates and such??

[Cristian Peța 103]

Was just bitten by this.

ClientDataSet.Edit;
ClientDataSet.FieldByName('Field').AsString := 'aa'; //exception "DataSet not in edit or insert mode" if debbuger is reading ClientDataSet.LogChanges property

P.S. State is changed to dsBrowse when reading ClientDataSet.LogChanges

Edited September 26, 2019 by Cristian Peța