How to get a line-numbered stack trace for a memor

问题:

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.

回答1:

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.

回答2:

Valgrind 3.7.0 is available for Mac OS X; my code test was

with Ada.Text_IO; use Ada.Text_IO;
procedure Leaker is
   type P is access Integer;
   procedure Inner is
      V : P;
   begin
      Put_Line ("allocating for 42");
      V := new Integer'(42);
      Put_Line ("allocating for 0");
      V := new Integer'(0);
      Put_Line ("done.");
   end Inner;
begin
   Inner;
end Leaker;

and I ran with

valgrind --leak-check=full --dsymutil=yes ./leaker

to get a report including

8 bytes in 2 blocks are definitely lost in loss record 2 of 9
   at 0xB823: malloc (vg_replace_malloc.c:266)
   by 0x100010CC7: __gnat_malloc (s-memory.adb:92)
   by 0x100001C7D: _ada_leaker (leaker.adb:14)
   by 0x100001BAA: main (b~leaker.adb:191)

leaker.adb:14 is the call to Inner.