Question

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

==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: ???

编辑：同样，我将如何释放这段记忆？

Answer 1

分配完全超出您的控制范围;对你而言，免费同样根本不可能。这应该添加到已知，检测，记录但忽略的项目列表中（'抑制'是行话）。

当我在MacOS X 10.7.2上的valgrind 3.7.0下运行程序时，我得到一个总结：

==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

Answer 2

它看起来更像是你正在使用的一个库中，如果是这样，那么请确保你正确使用了库的API，但也知道有时库分配全局资源，例如初始化时，它在程序退出之前不会自由。

例如，考虑这种情况：

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

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

见常见陷阱here

编辑：从技术上讲，在上面的例子中，buf可以按照以下评论之一的建议免费使用，但许多库都不会这样做，因为buf将用于程序和内存的持续时间程序退出时将被回收，因此valgrind将其报告为内存泄漏。

Answer 3

在OS X上，您需要使用--dsymutil = yes运行valgrind以获取有关泄漏位置的更多有用信息

Answer 4

我不确定您运行的是哪个版本的osx。但在我运行的版本上，valgrind报告这些错误是可以忽略的。

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

4 个答案: