Recompile the RTL to debug

[Cyrax]

I would suggest testing with FPC trunk compiler, too. Things related to lineinfo, heaptrace and debug info might be fixed there.

EDIT : https://bugs.freepascal.org/view.php?id=32775

It seems that there is no fix in there, yet.

[molly]

Thank you Cyrax, my rss feed-reader seems to have skipped a couple of numbers 

Bit strange though as there was a discussion somewhere in 2008 about debug support for Mac. Perhaps i misunderstood the thread or things have changed in the mean time.

In that case i would advice dbannon to (unfortunately) sit things out for the moment.

[dbannon]

OK -

Code: [Select]

/fpc-usr/3.0.4debug/lib/fpc/3.0.4/ppc386 -glh -gw -godwarfsets -O- -dDEBUG mollytest.pas
compiled OK and when run says -

Code: [Select]

Retrieving debug information failed
Heap dump by heaptrc unit
3 memory blocks allocated : 84/88
3 memory blocks freed     : 84/88
0 unfreed memory blocks : 0
True heap size : 360448 (16 used in System startup)
True free heap : 360432
Thats not very encouraging, is it ?

Nothing very interesting in the logs, its using the newly compiled units, its using the right fpc.cfg file.

Davo

[dbannon]

Advises Molly -

In that case i would advice dbannon to (unfortunately) sit things out for the moment.

Yep, looks that way. My underlying problem is a memory leak in TTrayIcon, an LCL component. Any suggestions as to another way to try and tackle this particular problem ?

https://bugs.freepascal.org/view.php?id=32678

I'll put a note on the wiki page about installing on a Mac warning people of both issues, might save someone else from spending the time on it that we have !

I guess the output from the test programme you posted today could be a useful addition to https://bugs.freepascal.org/view.php?id=32775

And putting all that aside, thanks heaps for your very professional help. I would have absolutely no chance of getting even to where we are now without your help.

David

[molly]

Any suggestions as to another way to try and tackle this particular problem ?

Sorry, no i don't know. Hopefully someone else is able to shed a light on that

And putting all that aside, thanks heaps for your very professional help. I would have absolutely no chance of getting even to where we are now without your help.

Thank you, but it wasn't really professional because in that case i would have fired up my mac (to make sure: which i haven't) and tested it myself. I also missed the bug-report that Cyrax mentioned 

As additional information. You can use readelf (provide options --debug-dump your-executable) to see if debug info was attached to your executable. There is also another tool that is able to do that for you named dwarfdump. Both tools should be available on your system (provided that you have mac SDK installed).

Thank you for your testings, reportings and patience 

[balazsszekely]

@dbannon
The source of the leak(or at least on of them) is in the attached picture. Procedure NSObject.AddMethod is called from carbontrayicon.inc AddMethods.

[dbannon]

@dbannon
The source of the leak(or at least on of them) is in the attached picture. Procedure NSObject.AddMethod is called from carbontrayicon.inc AddMethods.

Ah, GemMem (I assume its a coincidence, your user name and the offending function ?) - I have stepped through with gdb to that point and wondered about it. Unfortunately, gdb has problems with the next call ("cannot determine bounds of function), due, I guess to passing pointers to pointers to functions. So I was never able to get any further. Just confirmed thats still the case in 1.8.

So, you have managed to confirm thats the (or a) source of the leak ?  How did you do that if you don't mind me asking ?

David

[balazsszekely]

@dbannon

I assume its a coincidence, your user name and the offending function ?

Yes. It looks like a joke but is not. 

So, you have managed to confirm thats the (or a) source of the leak ?  How did you do that if you don't mind me asking ?

Just open carbontray.inc($LazarusDir/lcl/interfaces/carbon), search for "AddMethods" then uncomment the body of the procedure. Rebuild the IDE, rebuild your project then test again. By removing three call to NSObject.AddMethod three leaks are gone.   

[dbannon]

Yes. It looks like a joke but is not. 

No, no, its a great joke !

But more seriously, are you saying that you can comment out those lines AND TrayIcon is still sufficiently functional ?   

I've put my Mac away - sounds like I need to get it out again ....

Thanks, Davo

[balazsszekely]

But more seriously, are you saying that you can comment out those lines AND TrayIcon is still sufficiently functional ?   

No, of course not. By commenting out those lines, you only prove that the following line is responsible for the leak:

Code: Pascal  [Select][+][-]

1. method_list := GetMem(SizeOf(objc_method_list));

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. 

[balazsszekely]

@GetMem
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. 

Ok. I fixed the leaks related to object method list. Please do the following:
1. Go to folder $LazarusDir/lcl/interfaces/carbon/pascocoa/foundation/
2. Backup file NSObject.inc, then  extract NSObject.zip(attachment)
3. Rebuild IDE with "Clean All" option checked
4. Rebuild your application

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

[dbannon]

Wow, GetMem, just like that ?

I'm away without the Mac right now, might be  a day or so before I can try it out. I had been attempting to run my project under Cocoa following your comments. And yes, Cocoa works better than last time I tried but still has some way to go I suspect. And my project still leaks under Cocoa but nowhere near as much.

But you have fixed at least some of my carbon memory leaks, thanks !  Will you put it up against bug 32678 ?

Davo 

[balazsszekely]

@dbannon
Will you put it up against bug 32678 ?

What do you mean? That's exactly what I did in my previous post.

Bug description:
Blank Form, put a TTrayIcon on it, in the form's OnShow, call TTrayIcon.Show
In ProjectOptions, turn on Heaptrc
Compile and run from commandline.

Five unreleased memory, three are gone with the fix. Please test.

Additional Information:
Appears to be a real leak too, not just a one off of unreleased memory, grows as an App is used over time.

I let the application run for half an hour, I don't see any real leak. Are you sure it's caused by TTrayIcon. If yes how can I reproduce?

 

[dbannon]

>>Will you put it up against bug 32678 ?
What do you mean? That's exactly what I did in my previous post.

I meant will you post what you found on the bug tracker so the fix can appear in the trunk and ultimately, the next version of Lazarus.

Please test.

Hopefully later today.

I don't see any real leak. Are you sure it's caused by TTrayIcon. If yes how can I reproduce?

No, not sure at all. As heaptrc in Mac does not report where leaks come from, I don't know where ALL LEAKs come from. I knew TTrayIcon contributed by making a small test app that just called TTrayIcon. In my main app (quite big) I see leaks that gradually grow over time. My code has to refresh TrayIcon from time to time, it may be there. There are no leaks in Linux/Windows.

With any luck, I'll get a chance to do some testing later today.

David

[jamie]

TTrayIcon did have leak issues at one time.

 It has something to do with not freeing the icon.