На OSX Valgrind сообщает об этой утечке памяти. Откуда она? - PullRequest
Новая
       1

На OSX Valgrind сообщает об этой утечке памяти. Откуда она?

5 голосов
/ 27 января 2012

На OSX Valgrind сообщает об этой утечке памяти. Откуда она?Код скомпилирован с g ++ как код 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: ???

РЕДАКТИРОВАТЬ: также, как бы я освободил эту память?

Ответы [ 4 ]

5 голосов
/ 28 января 2012

Распределение полностью вне вашего контроля;бесплатное для вас также практически невозможно.Это должно быть добавлено в список известных, обнаруженных, записанных, но игнорируемых элементов («подавленный» - это жаргон).

Когда я запускаю программу под valgrind 3.7.0 на MacOS 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
0 голосов
/ 27 марта 2014

Я не уверен, какую версию osx вы используете.Но в версии, которую я использую, valgrind сообщает об этих ошибках как об игнорируемых.

0 голосов
/ 28 января 2012

В OS X вам нужно запустить valgrind с параметром --dsymutil = yes, чтобы получить более полезную информацию о месте утечки

0 голосов
/ 28 января 2012

Похоже, что он находится в одной из библиотек, которые вы используете, если это так, то убедитесь, что вы правильно используете API библиотеки, но также знаете, что иногда библиотека выделяет глобальные ресурсы, например, при инициализации, чтоне освобождается до выхода из программы.

Например, рассмотрим следующую ситуацию: 

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

Как библиотека может освободить этот буфер перед выходом?не может, пока программа не выйдет и ее память не будет возвращена ОС.

См. Общие ошибки здесь

Редактировать: технически, в приведенном выше примере, bufможет быть free'd, как предложено одним из комментариев ниже, но многие библиотеки не утруждают себя этим, потому что buf будет использоваться на протяжении всей программы, а память будет возвращаться при выходе из программы, поэтому valgrind сообщает об этом какутечка памяти.

...