开罗链接导致内存泄漏
Cairo Linking Causes Memory Leak
我在 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 运算符释放的内存，这可能是也可能不是故意泄漏。至少在我看来，"leaked memory" 是 你 可以有意释放但没有释放的内存。
根据您提供的诊断输出，您无法判断这 12,384 个字节是由 C 运行时分配的还是由 Cairo 分配的。 12K 也有可能是动态链接开销，如果 Cairo 是您系统上的 .so 对象，则可能会出现这种情况。在那种情况下，这是您无法逃避的运行时开销。
基本上，如果没有运行 --leak-check=full，您无法最终证明或反驳内存泄漏或是谁泄漏的。
并且（现在）由于 valgrind 没有提供进一步的见解，并且 dmalloc 说指针是外来的，老派方法是：启动 gdb，设置malloc 中的断点并查看回溯。
同意scooter 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 的能力，并为各种代码选择尽可能快的代码。这不算是真正的泄漏，我想说（另外，这不能安全地解除分配）。
只需在调用 cairo_xxx() 绘制文本或其他内容的函数末尾添加 cairo_debug_reset_static_data() 即可。如果好的话，你只会看到 pixman 库的一些可达到的损失，根据 Uli Schlachter 所说，这没什么大不了的。这样事情就完成了。
我在 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 运算符释放的内存，这可能是也可能不是故意泄漏。至少在我看来，"leaked memory" 是 你 可以有意释放但没有释放的内存。
根据您提供的诊断输出，您无法判断这 12,384 个字节是由 C 运行时分配的还是由 Cairo 分配的。 12K 也有可能是动态链接开销，如果 Cairo 是您系统上的 .so 对象，则可能会出现这种情况。在那种情况下，这是您无法逃避的运行时开销。
基本上，如果没有运行 --leak-check=full，您无法最终证明或反驳内存泄漏或是谁泄漏的。
并且（现在）由于 valgrind 没有提供进一步的见解，并且 dmalloc 说指针是外来的，老派方法是：启动 gdb，设置malloc 中的断点并查看回溯。
同意scooter 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 的能力，并为各种代码选择尽可能快的代码。这不算是真正的泄漏，我想说（另外，这不能安全地解除分配）。
只需在调用 cairo_xxx() 绘制文本或其他内容的函数末尾添加 cairo_debug_reset_static_data() 即可。如果好的话，你只会看到 pixman 库的一些可达到的损失，根据 Uli Schlachter 所说，这没什么大不了的。这样事情就完成了。