Memory leak using Delphi

Question

I have this procedure:

procedure TMainForm.ExtractActor(const actor_id : string);
var
  mystream : TStringStream;
  js : TlkJSONobject;
begin
    mystream:= TStringStream.Create('');
    idHTTP1.Get(TIdURI.URLEncode('some dynamic url'),mystream);                                               
    js := TlkJSON.ParseText( mystream.DataString ) as TlkJsonObject;
    //insert
    if UniConnection1.Connected then
    begin
      UniQuery3.Params[0].Value:= StrToInt(js.getString('id'));
      UniQuery3.Open;
      if (UniQuery3.RecordCount = 0) then
      begin
        Uniquery2.Params[0].Value:= StrToInt(js.getString('id'));
        Uniquery2.Params[1].Text:= js.getString('name');
        Uniquery2.Params[2].Text:= js.getString('locale');
        Uniquery2.Params[3].Text:= js.getString('gender');
        Uniquery2.Params[4].Text:= js.getString('username');
        Uniquery2.Execute;
      end;
      UniQuery3.Close;
    end;
    mystream.Free;
end;

Monitoring Windows Task Manager I see that the process memory keeps increasing. After a day or so I will get an Out of Memory error and the application will crash. What am I doing wrong? I'm assuming that neither the JSON or the Devart UniDAC libraries are leaking.

David Heffernan · Accepted Answer · 2014-01-20T10:36:51.343

There are a couple of obvious causes for a leak.

The one that is surely a leak is the js object that you create but fail to destroy. Protect its lifetime with a try/finally block:

js := TlkJSON.ParseText( mystream.DataString ) as TlkJsonObject;
try
  ...
finally
  js.Free;
end;

More subtle is the un-protected mystream. If an exception is raised after mystream is assigned, and before it is destroyed, you will leak that object. Again you should protect that with a try/finally block using the exact same idiom as demonstrated above. The problem with mystream will only be an issue for you in case your function is raising exceptions. Whilst that might not be the case here you must always protect objects in the manner shown above.

In any event, you should certainly do some leak tracking in your program. There may very well be more leaks. Here are the first steps you need to take:

Change your code so that it uses the full version of FastMM.
Set up the FastMM configuration file for full debug. That may involve editing the .inc file and if you find that too daunting, you can use the GUI utility from here: http://jed-software.com/blog/?p=606
Run your program for a little while and then close it. If you have leaks these should be reported at this point.
Fix all your leaks.

It is possible that you have leaks during the running of your program, but that are all tidied up when the program closes. These are harder to track and require some extra instrumentation of your program.

Thanks. But if an exception happened without the try block, it would crash the application and it would be visible. It runs ok for a day at least. In the end it will stop and I'll get and "Out of memory" message box after closing it. — Miguel E, Jan 20 '14 at 10:38
@MiguelE Read the part about `js`. Also, please don't just fix that and then forget all about leaks. Add FastMM full debug and fix them all. Leaks are like Pokemon. — David Heffernan, Jan 20 '14 at 10:42
@MiguelE "_But if an exception happened without the try block, it would crash the application and it would be visible._" ... Unless you've done something to specifically cause the application to crash, that's not true. With default exception handling, the current operation will be stopped and the user will see an error message; the app will continue running. In fact, the user won't even see an error message if the exception **is** of the `EAbort` class. — Disillusioned, Jan 21 '14 at 16:14
@MiguelE Also, you don't want to waste your time in code outside this method worrying about whether it's compatible with the fact that this method doesn't implement proper resource protection. Just do it - there's no good reason not to! — Disillusioned, Jan 21 '14 at 16:15

Memory leak using Delphi

1 Answers1