Recompile the RTL to debug

[dbannon]

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.InternalUpdate

Patched, 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

[balazsszekely]

@dbannon
I did take a quick look, your projects leaks under windows too. Please fix the leaks related to your project first, then we can go back to carbon/cocoa components. There are several exceptions too(see attached images).

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.

Cocoa is still under development, but I agree is getting better and better fast. QT also works well under OSX. You can try it with fpcupdeluxe. It won't interfere with your current installation.

[dbannon]

I did take a quick look, your projects leaks under windows too.

Thats disappointing. I have not tested for leaks under windows for a while, assuming Linux tests would be enough. Very disappointing but thanks for pointing it out ! There were some substantial changes made a little while ago, bet they are in there. Sigh.

Conversely, I made a simple test rig to test just TTrayIcon on a Mac. And using your patched file found no leaks in TTrayIcon. So, it sounds like thats a very good thing.  Maybe I'll be lucky and the current leaks you found, which will be easy to find on a Windows box, might be reflected on the Mac ?

Mind telling me what you did to trigger that exception ?  I'm assuming its going to relate to the app firing up and finding no notes present. But I have tested against that but maybe only on Linux....

David
David 

[dbannon]

Actually, GetMem, is it correct to say you ran into those exceptions in the debugger ?  The debugger reports exceptions that are later handled and thats not an error condition.

Running native, or not with the debugger in place and you would not be aware of those exceptions.

David

[dbannon]

@GetMem, I would really appreciate it if you could tell me what steps you took to trigger off those memory leaks you mention in my app.

Are you using the head version of the source ?

It appears to me, from your screen shots, that you started it up, declined to make a directory for the notes and then looked for backup copies of the notes ?

I have repeatedly played around that area but have been unable to see either the exception or the leaks. I wonder if you saw the exception in the IDE, was shown it by the debugger and choose to "abort" rather than "continue" thus denying the exception handler I have in there the chance to clean up ? That would cause a one off memory leak....

Trouble with that theory, I cannot trigger off the exception either !

Davo

[balazsszekely]

@GetMem, I would really appreciate it if you could tell me what steps you took to trigger off those memory leaks you mention in my app.

I honestly do not remember the exact steps. I just navigated randomly in your application.

Are you using the head version of the source ?

Yes.

It appears to me, from your screen shots, that you started it up, declined to make a directory for the notes and then looked for backup copies of the notes ?

Yes that's possible.

I have repeatedly played around that area but have been unable to see either the exception or the leaks. I wonder if you saw the exception in the IDE, was shown it by the debugger and choose to "abort" rather than "continue" thus denying the exception handler I have in there the chance to clean up ? That would cause a one off memory leak....
Trouble with that theory, I cannot trigger off the exception either !

I will redo the tests(this time more carefully), but only next week.

[dbannon]

I will redo the tests(this time more carefully), but only next week.

Of Course, a lot of us will find the next week a busy one !

David

[dbannon]

@GetMem, I am sorry, I have mislead you. The patch you provided for TTrayIcon has not in fact fixed all the memory leaks.

.... I made a simple test rig to test just TTrayIcon on a Mac. And using your patched file found no leaks in TTrayIcon. ........

Wrong, I had unintentionally switched to Cocoa, we know it does not leak in Cocoa !  But it does most certainly still leak under Carbon. It Leaks when initially started and then it leaks every time we call TrayIcon1.InternalUpdate; and we need call that to update the menu entries.  About 20 bytes each time.

My impression is that its now leaking less overall than it did.

Davo

[balazsszekely]

@GetMem, I am sorry, I have mislead you. The patch you provided for TTrayIcon has not in fact fixed all the memory leaks.

You did not mislead me. I'm gonna quote myself:

With this bug fix three from the five leaks are gone. You still need to find the remaining two.

The remaining leaks most likely are in NSObjects.inc. I was hoping that you or somebody else will find it. Currently I'm busy with other IDE related stuff, more over carbon has no future at all, in my opinion it's not worth the effort. Of course this should not discourage you. You still can develop with carbon, but not for long.

[dbannon]

You still can develop with carbon, but not for long.

Yep, understand. My app looks like a lot of it runs under cocoa and even looks good. But I have an issue with the main application form refusing to hide as the app starts up. I think I'll concentrate on that and move, kicking and screaming into the 21st century ....

[dbannon]

Just for the benefit of people watching this thread, its morphed into one about the memory leaks under OSX.

My conclusion is that for my App and a carefully repeated test sequence, no memory leaks under Linux and Windows. Leaks under both Cocoa and Carbon, significantly worse with Cocoa. Under, Cocoa, to a dangerous degree. Its possible some of those leaks are in my code but I suspect most, if not all are in LCL or RTL.

My guess is that it will remain like that until HeapTRC reports line numbers.
https://bugs.freepascal.org/view.php?id=32775

Many thanks to the many people who have assisted with this thread !

David