Hello,

Is anyone using a profiler in Mac OS X? I am trying to detect if there are memory leaks.

gprof doesn't seam to work and valgrind doesn't seams usable from their readme, so I tryed "Sampler" from the Developers dir, but the application runs and after it nothing appears in the tables.

thanks,

You should use Instruments from the Developper tools. /Developper/Applications/Instruments

Milipili wrote

You should use Instruments from the Developper tools. /Developper/Applications/Instruments

In my 10.4 there isn't this directory.

Ah, but I found ObjectAlloc, which seams to work, thanks a lot =)

Felipe Monteiro de Carvalho wrote

Is anyone using a profiler in Mac OS X? I am trying to detect if there are memory leaks.

Profilers don't detect memory leaks. Profilers detect which code is executed (a lot) by the program.

gprof doesn't seam to work

gprof cannot detect memory leaks. gprof is also not supported on Mac OS X/i386 (it does work on PowerPC, PowerPC64 and x86_64 though; it's hard on i386 for implementation reasons). The next release of FPC will properly given an error if you try to enable grpof profiling information (-gp) on a platform that does not support it, instead of silently do nothing.

and valgrind doesn't seams usable from their readme,

The latest release of Valgrind works on Mac OS X/i386, but only under 10.5 (because due to its nature, it has to be completely syscall-based).

so I tryed "Sampler" from the Developers dir, but the application runs and after it nothing appears in the tables.

Sampler can only display how the call stack varies during the run time of the application.

As you discovered, ObjectAlloc is a tool you can use to detect memory leaks.

A good way to find out development related things about Mac OS X is googling with site:developer.apple.com, e.g. http://www.google.com/search?q=site%3Adeveloper.apple.com+memory+leaks

The first result is http://developer.apple.com/mac/library/documentation/Performance/Conceptual/ManagingMemory/Articles/FindingLeaks.html . Not all of it may be applicable to 10.4, but a lot of it still is.

Jonas

Available since 10.5 if I remember well.

http://developer.apple.com/mac/library/documentation/DeveloperTools/Conceptual/InstrumentsUserGuide/Introduction/Introduction.html

Felipe Monteiro de Carvalho het geskryf:

Is anyone using a profiler in Mac OS X? I am trying to detect if there are memory leaks.

As Jonas mentioned, profilers do not detect memory leaks, but rather the performance (speed) of your code.

What is wrong with enabling the heaptrc unit (-gh)? That works for me under Linux and Windows. When the application quits, it dumps to the console the memory leak status and a backtrace of more or less where they got introduced. The latter is rather a 'hit and miss' situation, so to make my live easier I start developing a project from scratch with HeapTrc enabled - so I can detect memory leaks as soon as I introduced them - which also make them easier to find and fix.

Regards,
- Graeme -

Graeme Geldenhuys wrote

What is wrong with enabling the heaptrc unit (-gh)?

It works only for memory allocated by the fpc heap manager, so a winapi CreateWindow call, or a gtk gtk_button_new call would create an undetected memory leak, if the returned handle/pointer is not release properly.

Vincent

Graeme Geldenhuys wrote

What is wrong with enabling the heaptrc unit (-gh)?

It does not detect memory leaks stemming from memory not allocated via FPC code. A lot of Mac OS X framework routines return pointers that you have to retain/release in a balanced way.

Jonas

Graeme Geldenhuys wrote

When the application quits, it dumps to the console the memory leak status and a backtrace of more or less where they got introduced. The latter is rather a 'hit and miss' situation

What do you mean?

Jonas

Why not just use unit heaptrc?

<http://www.freepascal.org/docs-html/rtl/heaptrc/>

Quoted from that page:

The HEAPTRC unit can be used to debug your memory
allocation/deallocation. It keeps track of the calls to getmem/freemem, and, implicitly, of New/Dispose statements.

When the program exits, or when you request it explicitly. It displays the total memory used, and then dumps a list of blocks that were allocated but not freed. It also displays where the memory was allocated.

If there are any inconsistencies, such as memory blocks being allocated or freed twice, or a memory block that is released but with wrong size, this will be displayed also.

The information that is stored/displayed can be customized using some constants.

Works very well.

Tom

Jonas Maebe het geskryf:

What do you mean?

You sometimes get loads of output highlighting several memory leaks. The backtrace information doesn't always lead tot he exact location where the memory leak was caused. That's the "hit and miss" I mentioned. Sometimes the backtrace is correct and sometimes it is not. Also sometimes you fix one memory leak and suddenly our heaptrc output report that half the memory leaks are fixed.

Anyway, as I said, I enable heaptrc for all my coding projects so that I detect memory leaks as soon as they are introduced. This greatly reduces my time in find them, because I know what code I was working on. Obviously at app deployment, I disable heaptrc.

Regards,
- Graeme -

Vincent Snijders het geskryf:

It works only for memory allocated by the fpc heap manager, so a winapi CreateWindow call, or a gtk gtk_button_new call would create

Ah OK, I see what you mean. So does profilers like valgrind detect those?

Regards,
- Graeme -

Jonas Maebe wrote

It does not detect memory leaks stemming from memory not allocated via FPC code. A lot of Mac OS X framework routines return pointers that you have to retain/release in a balanced way.

Yes, my memory leak was not about allocated blocks but rather about correctly calling release for NSMenu, NSMenuItem and other Cocoa objects.