1

我有以下 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* （我应该释放 Linux 中 getpwuid() 返回的指针吗？）；所以我错过了什么？

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)
4

2 回答 2

2

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

MacOS X 版本要么使用真正的静态区域，要么valgrind拥有更好的抑制器。

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

更新

我终于追踪到内部的几个结构的泄漏nssswitch.c，getXXent.c不同的大小和说服力。虽然代码似乎进行了比实际需要更多的分配，需要 malloc 锁，但这通常不应该是可观的性能，我当然不打算对glibc 的维护者进行第二次猜测！

于 2012-10-16T17:03:38.470 回答
0

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

于 2012-10-16T17:14:01.303 回答