valgrind在Debian Wheezy在簡約應用程序中泄漏內存時是否捕獲Qt 4.8？

我讀過幾個問題，在這裏人們通過valgrind運行最小的Qt程序，併發布結果。通過查看輸出的一般結論是「好的，沒有實際的泄漏，這只是Qt如何使用內存」。valgrind在Debian Wheezy在簡約應用程序中泄漏內存時是否捕獲Qt 4.8？

但是，我得到的基本上是空的應用程序看起來......更糟糕。我得到「肯定失去了」泄漏，例如：

的valgrind --tool = MEMCHECK --leak檢查= YES --show：

https://gist.github.com/3204769
==32147== LEAK SUMMARY: 
==32147== definitely lost: 848 bytes in 11 blocks 
==32147== indirectly lost: 1,756 bytes in 53 blocks 
==32147==  possibly lost: 1,720 bytes in 9 blocks 
==32147== still reachable: 121,019 bytes in 2,257 blocks 
==32147==   suppressed: 0 bytes in 0 blocks 
與運行-reachable = yes --num-callers = 20 --track-fds = yes ./testing 2> valgrind.log

我對這個設置有點出血，試圖獲得一個相對的近期C++ 11-GCC編譯：

Debian的喘息3.2.0-2-686-PAE
GCC（Debian的4.7.1-2）4.7.1

如果我做sudo kwrite --version我得到：

Qt: 4.8.1 
KDE Development Platform: 4.8.4 (4.8.4) 
KWrite: 4.8.3 (4.8.3)

任何人在類似的情況，或知道這是怎麼回事？： -/

來源

2012-07-30 HostileFork

沒有確切的警告，應該怎麼知道？ – 2012-07-30 06:47:38

@FrankOsterfeld在GitHub gist鏈接的最後一個文件中附加了精確的警告（除非你的意思是別的......？） – HostileFork 2012-07-30 13:08:36

啊，我滾動得快。看起來像靜態字體配置數據沒有被清除，沒有關鍵。 – 2012-07-30 14:16:01

大部分的東西似乎是你正在使用的庫的內部'全局'狀態。人們可以爭辯說，通過「程序終止」清理全球資源是否是一種很好的風格，但如果做得對，這很可能是正確的。我個人不喜歡它，因爲它使得檢測真正的泄漏更難...

來源

2012-07-30 09:35:14 sim82

valgrind在Debian Wheezy在簡約應用程序中泄漏內存時是否捕獲Qt 4.8？

回答

相關問題