在OSX上Valgrind报告了这种内存泄漏，它来自哪里？

在OSX Valgrind的报告此内存泄漏，这是哪里来的？该代码是用g ++编译为C++代码（我这样做是为了重载函数）。在OSX上Valgrind报告了这种内存泄漏，它来自哪里？

 
==13088== 18 bytes in 1 blocks are definitely lost in loss record 82 of 264 
==13088== at 0x1F25DC: malloc_zone_malloc (vg_replace_malloc.c:267) 
==13088== by 0xA1AEDA: malloc_set_zone_name (in /usr/lib/system/libsystem_c.dylib) 
==13088== by 0xA1B4A7: _malloc_initialize (in /usr/lib/system/libsystem_c.dylib) 
==13088== by 0xA1B5DD: malloc_good_size (in /usr/lib/system/libsystem_c.dylib) 
==13088== by 0x4EFA6E: __CFStringChangeSizeMultiple (in /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation) 
==13088== by 0x4F3900: CFStringAppend (in /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation) 
==13088== by 0x506F91: _convertToURLRepresentation (in /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation) 
==13088== by 0x60F963: _CFURLInit (in /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation) 
==13088== by 0x4FF268: CFURLCreateWithFileSystemPathRelativeToBase (in /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation) 
==13088== by 0x4FF8EE: CFURLCreateWithFileSystemPath (in /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation) 
==13088== by 0x515735: _CFBundleGetMainBundleAlreadyLocked (in /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation) 
==13088== by 0x515663: CFBundleGetMainBundle (in /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation) 
==13088== by 0x539533: cacheBundleInfo (in /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation) 
==13088== by 0x5394B3: _CFAppVersionCheckLessThan (in /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation) 
==13088== by 0x56C35B: __CFInitialize (in /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation) 
==13088== by 0x8FE11243: ImageLoaderMachO::doImageInit(ImageLoader::LinkContext const&) (in /usr/lib/dyld) 
==13088== by 0x8FE10CB3: ImageLoaderMachO::doInitialization(ImageLoader::LinkContext const&) (in /usr/lib/dyld) 
==13088== by 0x8FE0E21F: ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int, ImageLoader::InitializerTimingList&) (in /usr/lib/dyld) 
==13088== by 0x8FE0E1B5: ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int, ImageLoader::InitializerTimingList&) (in /usr/lib/dyld) 
==13088== by 0x8FE0F1BF: ImageLoader::runInitializers(ImageLoader::LinkContext const&, ImageLoader::InitializerTimingList&) (in /usr/lib/dyld) 
==13088== by 0x8FE03655: dyld::initializeMainExecutable() (in /usr/lib/dyld) 
==13088== by 0x8FE07EF1: dyld::_main(macho_header const*, unsigned long, int, char const**, char const**, char const**) (in /usr/lib/dyld) 
==13088== by 0x8FE012EE: dyldbootstrap::start(macho_header const*, int, char const**, long, macho_header const*) (in /usr/lib/dyld) 
==13088== by 0x8FE01062: _dyld_start (in /usr/lib/dyld) 
==13088== by 0xFFF: ???

编辑：另外，我会如何释放这个内存？

来源

2012-01-27 chacham15

相似的问题：http://stackoverflow.com/questions/5226691/valgrind-mac-os-mem-leak – bames53 2012-01-27 20:03:26

也可能有关：http://www.mail-archive.com/[email protected]。 sourceforge.net/msg03053.html – bames53 2012-01-27 20:05:35

@ bames53不同的是，这种泄漏发生在“肯定失去了”类别，而不是“仍可达” – chacham15 2012-01-27 20:09:34

分配是完全在你的控制;免费对你来说同样是不可能的。这应该被添加到已知，检测，记录但被忽略的项目列表（'压制'是行话）。

当我在MacOS下运行的valgrind 3.7.0程序X 10.7.2，我得到这样的总结：

==71989== 
==71989== HEAP SUMMARY: 
==71989==  in use at exit: 6,191 bytes in 33 blocks 
==71989== total heap usage: 33 allocs, 0 frees, 6,191 bytes allocated 
==71989== 
==71989== LEAK SUMMARY: 
==71989== definitely lost: 0 bytes in 0 blocks 
==71989== indirectly lost: 0 bytes in 0 blocks 
==71989==  possibly lost: 0 bytes in 0 blocks 
==71989== still reachable: 6,191 bytes in 33 blocks 
==71989==   suppressed: 0 bytes in 0 blocks 
==71989== Rerun with --leak-check=full to see details of leaked memory 
==71989== 
==71989== For counts of detected and suppressed errors, rerun with: -v 
==71989== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 1 from 1)

这是从程序，它没有明确的内存分配 - printf()可能会引发一些分配，但大部分这些字节都是在系统库中分配的。你已经清楚地得到了比回溯值设定的更深的值（--num-callers=N）。

看手册如何正确添加抑制纪录，但valgrind --help报价：

--num-callers=<number> show <number> callers in stack traces [12] 
--error-limit=no|yes  stop showing new errors if too many? [yes] 
--error-exitcode=<number> exit code to return if errors found [0=disable] 
--show-below-main=no|yes continue stack traces below main() [no] 
--suppressions=<filename> suppress errors described in <filename> 
--gen-suppressions=no|yes|all print suppressions for errors? [no]

所以，你可以得到valgrind生成抑制串为你添加到一个文件，你再使用在随后的运行中。

Extra options read from ~/.valgrindrc, $VALGRIND_OPTS, ./.valgrindrc

来源

2012-01-27 20:32:46

它看起来更像是它在你使用的图书馆之一，如果是的话，那么要确保你正确使用该库的API，也知道有时候库分配全球资源，初始化例如当，这在程序退出之前它并不是免费的。

例如，考虑这种情况：

void init_lib(){ 
    static char *buf=NULL; 
    if (buf==NULL) { 
     buf = malloc(18); 
    } 
    ..... 
}

如何库退出之前释放这个缓冲区？它不能，直到程序退出并且它的内存被操作系统回收。

参见常见的陷阱here

编辑：技术上，在上面的例子中，BUF可以通过下面的意见之一是建议free'd，但许多图书馆也懒得这样做，因为BUF将使用在程序执行期间，程序退出时将回收内存，因此valgrind会将其报告为内存泄漏。

来源

2012-01-27 20:07:12 iabdalkader

我唯一使用的库是SQLite。我确实称之为释放功能，所以我没有看到这可能是问题所在。 – chacham15 2012-01-27 20:11:20

我已经给我的答案添加了一个例子。 – iabdalkader 2012-01-27 20:12:47

你有一个关机/清理电话。许多图书馆都有这种行为。但是，据我所知，SQLite没有。我认为osx的g ++将链接核心基础库并添加一个初始化调用：'__CFInitialize'。我怎么会打电话给清理？ – chacham15 2012-01-27 20:18:01

在OS X上，你需要与--dsymutil = Valgrind的运行是获得关于泄漏位置

来源

2012-01-27 20:36:25 arsenm

更多有用的信息，我不知道你正在运行的OSX版本。但在我运行的版本中，valgrind会将这些错误报告为可忽略的。

来源

2014-03-26 21:05:28

在OSX上Valgrind报告了这种内存泄漏，它来自哪里？

回答

相关问题