一個空main（）分配內存的程序可以嗎？

我一直在追逐我的程序中的內存問題，該問題鏈接到-lcairo和-lX11。最後，我決定註釋掉我的main()中的所有行，並確保valgrind很開心。令我驚訝的是，它不是：一個空main（）分配內存的程序可以嗎？

==7570== Memcheck, a memory error detector 
==7570== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. 
==7570== Using Valgrind-3.10.0.SVN and LibVEX; rerun with -h for copyright info 
==7570== Command: ./Test 
==7570== 
==7570== 
==7570== HEAP SUMMARY: 
==7570==  in use at exit: 10,360 bytes in 5 blocks 
==7570== total heap usage: 5 allocs, 0 frees, 10,360 bytes allocated 
==7570== 
==7570== 2,072 bytes in 1 blocks are still reachable in loss record 1 of 5 
==7570== at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) 
==7570== by 0x5FCCE9A: ??? (in /usr/lib/x86_64-linux-gnu/libpixman-1.so.0.30.2) 
==7570== by 0x5FCBACE: ??? (in /usr/lib/x86_64-linux-gnu/libpixman-1.so.0.30.2) 
==7570== by 0x5FCD585: ??? (in /usr/lib/x86_64-linux-gnu/libpixman-1.so.0.30.2) 
==7570== by 0x5F7F508: ??? (in /usr/lib/x86_64-linux-gnu/libpixman-1.so.0.30.2) 
==7570== by 0x4010139: call_init.part.0 (dl-init.c:78) 
==7570== by 0x4010222: _dl_init (dl-init.c:36) 
==7570== by 0x4001309: ??? (in /lib/x86_64-linux-gnu/ld-2.19.so) 
==7570== 
==7570== 2,072 bytes in 1 blocks are still reachable in loss record 2 of 5 
==7570== at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) 
==7570== by 0x5FCCE9A: ??? (in /usr/lib/x86_64-linux-gnu/libpixman-1.so.0.30.2) 
==7570== by 0x5FCA61F: ??? (in /usr/lib/x86_64-linux-gnu/libpixman-1.so.0.30.2) 
==7570== by 0x5FCD5A0: ??? (in /usr/lib/x86_64-linux-gnu/libpixman-1.so.0.30.2) 
==7570== by 0x5F7F508: ??? (in /usr/lib/x86_64-linux-gnu/libpixman-1.so.0.30.2) 
==7570== by 0x4010139: call_init.part.0 (dl-init.c:78) 
==7570== by 0x4010222: _dl_init (dl-init.c:36) 
==7570== by 0x4001309: ??? (in /lib/x86_64-linux-gnu/ld-2.19.so) 
==7570== 
==7570== 2,072 bytes in 1 blocks are still reachable in loss record 3 of 5 
==7570== at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) 
==7570== by 0x5FCCE9A: ??? (in /usr/lib/x86_64-linux-gnu/libpixman-1.so.0.30.2) 
==7570== by 0x5FE5A8F: ??? (in /usr/lib/x86_64-linux-gnu/libpixman-1.so.0.30.2) 
==7570== by 0x5FBC1A5: ??? (in /usr/lib/x86_64-linux-gnu/libpixman-1.so.0.30.2) 
==7570== by 0x5FCD5AB: ??? (in /usr/lib/x86_64-linux-gnu/libpixman-1.so.0.30.2) 
==7570== by 0x5F7F508: ??? (in /usr/lib/x86_64-linux-gnu/libpixman-1.so.0.30.2) 
==7570== by 0x4010139: call_init.part.0 (dl-init.c:78) 
==7570== by 0x4010222: _dl_init (dl-init.c:36) 
==7570== by 0x4001309: ??? (in /lib/x86_64-linux-gnu/ld-2.19.so) 
==7570== 
==7570== 2,072 bytes in 1 blocks are still reachable in loss record 4 of 5 
==7570== at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) 
==7570== by 0x5FCCE9A: ??? (in /usr/lib/x86_64-linux-gnu/libpixman-1.so.0.30.2) 
==7570== by 0x60053CF: ??? (in /usr/lib/x86_64-linux-gnu/libpixman-1.so.0.30.2) 
==7570== by 0x5FCD5AB: ??? (in /usr/lib/x86_64-linux-gnu/libpixman-1.so.0.30.2) 
==7570== by 0x5F7F508: ??? (in /usr/lib/x86_64-linux-gnu/libpixman-1.so.0.30.2) 
==7570== by 0x4010139: call_init.part.0 (dl-init.c:78) 
==7570== by 0x4010222: _dl_init (dl-init.c:36) 
==7570== by 0x4001309: ??? (in /lib/x86_64-linux-gnu/ld-2.19.so) 
==7570== 
==7570== 2,072 bytes in 1 blocks are still reachable in loss record 5 of 5 
==7570== at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) 
==7570== by 0x5FCCE9A: ??? (in /usr/lib/x86_64-linux-gnu/libpixman-1.so.0.30.2) 
==7570== by 0x5FCFCBF: ??? (in /usr/lib/x86_64-linux-gnu/libpixman-1.so.0.30.2) 
==7570== by 0x5F7F508: ??? (in /usr/lib/x86_64-linux-gnu/libpixman-1.so.0.30.2) 
==7570== by 0x4010139: call_init.part.0 (dl-init.c:78) 
==7570== by 0x4010222: _dl_init (dl-init.c:36) 
==7570== by 0x4001309: ??? (in /lib/x86_64-linux-gnu/ld-2.19.so) 
==7570== 
==7570== LEAK SUMMARY: 
==7570== definitely lost: 0 bytes in 0 blocks 
==7570== indirectly lost: 0 bytes in 0 blocks 
==7570==  possibly lost: 0 bytes in 0 blocks 
==7570== still reachable: 10,360 bytes in 5 blocks 
==7570==   suppressed: 0 bytes in 0 blocks 
==7570== 
==7570== For counts of detected and suppressed errors, rerun with: -v 
==7570== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

與空main()程序可以分配內存，並與一些到達塊結束了？有沒有辦法擺脫這個奇怪的問題？

來源

2015-11-22 AlwaysLearning

有可能是在你鏈接到的庫靜態對象。你只需要記下這份報告，並在使用真實代碼查找泄漏時折扣這些條目。 –

對。在這個特定的圖書館裏是否有一個已知的解決方案，即「pixman」？ – AlwaysLearning

我不知道。如果它是開源的，你可以嘗試自己構建並進行調查。 –

是的。有可能的。

一種方法是，您鏈接的庫中可能存在一些靜態對象。這已經被@M.M

已經指出。另一種方法是，如果您正在鏈接共享庫，沒有靜態對象，並且此庫中的某些功能使用__attribute__((constructor))。這個屬性導致這些函數在main（）之前執行（僅與gcc一起工作），因此你會看到內存分配。如果在程序中使用這些函數，圖書館主要使用這些函數來聲明其功能的某些屬性。有關這些屬性的更多詳細信息，您可以參考：

http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html

來源

2015-11-22 21:27:15

謝謝。這是有啓發性的。但是，這聽起來似乎是解決這個問題的唯一方法，就是深入研究pixman的源代碼，我並不急於這樣做。我非常感謝一個真正使用pixman的人（直接或間接地，例如通過鏈接到'Cairo'）可以揭示正確的用法，從而產生一個乾淨的石板。 – AlwaysLearning

儘管我不使用pixman，但通常移除該屬性並不會造成巨大的傷害，因爲它主要是爲了編譯器優化。刪除__attribute __（（構造函數））通常不會影響結果，但只會導致較差的編譯器優化。如果庫也是爲非GCC編譯器設計的，那麼你可以使用沒有gcc的庫，由於這些屬性，這不會導致任何開銷。靜態對象很難避免，因爲它們大多是底層固有的算法。確切的答案需要徹底研究pixman –

一個空main（）分配內存的程序可以嗎？

回答

相關問題