Обнаружение утечки памяти GCC, эквивалентное Microsoft crtdbg.h?

Может быть, вы могли бы использовать сборщик мусора Boehm в качестве средства обнаружения утечек:

http://www.hpl.hp.com/personal/Hans_Boehm/gc/leak.html

С сайта:

#include "leak_detector.h"

main() {
    int *p[10];
    int i;
    /* GC_find_leak = 1; for new collector versions not     */
    /* compiled with -DFIND_LEAK.               */
    for (i = 0; i < 10; ++i) {
    p[i] = malloc(sizeof(int)+i);
    }
    for (i = 1; i < 10; ++i) {
    free(p[i]);
    }
    for (i = 0; i < 9; ++i) {
    p[i] = malloc(sizeof(int)+i);
    }
    CHECK_LEAKS();
}   

(вы получаете уведомление через stderr)

Я не знаю ничего "встроенного", которое делает то, что вы описываете, но не похоже, что было бы очень сложно "свернуть свою" версию этого. Вам просто нужно, чтобы новая отладка записывала указатель, файл и строку в map , где ключом является выделенный указатель, а значение ( AllocationInfo ) будет некоторая структура, содержащая имя файла, номер строки и т. д. Вам также необходимо определить пользовательский оператор удаления, который проверяет карту на предмет удаляемого указателя. В случае обнаружения эта запись удаляется с карты. Затем во время завершения процесса вы выдаете содержимое карты.

Я нашел страницу, где кто-то описывает свою собственную систему, которая работает подобным образом .

У меня была такая же проблема, когда мы начали переносить на Mac. «Запуск с инструментом повышения производительности -> Утечки» было единственным, что я нашел, и я не в восторге от этого ... по крайней мере, по сравнению с CRTDEBUG. Я понимаю, что есть некоторые варианты (как описано здесь другими), но в конечном итоге, поскольку мы многоплатформенные, мы используем Windows для поиска утечек.

Поскольку вы упомянули статический анализатор. Мы потратили некоторое время, пытаясь выяснить, как запустить его, пока не обнаружили, что он работает только с C, но не с C ++

У вас есть несколько вариантов, доступных вам.

Во-первых, и наиболее часто вы можете запускать свое приложение с помощью таких инструментов, как Valgrind . Это должно указать вам на ряд злоупотреблений памятью, таких как чтение и запись с помощью указателя NULL и утечки памяти. В наборе Valgrind имеется ряд инструментов, поэтому обязательно ознакомьтесь с ними.

Во-вторых, вы всегда можете использовать библиотеку, которая использует уловку LD_PRELOAD . По сути, трюк LD_PRELOAD позволяет внедрять DLL, что означает, что можно создавать инструменты, которые помогут отслеживать использование памяти в приложении без каких-либо изменений. Вы найдете такие инструменты, как dmalloc и efence , которые весьма обширны в предлагаемых ими средствах отладки.

Наконец, последние выпуски GCC включают инструмент под названием Mudflap . Это в основном использует инструментарий функций для обертывания вызовов вокруг тех же функций памяти, что и dmalloc, efence и Valgrind. Программа будет заметно медленнее, и ее можно будет настраивать во время выполнения, хотя похоже, что у нее есть большой потенциал.

Я использовал все три и нашел Valgrind очень полезным. Я тоже был очень заинтересован в использовании Mudflap, хотя пока не смог.

Вы также можете найти полезную переменную среды MALLOC_CHECK_.

Из справочной страницы malloc (3):

Последние версии Linux libc (позже, чем 5.4.23) и glibc (2 .x) включают реализацию malloc (), которая настраивается с помощью переменных среды. Когда установлен MALLOC_CHECK_, используется специальная (менее эффективная) реализация, которая разработана так, чтобы быть толерантной к простым ошибкам, таким как двойные вызовы free () с одним и тем же аргументом или переполнение одного байта (ошибки по отдельности ). Однако не все такие ошибки можно защитить, и это может привести к утечкам памяти. Если MALLOC_CHECK_ установлен в 0, любое обнаруженное повреждение кучи автоматически игнорируется; если установлено в 1, диагностическое сообщение печатается на stderr; если установлено значение 2, немедленно вызывается abort (3); если установлено значение 3, диагностическое сообщение печатается на stderr и программа прерывается. Использование ненулевого значения MALLOC_CHECK_ может быть полезно, потому что в противном случае сбой может произойти намного позже, и истинную причину проблемы тогда очень трудно отследить.