在OSX上Valgrind报告这个内存泄漏，它从哪里来？ [英] On OSX Valgrind reports this memory leak, Where is it coming from?

问题描述

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

 
 == 13088 == 1 bytes in 1块肯定是丢在负的战绩264 
 == 13088在0x1F25DC == 82：malloc_zone_malloc（vg_replace_malloc.c：267）
 == == 13088通过0xA1AEDA：malloc_set_zone_name（在/ usr / lib中/系统/ libsystem_c.dylib）
 == == 13088通过0xA1B4A7：_malloc_initialize（以/usr/lib/system/libsystem_c.dylib）
 == == 13088通过0xA1B5DD：malloc_good_size（在/ usr / LIB /系统/ libsystem_c.dylib）
 == == 13088通过0x4EFA6E：__CFStringChangeSizeMultiple（以/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation）
 == == 13088通过0x4F3900：CFStringAppend（在/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation）
 == 13088 == by 0x506F91：_convertToURLRepresentation（在/System/Library/Frameworks/CoreFoundation.framework/Versions/ A / CoreFoundation）
 == 13088 == by 0x60F963：_CFURLInit（在/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation）
 == 13088 == by 0x4FF268：CFURLCreateWithFileSystemPathRelativeToBase在/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation）
 == 13088 == by 0x4FF8EE：CFURLCreateWithFileSystemPath（在/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation） 
 == 13088 == by 0x515735：_CFBundleGetMainBundleAlreadyLocked（在/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation）
 == 13088 == by 0x515663：CFBundleGetMainBundle（在/ System /库/框架/ CoreFoundation.framework /版本/ A /的CoreFoundation）
 == == 13088通过0x539533：cacheBundleInfo（以/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation）
 == == 13088通过0x5394B3：_CFAppVersionCheckLessThan（以/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation）
 == == 13088通过0x56C35B：__CFInitialize（在/系统/库/框架/ CoreFoundation.framework /版本/ A /的CoreFoundation）
 == == 13088通过0x8FE11243：ImageLoaderMachO :: doImageInit（ImageLoader的:: LinkContext常量&）（在/ usr / lib中/ dyld的）
 == 13088 = = by 0x8FE10CB3：ImageLoaderMachO :: doInitialization（ImageLoader :: LinkContext const&）（在/ usr / lib / dyld）
 == 13088 == by 0x8FE0E21F：ImageLoader :: recursiveInitialization（ImageLoader :: LinkContext const&，unsigned int， ImageLoader :: InitializerTimingList&）（在/ usr / lib / dyld）
 == 13088 == by 0x8FE0E1B5：ImageLoader :: recursiveInitialization（ImageLoader :: LinkContext const&，unsigned int，ImageLoader :: InitializerTimingList& LIB / dyld的）
 == == 13088通过0x8FE0F1BF：ImageLoader的:: runInitializers（ImageLoader的:: LinkContext常量和，ImageLoader的:: InitializerTimingList&）（在/ usr / lib中/ dyld的）
 == == 13088通过0x8FE03655：dyld :: initializeMainExecutable（）（在/ usr / lib / dyld）
 == 13088 == by 0x8FE07EF1：dyld :: _ main（macho_header const *，unsigned long，int，char const **，char const **，char const **）（在/ usr / lib / dyld）
 == 13088 == by 0x8FE012EE：dyldbootstrap :: start（macho_header const *，int，char const **，long，macho_header const *）（在/ usr / lib / dyld）
 == 13088 == by 0x8FE01062：_dyld_start（在/ usr / lib / dyld）
 == 13088 == by 0xFFF：？ 
 
 
 
 
编辑：同样，我如何释放这个内存？
方案
分配完全不受您的控制;自由同样基本上是不可能的。这应该被添加到已知，检测，记录但被忽略的项目的列表（'压制'是术语）。
 
 
 
当我运行valgrind 3.7.0在MacOS X 10.7.2，我得到一个总结如下：
  == 71989 == 
 == 71989 = = HEAP摘要：
 == 71989 ==在退出时使用：3319块中的6,191字节
 == 71989 ==总堆使用：33分配，0释放，6,191字节分配
 = = 71989 == 
 == 71989 == LEAK摘要：
 == 71989 == defin lost：0 bytes in 0 blocks 
 == 71989 == indirect lost：0 bytes in 0 blocks 
 == 71989 ==可能丢失：0块在0块
 == 71989 ==仍然可达：6,191字节在33块
 == 71989 ==被抑制：0块0块
 == 71989 ==重新运行--leak-check = full以查看泄漏内存的详细信息
 == 71989 == 
 == 71989 ==对于检测到的和抑制的错误计数，重新运行：-v 
 == 71989 == ERROR摘要：0个上下文中的0个错误（抑制：1从1开始）
  
这是一个程序，它没有明确的内存分配 -  的printf（）可能会引发一些配置，但大部分这些字节在系统中分配图书馆。你明显有一个比正常的值设置的回溯（  -  num-callers = N ）。
 
 
 
查看手册中如何正确添加抑制记录，但 valgrind --help 提供：
   -  num-callers =< number> show< number>调用者在堆栈跟踪[12] 
 --error-limit = no |是停止显示新的错误，如果太多？ [yes] 
 --error-exitcode =< number>退出代码返回如果发现错误[0 =禁用] 
 --show-below-main = no |是继续堆栈跟踪main（）[no] 
 --suppressions =< filename&抑制< filename>中描述的错误。 
 --gen-suppressions = no | yes |所有打印禁止错误？ [no] 
  
所以，你可以得到 valgrind  
 额外的选项读取从〜 /.valgrindrc，$ VALGRIND_OPTS，./.valgrindrc 
  
 
On OSX Valgrind reports this memory leak, Where is it coming from? The code is c compiled with g++ as c++ code (i do this for function overloading).
==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: ???
EDIT: also, how would I release this memory?
解决方案
The allocation is completely out of your control; the free is likewise substantially impossible for you.  This should be added to the list of known, detected, recorded but ignored items ('suppressed' is the jargon).

When I run a program under valgrind 3.7.0 on MacOS X 10.7.2, I get a summary like:
==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)
This is from a program that does no explicit memory allocation - printf() may trigger some allocation, but most of those bytes are allocated in system libraries.  You've clearly got a deeper than normal value set for the traceback (--num-callers=N).

Look in the manual for how to add a suppression record properly, but valgrind --help offers:
--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]
So, you could get valgrind to generate the suppression string for you to add to a file which you then use in subsequent runs.
Extra options read from ~/.valgrindrc, $VALGRIND_OPTS, ./.valgrindrc


                        
这篇关于在OSX上Valgrind报告这个内存泄漏，它从哪里来？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！