Memory leak when using in/out variables

Remoting SDK
1

Delphi Tokyo.
Latest RO/DA.

Hello there,

Im finding a strange possible memory leak when using in/out parameters on the Client side.

Delphi Server.
Delphi Client.

I include a parameter called “User” which is a RO complextype with in/out parameters.

The parameter is passed as a already created object, server sees it, process it, returns, all good. If server is shutdown FASTMM4 doesnt return any memory leak. Good stuff.

Client receives message and destroys the class. Client is shut down and memory leak is reported of the same class just got destroyed.

I’m attaching the SessionTypes sample with some modifications to reproduce the issue.

Just open server, open client, login/logout, shutdown client. See the memory leak report on screen.

(Sent via support email)

2

Hi,
this is as designed: in case of var parameter RO SDK doesn’t destroy original parameter so you need to destroy it manually.
correct usage:

procedure TSessionTypes_ClientMainForm.LoginButtonClick(Sender: TObject);
var
 lUser, luser2 : TUser;
begin
  lUser := TUser.Create;
  try
   lUser.LoginName := cbUserId.Text;
   lUser.UserTypeId := 0;
   luser2 := luser;  // store reference to original object
   FLoginService.Login(cbUserID.Text, ePassword.Text,lUser);
  finally
   lUser.Free;
   luser2.Free;  //destroy it
  end;
end;
1 Like
3

In a normal situation luser2 dont becomes just a pointer to luser actual instance? Or im wrong?

Im confused. :scream:

1 Like
4

I agree.

Plus its a very akward non Remobjects way to do it. There must be some technical problem that force it to be implemented in such a way.

5

how to things work:

  • client side sends TUser to server
  • server-side processes it and can return nil, TUser or TUser descendant
  • client-side reads this server’s response, creates correspondent class and puts it into in/out parameter so it works like (very simplified case)
procedure method1(var x: TUser);
begin
  // send x to server
  x := TUser.Create;
  // read x from server's response
end;
  • as a result, old object isn’t released in above code and may cause memory leak if it isn’t released manually