如何在 Mac OS X 上获取内存泄漏的行编号堆栈跟踪?
我已经设法让 Xcode leaks
工具报告我的命令行 GCC Ada 程序中的泄漏(通过在末尾添加 delay 11.0;
让 leaks
进行检查),然后
$ export MallocStackLogging=1
$ (./foobar &) && leaks foobar
导致(摘录),
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
这比没有好得多,但行数会大大改善。
有没有我应该使用的构建选项?如果 Ada 编译器(FSF GCC 4.6.0,不是来自 Apple)与 Xcode 集成,效果会更好吗?
这是基于 10.6.7、Xcode 3.2.6 的 x86_64 构建。使用 -g 没有什么区别。
调用栈中,main
是gnatmake
生成的main()
,_ada_foobar
是Ada程序,其中泄漏确实发生了。其他帧来自运行时系统。
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.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
好吧,这里的主要问题正是您拥有哪个编译器。您从 ACT 获得的 Gnat 版本带有一个链接库 addr2line.lib,可用于在运行时生成符号回溯。
您从 FSF 发行版获得的 Gnat 版本没有该库。不过,仍然有 Gnu 的“binutils”附带的 addr2line 程序。您的 Mac 设置中确实可以使用该功能,对吧?
如果您将十六进制地址输入该程序,它应该报告您想要的符号信息。您可能需要稍微重新格式化您的
leaks
输出,以便 addr2line 接受它。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.Valgrind 3.7.0 适用于 Mac OS X;我的代码测试是
,我运行以
获得一份报告,其中包括
leaker.adb:14
是对Inner
的调用。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
.虽然不如
valgrind
具有决定性,如此处所示,但可以Spawn
没有延迟
的leaks
实例,如下所示。Spawn
块,允许leaks
在继续之前结束。在最好的情况下,这是验证没有发现泄漏的快速方法;如果没有,配对调用可以缩小对违规代码的搜索范围。代码:
控制台:
Although less dispositive than
valgrind
, illustrated here, it's possible toSpawn
an instance ofleaks
withoutdelay
as shown below.Spawn
blocks, allowingleaks
to conclude before proceeding. In the best case, it's a quick way to verify that no leaks were found; if not, paired calls can narrow the search for offending code.Code:
Console: