Как valgrind определяет утечку памяти, и что делает компилятор?
Пишу долго работающую программу (демон). Использую библиотеку commoncpp.
Проверяю valgrind-ом и по сообщениям делаю вывод (может быть скоропалительный и неправильный),
что есть утечка памяти. Количество выделений памяти меньше количества освобождений.
В результате всяческих метаний обнаружил интересный момент.
Вот текст программы (после ВСЕХ обрезаний):#include <cstdlib>
int main(int argc, char **argv)
{
return EXIT_SUCCESS;
}компиляция:
g++ -o main main.cpp
проверка на вшивость:
valgrind ./main
==6508== Memcheck, a memory error detector.
==6508== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
==6508== Using LibVEX rev 1732, a library for dynamic binary translation.
==6508== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
==6508== Using valgrind-3.2.3, a dynamic binary instrumentation framework.
==6508== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
==6508== For more details, rerun with: -v
==6508==
==6508==
==6508== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 18 from 1)
==6508== malloc/free: in use at exit: 0 bytes in 0 blocks.
==6508== malloc/free: 0 allocs, 0 frees, 0 bytes allocated.
==6508== For counts of detected errors, rerun with: -v
==6508== All heap blocks were freed -- no leaks are possible.т.е ОК,
но если компилировать вот так (подключаем библиотеку):g++ -o main main.cpp `ccgnu2-config --libs`
то проверка дает не ожидаемый результат
valgrind ./main
==6542== Memcheck, a memory error detector.
==6542== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
==6542== Using LibVEX rev 1732, a library for dynamic binary translation.
==6542== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
==6542== Using valgrind-3.2.3, a dynamic binary instrumentation framework.
==6542== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
==6542== For more details, rerun with: -v
==6542==
==6542==
==6542== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 26 from 1)
==6542== malloc/free: in use at exit: 212 bytes in 1 blocks.
==6542== malloc/free: 2 allocs, 1 frees, 732 bytes allocated.
==6542== For counts of detected errors, rerun with: -v
==6542== searching for pointers to 1 not-freed blocks.
==6542== checked 197,332 bytes.
==6542==
==6542== LEAK SUMMARY:
==6542== definitely lost: 0 bytes in 0 blocks.
==6542== possibly lost: 0 bytes in 0 blocks.
==6542== still reachable: 212 bytes in 1 blocks.
==6542== suppressed: 0 bytes in 0 blocks.
==6542== Rerun with --leak-check=full to see details of leaked memory.т.е. количество аллокаций не на 1 больше, чем количество освобождений.
Но ведь ни одной функции, класса или чего там еще, я в программе не использовал,
текст остался прежним (см. начало поста).
КАК может такое происходить?
По-порядку:1. valgrind определяет утечку памяти за счет ведения учета операций выделения и освобождения памяти через malloc/free, new/delete и new[]/delete[]. При завершении процесса производится проверка соответствия выделенного освобожденному. Ненулевая величина в поле "still reachable" говорит о наличии динамически выделенных участков памяти, на которые есть указатели в стеке и в глобальных переменных - либо в других участках динамической памяти, которые, сами по себе, доступны через стек или глобальные переменные.
2. Появление ненулевого "still reachable" при пустом main() после подключения некоей библиотеки означает, что код инициализации библиотеки (например, код конструкторов глобальных объектов) содержит операции выделения памяти, а код очистки (тех же деструкторов) эту память не освобождает. В принципе нет ничего плохого в том, что для работы библиотеки постоянно требуется некая фиксированная область памяти, управляемая ей. Главное, чтобы такая память не росла по мере работы программы.