valgrind сообщает, что getpwuid () обнаруживает утечку в c ++ с помощью Ubuntu

Question

valgrind сообщает, что getpwuid () обнаруживает утечку в c ++ с помощью Ubuntu

У меня есть следующий файл C ++, pwd01.cpp:

#include <pwd.h>
#include <iostream>
int main() {
passwd* pwd = getpwuid(getuid());
}

Я компилирую это с помощью следующей команды:

g++ pwd01.cpp -Wall -o pwd01

В Ubuntu 12.04.1 LTS / gcc версии 4.6.3 valgrind сообщает об утечке (см. Ниже). Когда я компилирую тот же код с той же командой в Mac OS 10.6.8 / gcc версии 4.2.1, valgrind не сообщает об утечках.

Я в курсе, что мне не нужно освобождать passwd * ( я должен освободить указатель, возвращаемый getpwuid () в Linux? ); так чего мне не хватает?

valgrind ./pwd01
==10618== Memcheck, a memory error detector
==10618== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==10618== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==10618== Command: ./pwd01
==10618==
==10618==
==10618== HEAP SUMMARY:
==10618==     in use at exit: 300 bytes in 11 blocks
==10618==   total heap usage: 68 allocs, 57 frees, 10,130 bytes allocated
==10618==
==10618== LEAK SUMMARY:
==10618==    definitely lost: 60 bytes in 1 blocks
==10618==    indirectly lost: 240 bytes in 10 blocks
==10618==      possibly lost: 0 bytes in 0 blocks
==10618==    still reachable: 0 bytes in 0 blocks
==10618==         suppressed: 0 bytes in 0 blocks
==10618== Rerun with --leak-check=full to see details of leaked memory
==10618==
==10618== For counts of detected and suppressed errors, rerun with: -v
==10618== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2)

1

c++getpwuid memory-leaks ubuntu-12.04 valgrind

Решение

Другие решения

А может и не быть getpwuid() Сам, что вызывает это (ложное) положительное. Это может быть любое количество других вещей, которые библиотека C инициализирует во время запуска, но затем не разрушает при завершении процесса (поскольку процесс уходит вместе со всей отображенной памятью, которая ему принадлежит, некоторые вещи не не должно быть уничтожено / нераспределено). Как сказал другой ответ, запустите некоторые дополнительные тесты, особенно когда вы создаете больше кода, помимо простого примера, который вы предоставили, и убедитесь, что числа стабильны и не связаны напрямую с вашим собственным кодом. Вы не можете ничего сделать непосредственно с библиотечным кодом, за исключением отправки отчета об ошибке (в любом случае, я предполагаю, что вы не являетесь одним из разработчиков библиотеки C).

0

Источник

Accepted Answer

Кажется, что это не «настоящая» утечка, то есть, если она вызывается несколько раз, утечка не усугубляется; возможно, он содержит статический указатель на область памяти, если он равен NULL (в первый раз), он выделяет эти 60 байтов, а затем не освобождает их.

Версия MacOS X либо использует действительно статическую область, либо ее valgrind стало лучше супрессоров.

Просто запустите getpwuid пара сотен раз в цикле, чтобы гарантировать, что он действительно пропускает только 60 байтов (а не 1200), просто чтобы быть уверенным.

ОБНОВИТЬ

Я наконец-то проследил утечку до нескольких структур внутри nssswitch.c а также getXXent.c, разных размеров и убеждений. В то время как код, кажется, делает намного больше выделений, чем действительно необходимо, требуя блокировок malloc, это обычно не должно быть заметно с точки зрения производительности, и я, безусловно, сделаю не намереваться догадаться Сопровождающие Glibc!

2