Hmm, some results using my App. In my app, the main form puts a TrayIcon in place and then hides itself. The Popup menu behind the TrayIcon allows user to open one of potentially many "notes" (based on KControls) or exit. In my tests below I either exit immediately or open one note, close it and then exit.
I did three runs of each to ensure results are consistent.
Unpatched, launch and exit - 23 unfreed memory blocks : 380
Patched, launch and exit - 20 unfreed memory blocks : 400
Patched, Launch, open note, close, exit - 23 unfreed memory blocks : 460
Now, the Popup Menu associated with the TrayIcon, on the Mac, does not update programmatically. See
https://bugs.freepascal.org/view.php?id=32516 so I call TrayIcon.InternalUpdate after changing the text I want displayed in that Popup Menu.
Without Calling TrayIcon.InternalUpdatePatched, Launch and exit - 16 unfreed memory blocks : 320
Patched, Launch, open note, close and exit - 19 unfreed memory blocks : 380
So, results without that call to TrayIcon.InternalUpdate are a little better but still not perfect. That leads me to assume these leaks are happening in lots of different places.
My code is quite large now, and I'm sure you don't want to look at it(
https://github.com/tomboy-notes/tomboy-ng). Perhaps I need to make a simple demo ?
Given your comment about Carbon being phased out -
A large part of the functions used in NSObjects.inc are already deprecated. Support for carbon is fading out so I'm skeptical about a bug fix.
Would I be better off, and your time be better used if I concentrated on using Cocoa instead ? Last time I tried Cocoa, it was pretty grim. Components crashed or failed to render and it looked terrible. I tried it yesterday using Lazarus 1.8 and was surprised how well it did work although there were certainly some issues.
Would you start a new project now based on Cocoa ?
David