【问题标题】:Possible Memory Leak Valgrind in OSX El CapitanOSX El Capitan 中可能的内存泄漏 Valgrind
【发布时间】:2016-04-06 23:55:07
【问题描述】:

在 OSX Yosemite 上使用 Valgrind 时,我收到了 possibly lost: 2,064 bytes in 1 blocks 的警告。有解决办法吗?我使用 brew 安装了 valgrind。

以下是如何重现的示例

~/cat hello.c
int main() {
    return 123;
}

~/uname -a
Darwin mac.local 15.2.0 Darwin Kernel Version 15.2.0: Fri Nov 13 19:56:56 PST 2015; root:xnu-3248.20.55~2/RELEASE_X86_64 x86_64 i386 MacBookAir6,2 Darwin

~/clang --version
Apple LLVM version 7.0.2 (clang-700.1.81)
Target: x86_64-apple-darwin15.2.0
Thread model: posix

~/valgrind --version
  valgrind-3.11.0

~/brew info valgrind
valgrind: stable 3.11.0 (bottled), HEAD
Dynamic analysis tools (memory, debug, profiling)
http://www.valgrind.org/
/usr/local/Cellar/valgrind/3.11.0 (328 files, 46.7M) *
  Poured from bottle
From: https://github.com/Homebrew/homebrew/blob/master/Library/Formula/valgrind.rb

~/clang hello.c -o hello.o

~/valgrind --leak-check=full ./hello.o
==7972== Memcheck, a memory error detector
==7972== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==7972== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==7972== Command: ./hello.o
==7972== 
==7972== 
==7972== HEAP SUMMARY:
==7972==     in use at exit: 22,411 bytes in 187 blocks
==7972==   total heap usage: 271 allocs, 84 frees, 28,651 bytes allocated
==7972== 
==7972== 2,064 bytes in 1 blocks are possibly lost in loss record 57 of 62
==7972==    at 0x10000817C: malloc_zone_malloc (in /usr/local/Cellar/valgrind/3.11.0/lib/valgrind/vgpreload_memcheck-amd64-darwin.so)
==7972==    by 0x1004F3EFD: _objc_copyClassNamesForImage (in /usr/lib/libobjc.A.dylib)
==7972==    by 0x1004E7182: protocols() (in /usr/lib/libobjc.A.dylib)
==7972==    by 0x1004E7093: readClass(objc_class*, bool, bool) (in /usr/lib/libobjc.A.dylib)
==7972==    by 0x1004E4C13: gc_init (in /usr/lib/libobjc.A.dylib)
==7972==    by 0x1004EC24E: objc_initializeClassPair_internal(objc_class*, char const*, objc_class*, objc_class*) (in /usr/lib/libobjc.A.dylib)
==7972==    by 0x1004F9132: layout_string_create (in /usr/lib/libobjc.A.dylib)
==7972==    by 0x1004E783C: realizeClass(objc_class*) (in /usr/lib/libobjc.A.dylib)
==7972==    by 0x1004E7300: copySwiftV1MangledName(char const*, bool) (in /usr/lib/libobjc.A.dylib)
==7972==    by 0x1004E72E9: copySwiftV1MangledName(char const*, bool) (in /usr/lib/libobjc.A.dylib)
==7972==    by 0x1004E72E9: copySwiftV1MangledName(char const*, bool) (in /usr/lib/libobjc.A.dylib)
==7972==    by 0x1004E72E9: copySwiftV1MangledName(char const*, bool) (in /usr/lib/libobjc.A.dylib)
==7972== 
==7972== LEAK SUMMARY:
==7972==    definitely lost: 0 bytes in 0 blocks
==7972==    indirectly lost: 0 bytes in 0 blocks
==7972==      possibly lost: 2,064 bytes in 1 blocks
==7972==    still reachable: 0 bytes in 0 blocks
==7972==         suppressed: 20,347 bytes in 186 blocks
==7972== 
==7972== For counts of detected and suppressed errors, rerun with: -v
==7972== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 17 from 17)

【问题讨论】:

  • 如果您不介意将我的答案标记为正确或发布您的解决方案(如果答案不同),我将不胜感激 :)
  • Tbh 我已经好几个月没有接触 Valgrind 或 c,所以我对什么是正确的没有一个明智的意见。这种情况下的 SO 协议是什么?
  • 不确定。我想如果您仍在想办法解决您的问题,或者您是否打算在未来某个时间尝试解决,那么请留下它,直到您发现某人的答案有帮助或只是发布您自己的答案。如果您只是完全放弃了这个问题并且不打算回到它,那么我认为您最好选择一个答案来关闭它。如果出现更好的答案,您可以随时更改答案

标签: c macos memory-leaks valgrind


【解决方案1】:

Valgrind 主要是用于 Linux 的工具,对 OSX 的支持较少。这意味着 Valgrind 会在 OSX 上产生很多误报。如果您想抑制那些可能丢失的泄漏,请将--gen-suppressions=all(或--gen-suppressions=yes,如果您想一一挑选报告的泄漏)选项添加到您的valgrind 调用中。这会为每个报告的内存泄漏打印一段文本,如下所示:

{
   <insert_a_suppression_name_here>
   Memcheck:Leak
   match-leak-kinds: indirect
   fun:malloc
   fun:__Balloc_D2A
   fun:__rv_alloc_D2A
   fun:__dtoa
   fun:__vfprintf
   fun:__v2printf
   fun:vfprintf_l
   fun:printf
   fun:main
}

将括号和所有内容复制并粘贴到名为/Users/username/leak1.supp 之类的文件中。随意将&lt;...&gt; 更改为您的压制的实际名称。然后当你调用valgrind 时,如果你添加了--suppressions=/Users/&lt;username&gt;/leak1.supp 选项,那么内存泄漏报告将被抑制。为了使这更容易,您可以将内容放入~/.valgrindrc 文件中。这个文件可能看起来像

--tool=memcheck
--leak-check=full
--show-reachable=yes
--suppressions=/Users/benlindsay/leak1.supp
--suppressions=/Users/benlindsay/leak2.supp

或者,如果您可以在 Linux 机器上测试您的代码,您就不必担心所有这些;)

--编辑--

我从this other SO post得到了很多我的信息

【讨论】:

  • 你怎么知道是误报?
  • 一般来说,我不知道你如何判断你是否看到误报,但在你的具体情况下,你没有分配任何内存,所以很合理假设您没有泄漏任何内存。
  • 刚刚再次查看输出,我看到了快速的东西。奇怪!?
  • 是的,我猜 Mac OSX 中的一些误报与引导的 C 库有关(请参阅另一篇文章的 this answer),这可能解释...
猜你喜欢
  • 1970-01-01
  • 2015-08-10
  • 2013-06-24
  • 1970-01-01
  • 1970-01-01
  • 2015-08-12
  • 2020-03-31
  • 2016-03-15
  • 2014-04-09
相关资源
最近更新 更多