開羅鏈接導致內存泄漏

我在開羅搞亂並且很快意識到，即使只是定期鏈接庫（-I/usr/include/cairo）而不使用它或者分配任何東西都會導致內存泄漏。 有沒有人有這個問題？有沒有一個特定的cairo特定的代碼，我需要包括在鏈接時避免泄漏？開羅鏈接導致內存泄漏

樣品Hello World程序：

#include <stdio.h> 

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

定期編譯：

的gcc -o測試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)

來源

2016-04-14 Chirality

你沒有看到泄漏的內存，因爲這樣的。當應用程序退出時，您看到的內存未通過free()或delete運算符被釋放，這可能是也可能不是故意泄漏。在我看來，至少「泄漏的內存」是你可能有意釋放，但沒有。

從您提供的診斷輸出中，無法確定12,384字節是由C運行時還是由開羅分配的。還有一種可能性，即12K是動態鏈接開銷，如果開羅是系統上的.so對象，則可能是這種情況。在那種情況下，它是運行時間開銷，你無法逃脫。

基本上，如果沒有運行--leak-check=full，您不能確定地證明或反駁內存泄漏或泄漏內存。

和（現在），因爲valgrind沒有提供進一步的深入瞭解，以及dmalloc說，指針是國外的，老派的方法是：火起來gdb，在malloc設置一個斷點，並期待在回溯。

來源

2016-04-14 20:29:33

更新了完整的漏洞檢查問題，它絕對沒有洞察力。 – Chirality

那麼，因爲它不是__ you__誰沒有釋放，並且對其他系統或圖書館活動沒有太多可以做的事情，所以你可能應該停止引起自己的焦慮。除非你能確切地確定誰正在分配12K以及是否可以做任何事情。 –

我寧願強調自己。 – Chirality

我同意scooter me fecit的回答。總之，這裏是什麼的valgrind告訴你，如果你--leak-check=full --show-reachable=yes運行它，還可以使用pixman的調試版本：

==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的能力，並選擇以最快的速度碼的各種的碼。這不算真正的泄漏，我會說（加上，這不能安全地釋放）。

來源

2016-04-15 15:43:25

有趣。感謝您的洞察力。我更喜歡我的代碼沒有任何泄漏，不管它們是否是良性的。 – Chirality

@ user10984587：生活在一個完美的世界會很高興，但是，唉，我們不得不高興地遭受愚蠢的對待。 :-) –

開羅鏈接導致內存泄漏

回答

相關問題