I've managed to get the Xcode leaks
tool to report leaks in my command-line GCC Ada program (by adding delay 11.0;
at the end to let leaks
make its checks) and then
$ export MallocStackLogging=1
$ (./foobar &) && leaks foobar
which leads to (excerpted)
Process 52027: 18 nodes malloced for 2053 KB
Process 52027: 2 leaks for 32 total leaked bytes.
Leak: 0x1002000c0 size=16 zone: DefaultMallocZone_0x100175000 string '*'
Call stack: [thread 0x7fff70bbcca0]: | start | main | _ada_foobar | __gnat_malloc | malloc | malloc_zone_malloc
Leak: 0x1002000d0 size=16 zone: DefaultMallocZone_0x100175000 string 'T'
Call stack: [thread 0x7fff70bbcca0]: | start | main | _ada_foobar | __gnat_malloc | malloc | malloc_zone_malloc
which is a great deal better than nothing, but would be considerably improved with line numbers.
Are there any build options I should have used? Would it work better if the Ada compiler (FSF GCC 4.6.0, not from Apple) was integrated with Xcode?
This is an x86_64 build on 10.6.7, Xcode 3.2.6. Using -g makes no difference.
In the call stack, main
is the main()
generated by gnatmake
, _ada_foobar
is the Ada program in which the leak actually occurs. The other frames are from the run time system.
Valgrind 3.7.0 is available for Mac OS X; my code test was
and I ran with
to get a report including
leaker.adb:14
is the call toInner
.Well, the chief issue here is exactly which compiler you have. The versions of Gnat you get from ACT come with a link libraray addr2line.lib that can be used to produce symbolic tracebacks at runtime.
The versions of Gnat you get from the FSF distributions don't have that library. However, there is still the addr2line program that comes with Gnu's "binutils". You do have that available for you on your Mac setup, right?
If you feed your hex addresses into that program, it should report the symbolic information you want. You may have to reformat your
leaks
output a bit for addr2line to accept it.