开罗链接导致内存泄漏

标签 c memory-leaks valgrind cairo

我在 Cairo 闲逛,很快意识到即使只是定期链接库 (-I/usr/include/cairo) 而没有使用它或分配任何东西都会导致内存泄漏。 有人遇到过这个问题吗?是否需要包含一段特定于 cairo 的代码以避免链接时泄漏?

示例 Hello world 程序:

#include <stdio.h>

int main(){
  printf("Hello, world!\n");
  return 0;
}

定期编译:

gcc -o test test.c -Wall

Hello, world!
==19531== 
==19531== HEAP SUMMARY:
==19531==     in use at exit: 0 bytes in 0 blocks
==19531==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==19531== 
==19531== All heap blocks were freed -- no leaks are possible
==19531== 
==19531== For counts of detected and suppressed errors, rerun with: -v
==19531== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

链接开罗:

gcc -o test test.c -Wall $(pkg-config --cflags --libs cairo)

Hello, world!
==19538== 
==19538== HEAP SUMMARY:
==19538==     in use at exit: 12,384 bytes in 6 blocks
==19538==   total heap usage: 6 allocs, 0 frees, 12,384 bytes allocated
==19538== 
==19538== LEAK SUMMARY:
==19538==    definitely lost: 0 bytes in 0 blocks
==19538==    indirectly lost: 0 bytes in 0 blocks
==19538==      possibly lost: 0 bytes in 0 blocks
==19538==    still reachable: 12,384 bytes in 6 blocks
==19538==         suppressed: 0 bytes in 0 blocks
==19538== Rerun with --leak-check=full to see details of leaked memory
==19538== 
==19538== For counts of detected and suppressed errors, rerun with: -v
==19538== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

泄漏检查=满:

valgrind ./test --leak-check=full -v --tool=memcheck
==20390== Memcheck, a memory error detector
==20390== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==20390== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==20390== Command: ./test --leak-check=full -v --tool=memcheck
==20390== 
--20390-- WARNING: Serious error when reading debug info
--20390-- When reading debug info from /lib/x86_64-linux-gnu/ld-2.22.so:
--20390-- Ignoring non-Dwarf2/3/4 block in .debug_info
--20390-- WARNING: Serious error when reading debug info
--20390-- When reading debug info from /lib/x86_64-linux-gnu/ld-2.22.so:
--20390-- Last block truncated in .debug_info; ignoring
--20390-- WARNING: Serious error when reading debug info
--20390-- When reading debug info from /lib/x86_64-linux-gnu/ld-2.22.so:
--20390-- parse_CU_Header: is neither DWARF2 nor DWARF3 nor DWARF4
--20390-- WARNING: Serious error when reading debug info
--20390-- When reading debug info from /lib/x86_64-linux-gnu/libc-2.22.so:
--20390-- Ignoring non-Dwarf2/3/4 block in .debug_info
--20390-- WARNING: Serious error when reading debug info
--20390-- When reading debug info from /lib/x86_64-linux-gnu/libc-2.22.so:
--20390-- Ignoring non-Dwarf2/3/4 block in .debug_info
--20390-- WARNING: Serious error when reading debug info
--20390-- When reading debug info from /lib/x86_64-linux-gnu/libc-2.22.so:
--20390-- Ignoring non-Dwarf2/3/4 block in .debug_info
--20390-- WARNING: Serious error when reading debug info
--20390-- When reading debug info from /lib/x86_64-linux-gnu/libc-2.22.so:
--20390-- Last block truncated in .debug_info; ignoring
--20390-- WARNING: Serious error when reading debug info
--20390-- When reading debug info from /lib/x86_64-linux-gnu/libc-2.22.so:
--20390-- parse_CU_Header: is neither DWARF2 nor DWARF3 nor DWARF4
--20390-- WARNING: Serious error when reading debug info
--20390-- When reading debug info from /lib/x86_64-linux-gnu/librt-2.22.so:
--20390-- Ignoring non-Dwarf2/3/4 block in .debug_info
--20390-- WARNING: Serious error when reading debug info
--20390-- When reading debug info from /lib/x86_64-linux-gnu/librt-2.22.so:
--20390-- Last block truncated in .debug_info; ignoring
--20390-- WARNING: Serious error when reading debug info
--20390-- When reading debug info from /lib/x86_64-linux-gnu/librt-2.22.so:
--20390-- parse_CU_Header: is neither DWARF2 nor DWARF3 nor DWARF4
--20390-- WARNING: Serious error when reading debug info
--20390-- When reading debug info from /lib/x86_64-linux-gnu/libm-2.22.so:
--20390-- Ignoring non-Dwarf2/3/4 block in .debug_info
--20390-- WARNING: Serious error when reading debug info
--20390-- When reading debug info from /lib/x86_64-linux-gnu/libm-2.22.so:
--20390-- Last block truncated in .debug_info; ignoring
--20390-- WARNING: Serious error when reading debug info
--20390-- When reading debug info from /lib/x86_64-linux-gnu/libm-2.22.so:
--20390-- parse_CU_Header: is neither DWARF2 nor DWARF3 nor DWARF4
--20390-- WARNING: Serious error when reading debug info
--20390-- When reading debug info from /lib/x86_64-linux-gnu/libdl-2.22.so:
--20390-- Ignoring non-Dwarf2/3/4 block in .debug_info
--20390-- WARNING: Serious error when reading debug info
--20390-- When reading debug info from /lib/x86_64-linux-gnu/libdl-2.22.so:
--20390-- Last block truncated in .debug_info; ignoring
--20390-- WARNING: Serious error when reading debug info
--20390-- When reading debug info from /lib/x86_64-linux-gnu/libdl-2.22.so:
--20390-- parse_CU_Header: is neither DWARF2 nor DWARF3 nor DWARF4
Hello, world!
==20390== 
==20390== HEAP SUMMARY:
==20390==     in use at exit: 12,384 bytes in 6 blocks
==20390==   total heap usage: 6 allocs, 0 frees, 12,384 bytes allocated
==20390== 
==20390== LEAK SUMMARY:
==20390==    definitely lost: 0 bytes in 0 blocks
==20390==    indirectly lost: 0 bytes in 0 blocks
==20390==      possibly lost: 0 bytes in 0 blocks
==20390==    still reachable: 12,384 bytes in 6 blocks
==20390==         suppressed: 0 bytes in 0 blocks
==20390== Rerun with --leak-check=full to see details of leaked memory
==20390== 
==20390== For counts of detected and suppressed errors, rerun with: -v
==20390== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

最佳答案

您没有看到泄漏的内存。当应用程序退出时,您会看到未通过 free()delete 运算符释放的内存,这可能是也可能不是故意泄漏。至少在我看来,“泄漏的内存”是本可以有意释放但没有释放的内存。

根据您提供的诊断输出,您无法判断这 12,384 个字节是由 C 运行时还是由 Cairo 分配的。 12K 也有可能是动态链接开销,如果 Cairo 是您系统上的 .so 对象,则可能会出现这种情况。在那种情况下,这是您无法逃避的运行时开销。

基本上,如果不使用 --leak-check=full 运行,您无法最终证明或反驳内存泄漏或是谁泄漏的。

并且(现在)因为 valgrind 没有提供进一步的洞察力,而 dmalloc 说指针是外部的,老派的方法是:启动 gdb,在malloc中设置断点,查看回溯。

关于开罗链接导致内存泄漏,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/36633071/

相关文章:

c - typedef - 不命名类型

iphone - 具有 +0 保留计数的对象返回给调用者,其中期望 +1(拥有)保留计数

android - 这个 Android 示例是否可以安全使用,内存泄漏方面?

c# - 连续创建位图会导致内存泄漏

c - Helgrind 报告单线程上的数据争用

c - 即使在 fclose 之后使用 valgrind 也会出现内存泄漏问题

c++ - 直接丢失或间接丢失-Valgrind问题

c - 用于基数排序的链表中的指针上的 EXC_BAD_ACCESS

不使用字符串函数连接字符串 : Replacing the end of string (null character) gives seg fault

c - 在 c 中的数组中使用时,模式被打印得很奇怪