Question

我有以下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 *（should I free pointer returned by getpwuid() in 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)

Answer 1

似乎不是“真正的”泄漏，即，如果多次调用，泄漏不会复合;可能它拥有一个指向内存区域的静态指针，如果它是NULL（第一次），它会分配这60个字节，然后不释放它们。

MacOS X版本使用真正的静态区域，或者valgrind更好suppressors。

只需在循环中运行getpwuid几百次，确保它确实只泄漏了60个字节（而不是1200个），只是为了确定。

<强>更新

我终于跟踪了nssswitch.c和getXXent.c内不同大小和说服的几个结构的泄漏。虽然代码似乎做出了比实际需要更多的分配，需要malloc锁，但这通常不应该是性能明显的，而我肯定会做不打算进行二次猜测 glibc的维护者！

Answer 2

可能不是getpwuid()本身导致那个（假）正面。它可能是C库在启动时初始化的任何数量的其他东西，但是在进程终止时不会被拆除（因为进程正在消失，以及属于它的所有映射内存，有些东西都没有真的需要被破坏/未分配。正如另一个答案所说，运行一些额外的测试，特别是当您构建超出您提供的简单示例的更多代码时，并确保数字是稳定的，而不是直接归因于您自己的代码。除了提交错误报告（我假设您不是C库开发人员之一）之外，您无法直接对库代码做任何事情。（

valgrind使用Ubuntu报告getpwuid（）在c ++中泄漏

2 个答案: