开罗链接导致内存泄漏

时间：2016-04-14 20:13:32

标签： c memory-leaks valgrind cairo

我正在搞乱开罗并很快意识到即使只是定期链接库（-I / usr / include / cairo）而不使用它或分配任何东西也会导致内存泄漏。 有人有这个问题吗？是否需要包含一段特定于cairo的代码以避免链接时出现泄漏？

示例Hello世界计划：

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

3 个答案:

答案 0 :(得分：2)

你没有看到泄露的记忆。当应用程序退出时，您会看到未通过free()或delete运算符释放的内存，这可能是也可能不是故意泄漏。在我看来，至少，＆＃34;泄露记忆＆＃34;是你可能故意解除分配的记忆，但没有。

从您提供的诊断输出中，您无法判断12,384字节是由C运行时还是由Cairo分配的。还有12K是动态链接开销的可能性，如果Cairo是您系统上的.so对象，则可能就是这种情况。在这种情况下，它无法逃脱它的运行时开销。

基本上，如果不与--leak-check=full一起运行，您无法最终证明或反驳内存泄露或泄露内存。

而且（现在）由于valgrind没有提供进一步的见解，dmalloc说指针是外来的，旧的学校方法是：启动gdb，设置malloc中的断点并查看回溯。

答案 1 :(得分：2)

我同意滑板车me fecit的回答。无论如何，如果你用--leak-check=full --show-reachable=yes运行它并使用pixman的调试版本，valgrind告诉你的是：

==3300== HEAP SUMMARY:
==3300==     in use at exit: 12,384 bytes in 6 blocks
==3300==   total heap usage: 6 allocs, 0 frees, 12,384 bytes allocated
==3300== 
==3300== 2,064 bytes in 1 blocks are still reachable in loss record 1 of 6
==3300==    at 0x4C29C0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3300==    by 0x575D8AA: _pixman_implementation_create (pixman-implementation.c:38)
==3300==    by 0x575C3EE: _pixman_implementation_create_general (pixman-general.c:250)
==3300==    by 0x575DF45: _pixman_choose_implementation (pixman-implementation.c:388)
==3300==    by 0x57152C8: pixman_constructor (pixman.c:39)
==3300==    by 0x400F2D9: call_init.part.0 (in /lib/x86_64-linux-gnu/ld-2.22.so)
==3300==    by 0x400F3EA: _dl_init (in /lib/x86_64-linux-gnu/ld-2.22.so)
==3300==    by 0x4000CC9: ??? (in /lib/x86_64-linux-gnu/ld-2.22.so)
==3300== 
==3300== 2,064 bytes in 1 blocks are still reachable in loss record 2 of 6
==3300==    at 0x4C29C0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3300==    by 0x575D8AA: _pixman_implementation_create (pixman-implementation.c:38)
==3300==    by 0x575AF3F: _pixman_implementation_create_fast_path (pixman-fast-path.c:3286)
==3300==    by 0x575DF60: _pixman_choose_implementation (pixman-implementation.c:391)
==3300==    by 0x57152C8: pixman_constructor (pixman.c:39)
==3300==    by 0x400F2D9: call_init.part.0 (in /lib/x86_64-linux-gnu/ld-2.22.so)
==3300==    by 0x400F3EA: _dl_init (in /lib/x86_64-linux-gnu/ld-2.22.so)
==3300==    by 0x4000CC9: ??? (in /lib/x86_64-linux-gnu/ld-2.22.so)
==3300== 
==3300== 2,064 bytes in 1 blocks are still reachable in loss record 3 of 6
==3300==    at 0x4C29C0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3300==    by 0x575D8AA: _pixman_implementation_create (pixman-implementation.c:38)
==3300==    by 0x57761DF: _pixman_implementation_create_mmx (pixman-mmx.c:4021)
==3300==    by 0x57433C5: _pixman_x86_get_implementations (pixman-x86.c:234)
==3300==    by 0x575DF6B: _pixman_choose_implementation (pixman-implementation.c:393)
==3300==    by 0x57152C8: pixman_constructor (pixman.c:39)
==3300==    by 0x400F2D9: call_init.part.0 (in /lib/x86_64-linux-gnu/ld-2.22.so)
==3300==    by 0x400F3EA: _dl_init (in /lib/x86_64-linux-gnu/ld-2.22.so)
==3300==    by 0x4000CC9: ??? (in /lib/x86_64-linux-gnu/ld-2.22.so)
==3300== 
==3300== 2,064 bytes in 1 blocks are still reachable in loss record 4 of 6
==3300==    at 0x4C29C0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3300==    by 0x575D8AA: _pixman_implementation_create (pixman-implementation.c:38)
==3300==    by 0x57972BF: _pixman_implementation_create_sse2 (pixman-sse2.c:6487)
==3300==    by 0x57433A5: _pixman_x86_get_implementations (pixman-x86.c:239)
==3300==    by 0x575DF6B: _pixman_choose_implementation (pixman-implementation.c:393)
==3300==    by 0x57152C8: pixman_constructor (pixman.c:39)
==3300==    by 0x400F2D9: call_init.part.0 (in /lib/x86_64-linux-gnu/ld-2.22.so)
==3300==    by 0x400F3EA: _dl_init (in /lib/x86_64-linux-gnu/ld-2.22.so)
==3300==    by 0x4000CC9: ??? (in /lib/x86_64-linux-gnu/ld-2.22.so)
==3300== 
==3300== 2,064 bytes in 1 blocks are still reachable in loss record 5 of 6
==3300==    at 0x4C29C0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3300==    by 0x575D8AA: _pixman_implementation_create (pixman-implementation.c:38)
==3300==    by 0x579795F: _pixman_implementation_create_ssse3 (pixman-ssse3.c:345)
==3300==    by 0x575DF6B: _pixman_choose_implementation (pixman-implementation.c:393)
==3300==    by 0x57152C8: pixman_constructor (pixman.c:39)
==3300==    by 0x400F2D9: call_init.part.0 (in /lib/x86_64-linux-gnu/ld-2.22.so)
==3300==    by 0x400F3EA: _dl_init (in /lib/x86_64-linux-gnu/ld-2.22.so)
==3300==    by 0x4000CC9: ??? (in /lib/x86_64-linux-gnu/ld-2.22.so)
==3300== 
==3300== 2,064 bytes in 1 blocks are still reachable in loss record 6 of 6
==3300==    at 0x4C29C0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3300==    by 0x575D8AA: _pixman_implementation_create (pixman-implementation.c:38)
==3300==    by 0x57604CF: _pixman_implementation_create_noop (pixman-noop.c:155)
==3300==    by 0x57152C8: pixman_constructor (pixman.c:39)
==3300==    by 0x400F2D9: call_init.part.0 (in /lib/x86_64-linux-gnu/ld-2.22.so)
==3300==    by 0x400F3EA: _dl_init (in /lib/x86_64-linux-gnu/ld-2.22.so)
==3300==    by 0x4000CC9: ??? (in /lib/x86_64-linux-gnu/ld-2.22.so)
==3300== 
==3300== LEAK SUMMARY:
==3300==    definitely lost: 0 bytes in 0 blocks
==3300==    indirectly lost: 0 bytes in 0 blocks
==3300==      possibly lost: 0 bytes in 0 blocks
==3300==    still reachable: 12,384 bytes in 6 blocks
==3300==         suppressed: 0 bytes in 0 blocks

_pixman_choose_implementation()的作用是查看CPU的功能并为各种代码选择最快的代码。这不算是真正的泄漏，我会说（另外，这不能安全地解除分配）。

答案 2 :(得分：1)

只需在调用 cairo_debug_reset_static_data() 的函数末尾添加 cairo_xxx() 即可绘制文本或其他内容。如果好，您只会看到 pixman 库中的一些可达到的损失，根据 Uli Schlachter 所说，这没什么大不了的。事情就这么办了。

相关问题
最新问题