Delphi REST mac memory leak

Question

I am currently looking for a way around an apparent memory leak in the Mac implementation of the REST client. The code to generate the memory leak is the following (running XE8, update 1):

program mac_REST_leak_test;
{$APPTYPE CONSOLE}
{$R *.res}

uses
  System.SysUtils, REST.Client, REST.Types, IPPeerClient;

var
   request : TRestRequest;
   ii, iMax : integer;
begin
   iMax := 1; 
   for ii := 0 to iMax do
   begin
      request := TRestRequest.Create(nil);
      // Fake Online REST API for Testing and Prototyping 
      request.Client := TRestClient.Create('http://jsonplaceholder.typicode.com/');
      request.Method := rmPOST;
      request.Execute();

      request.Client.Free();
      request.Free();
   end;
end.

This is the smallest block of code that demonstrates the leak. Essentially, I have a synching service that makes REST requests every so often.

When I run this on Windows, using MadExcept, no leaks are found. Examining the running process in ProcessMonitor shows no increase in the amount of memory being used.

When run on a Mac, however, the Activity Monitor shows the memory allocated to the app continue to rise. Further, when run using Instruments, there appear to be leaks dealing with several URL and HTTP classes on mac.

Does anybody know how to resolve this leak?

(As an aside, it would be really helpful to know exactly where the leak is coming from on Mac, but the only Delphi classes listed are the TMethodImplementationIntercept. I'm to believe that this is due to the fact that Delphi doesn't generate a dSYM file for Mac. If anybody knows a way around that, that would be awesome too!)

UPDATE By varying iMax from 1 to 10 and comparing the FastMM4 output, it appears that the leak is in the class Macapi.ObjectiveC.TConvObjID.XForm. The 10 iteration output contains 9 more leaks with this as a stack trace compared to the 1 iteration. I have reported this to Embarcadero as RSP-12242.

Answer 1

Yes FastMM4 has OSX leak reporting support in latest SVN revision. Unfortunatly, the "global" leaks from a simple empty Delphi FMX application makes it difficult to analyse the mem-logfile. A few leaks has been fixed in XE10 but some objects in MacApi.ObjectiveC bridge still generate leaks. I have reported that in Quality Central & Quality Portal (QC & QP). So it's difficult to use FastMM4 for leak finding.

Please separate Delphi object leaks and ObjectiveC leaks, second you can find with instruments.