c++ - valgrind堆总结理解

Question

我正在运行代码，但遇到错误

* glibc detected * /home/build/bin/../bin/OPENSUSE_12.2_X86_64/reader: corrupted double-linked list: 0x0000000003df6dc0 *

我尝试通过 valgrind 重新运行它以了解是否存在内存泄漏问题。我运行它作为

valgrind --leak-check=full -v ./myprog

由于程序没有完成并停止，valgrind 总结如下:

>     ==5335== Process terminating with default action of signal 2 (SIGINT)
>     ==5335==    at 0x54E4007: kill (in /lib64/libc-2.15.so)
>     ==5335==    by 0x429473: ??? (in /bin/bash)
>     ==5335==    by 0x42A313: wait_for (in /bin/bash)
>     ==5335==    by 0x462BFE: execute_command_internal (in /bin/bash)
>     ==5335==    by 0x463360: execute_command (in /bin/bash)
>     ==5335==    by 0x41B7F0: reader_loop (in /bin/bash)
>     ==5335==    by 0x41B4C9: main (in /bin/bash)
>     ==5335== 
>     ==5335== HEAP SUMMARY:
>     ==5335==     in use at exit: 37,513 bytes in 1,074 blocks
>     ==5335==   total heap usage: 1,922 allocs, 848 frees, 72,605 bytes allocated
>     ==5335== 
>     ==5335== Searching for pointers to 1,074 not-freed blocks
>     ==5335== Checked 220,224 bytes
>     ==5335== 
>     ==5335== LEAK SUMMARY:
>     ==5335==    definitely lost: 0 bytes in 0 blocks
>     ==5335==    indirectly lost: 0 bytes in 0 blocks
>     ==5335==      possibly lost: 0 bytes in 0 blocks
>     ==5335==    still reachable: 37,513 bytes in 1,074 blocks
>     ==5335==         suppressed: 0 bytes in 0 blocks
>     ==5335== Reachable blocks (those to which a pointer was found) are not shown.
>     ==5335== To see them, rerun with: --leak-check=full --show-reachable=yes
>     ==5335== 
>     ==5335== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2)
>     --5335-- 
>     --5335-- used_suppression:      2 dl-hack3-cond-1
>     ==5335== 
>     ==5335== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2)

总堆使用量:1,922 次分配，848 次释放，我想知道这里是否有任何问题？ 但在错误摘要中没有错误。我想知道我是否应该担心代码中的任何问题或内存泄漏？

Answer 1

这个总结基本上意味着您没有丢弃任何指针(将它们设置为 NULL)，而没有首先释放关联的已分配内存。当程序退出时，任何分配的内存(无论是否泄漏)都将被释放。但是，您是对的 - 您没有泄漏任何内存，因此如果您的程序运行了很长一段时间，您就不会用完堆空间。

理想情况下，您仍然应该尝试自己清理 - 查找 malloc 调用，而不是任何相应的 free 调用。