如何检查 Guile 扩展模块中的内存泄漏？
我为 Guile 开发了一个扩展模块，用 C 语言编写。这个扩展模块嵌入了一个 Python 解释器。
由于此扩展模块调用 Python 解释器，因此我需要验证它是否正确管理 Python 对象占用的内存。
我发现 Python 解释器在其自身的内存处理方面表现良好，因此，如果没有其他干扰因素，通过运行 valgrind，我可以发现由于我自己的 Python 解释器嵌入代码中的错误而导致的内存泄漏。
然而，当我在 valgrind 下运行 Guile 时，valgrind 报告内存泄漏。 此类内存泄漏掩盖了由于我自己的代码而导致的任何内存泄漏。
问题是我能做些什么来将代码中的错误导致的内存泄漏与 valgrind 报告的 Guile 导致的内存泄漏分开。 另一种工具可以代替 valgrind 吗？ 特殊的 valgrind 选项？ 放弃并依赖手动代码演练？
I develop an extension module for Guile, written in C. This extension module embeds a Python interpreter.
Since this extension module invokes the Python interpreter, I need to verify that it properly manages the memory occupied by Python objects.
I found that the Python interpreter is well-behaved in its own memory handling, so that by running valgrind I can find memory leaks due to bugs in my own Python interpreter embedding code, if there are no other interfering factors.
However, when I run Guile under valgrind, valgrind reports memory leaks. Such memory leaks obscure any memory leaks due to my own code.
The question is what can I do to separate memory leaks due to bugs in my code from memory leaks reported by valgrind as due to Guile. Another tool instead of valgrind? Special valgrind options? Give up and rely upon manual code walkthrough?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
你有几个选择。 一种是为 valgrind 编写一个抑制文件，关闭对您未处理的内容的报告。 Python有这样一个文件，例如：
http://svn.python.org/projects/python/trunk /Misc/valgrind-python.supp
如果 valgrind 不喜欢您的设置，另一种可能性是使用
libmudflap； 您使用gcc -fmudflap -lmudflap编译程序，生成的代码将用于指针调试。 在 gcc 文档和此处进行了描述：http://gcc.gnu.org/wiki/Mudflap_Pointer_DebuggingYou've got a couple options. One is to write a supressions file for valgrind that turns off reporting of stuff that you're not working on. Python has such a file, for example:
http://svn.python.org/projects/python/trunk/Misc/valgrind-python.supp
If valgrind doesn't like your setup, another possibility is using
libmudflap; you compile your program withgcc -fmudflap -lmudflap, and the resulting code is instrumented for pointer debugging. Described in the gcc docs, and here: http://gcc.gnu.org/wiki/Mudflap_Pointer_Debugging