2. 程式人生 > >valgrind報告5種記憶體洩露的研究

valgrind報告5種記憶體洩露的研究

阿新 • • 發佈：2019-01-28
[[email protected] valtest]# valgrind --tool=memcheck --leak-check=yes ./valtest 
==29240== Memcheck, a memory error detector
==29240== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==29240== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
==29240== Command: ./valtest
==29240== 
This program will create various memory leak,use valgrind to observe it.
Following functions are bad codes,don't imitate.
Fun1
Fun2
Fun3
Fun4
Fun5
==29240== Invalid write of size 4
==29240==    at 0x4007BE: Fun5() (main.cpp:73)
==29240==    by 0x40086E: main (main.cpp:93)
==29240==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==29240== 
==29240== 
==29240== Process terminating with default action of signal 11 (SIGSEGV)
==29240==  Access not within mapped region at address 0x0
==29240==    at 0x4007BE: Fun5() (main.cpp:73)
==29240==    by 0x40086E: main (main.cpp:93)
==29240==  If you believe this happened as a result of a stack
==29240==  overflow in your program's main thread (unlikely but
==29240==  possible), you can try to increase the size of the
==29240==  main thread stack using the --main-stacksize= flag.
==29240==  The main thread stack size used in this run was 10485760.
==29240== 
==29240== HEAP SUMMARY:
==29240==     in use at exit: 58 bytes in 6 blocks
==29240==   total heap usage: 6 allocs, 0 frees, 58 bytes allocated
==29240== 
==29240== 10 bytes in 1 blocks are possibly lost in loss record 2 of 6
==29240==    at 0x4A05E1C: malloc (vg_replace_malloc.c:195)
==29240==    by 0x4006D9: Fun3() (main.cpp:46)
==29240==    by 0x400850: main (main.cpp:89)
==29240== 
==29240== 10 bytes in 1 blocks are possibly lost in loss record 3 of 6
==29240==    at 0x4A05E1C: malloc (vg_replace_malloc.c:195)
==29240==    by 0x400795: Fun5() (main.cpp:66)
==29240==    by 0x40086E: main (main.cpp:93)
==29240== 
==29240== 10 bytes in 1 blocks are definitely lost in loss record 5 of 6
==29240==    at 0x4A05E1C: malloc (vg_replace_malloc.c:195)
==29240==    by 0x40072D: Fun1() (main.cpp:28)
==29240==    by 0x400832: main (main.cpp:85)
==29240== 
==29240== 18 (8 direct, 10 indirect) bytes in 1 blocks are definitely lost in loss record 6 of 6
==29240==    at 0x4A0666E: operator new(unsigned long) (vg_replace_malloc.c:220)
==29240==    by 0x4007F0: Fun4() (main.cpp:56)
==29240==    by 0x40085F: main (main.cpp:91)
==29240== 
==29240== LEAK SUMMARY:
==29240==    definitely lost: 18 bytes in 2 blocks
==29240==    indirectly lost: 10 bytes in 1 blocks
==29240==      possibly lost: 20 bytes in 2 blocks
==29240==    still reachable: 10 bytes in 1 blocks
==29240==         suppressed: 0 bytes in 0 blocks
==29240== Reachable blocks (those to which a pointer was found) are not shown.
==29240== To see them, rerun with: --leak-check=full --show-reachable=yes
==29240== 
==29240== For counts of detected and suppressed errors, rerun with: -v
==29240== ERROR SUMMARY: 5 errors from 5 contexts (suppressed: 4 from 4)
段錯誤

相關推薦

valgrind報告5種記憶體洩露的研究

[[email protected] valtest]# valgrind --tool=memcheck --leak-check=yes ./valtest  ==29240== Memcheck, a memory error detector ==29240== Copyright (C)

關於valgrind的安裝和記憶體洩露分析

程式的安裝 如果使用的是tar包安裝. valgrind# wget http://valgrind.org/downloads/valgrind-3.9.0.tar.bz2# tar -jxvf valgrind-3.9.0.tar.bz2# cd valgrind-3.

圖書銷售管理系統的可行性研究報告(5)

6投資及效益分析 6.1支出  6.1.1  基本建設投資 a、房屋和設施：￥700元（宿舍）； b、升級裝置：￥5000元； c、資料通訊裝置：￥100元； d、環境保護裝置：￥300元； e、安全與保密裝置：￥100元； f、升級作業系統的和應用的軟體：￥10

使用Valgrind找出Android中Native程式記憶體洩露問題

轉自 https://blog.csdn.net/roland_sun/article/details/46049485   Android程式通常使用Java程式編寫，由於Dalvik虛擬機器集成了垃圾回收機制，所以記憶體使用比較不容易出錯，通常就是一個本該被釋放的物件

使用Handler容易產生的記憶體洩露以及介紹下Java的4種引用

最近時間都利用的不太好，都是到下午才開始學習或者做事，一上午都吹B或者XXX用掉了。。。不太好，這裡督促下自己不要再懶惰，哈哈！！ 廢話不多說，今天來講下一個“經常”遇到的一個記憶體洩露的情況來引出想提的Java的4種引用方式 在舉例子之前先將一些基礎的知識，不然

在Linux中檢查可用記憶體的5種方法

作為Linux使用者，特別是管理員，我們需要檢查系統使用多少記憶體資源以及有多少記憶體資源是空閒的。我們還知道，通過Linux命令列而不是圖形使用者介面可以更好地實現大多數與管理相關的任務。例如，伺服器主要在shell上工作，並且首先沒有可用的UI。由於最重要的是要檢查伺服器上的記憶體資源，因此最好學習可以幫

linux下記憶體洩露檢測工具Valgrind介紹

一、工作中一個記憶體洩漏問題的解決過程： 問題背景：我司裝置上執行有多個程序，在裝置執行兩天後，程序jsman所佔用的記憶體達到了1200M bytes（通過ps -aux檢視）。 解決步驟： 確定裝置上的軟體版本，根據git的commit號資訊回退

android記憶體洩露深入研究

首先抄上百科 隱式記憶體洩漏：程式在執行過程中不停的分配記憶體，但是直到結束的時候才釋放記憶體。嚴格的說這裡並沒有發生記憶體洩漏，因為最終程式釋放了所有申請的記憶體。但是對於一個伺服器程式，需要執行幾天，幾周甚至幾個月，不及時釋放記憶體也可能導致最終耗盡系統的所有記憶體。所

Linux下利用Valgrind工具進行記憶體洩露檢測和效能分析

Valgrind通常用來成分析程式效能及程式中的記憶體洩露錯誤 一 Valgrind工具集簡紹 Valgrind包含下列工具：     1、memcheck：檢查程式中的記憶體問題，如洩漏、越界、非法指標等。     2、callgrind：檢測程式程式碼的執行

Linux下記憶體洩露工具Valgrind

Valgrind 安裝 1、 到www.valgrind.org下載最新版valgrind-3.2.3.tar.bz2 2、 解壓安裝包：tar –jxvf valgrind-3.2.3.tar.bz2 3、 解壓後生成目錄valgrind-3.2.3 4、 cd

Handler記憶體洩露的分析和解決辦法以及實現延時執行操作的幾種方法

一.Handler記憶體洩露的分析和解決辦法在進行非同步操作時，我們經常會使用到Handler類。最常見的寫法如下。public class MainActivity extends Activity

載入webView 記憶體洩露 導致記憶體暴漲的幾種解決方案

載入webView導致記憶體洩露的原因是：Html中的js程式碼會引起記憶體洩露 解決這個問題的方法是在webViewDidFinishLoad方法中設定如下： ***************    

防止記憶體洩露 Linux下用Valgrind做檢查

 用C/C++開發其中最令人頭疼的一個問題就是記憶體管理，有時候為了查詢一個記憶體洩漏或者一個記憶體訪問越界，需要要花上好幾天時間，如果有一款工具能夠幫助我們做這件事情就好了，valgrind正好就是這樣的一款工具。 Valgrind是一款基於模擬linux下的程式偵錯程式

【java記憶體洩漏5種情況總結】

記憶體洩漏定義：一個不再被程式使用的物件或變數還在記憶體中佔有儲存空間。由於java的JVM引入了垃圾回收機制，垃圾回收器會自動回收不再使用的物件，瞭解JVM回收機制的都知道JVM是使用引用計數法和可達性分析演算法來判斷物件是否是不再使用的物件，本質都是判斷一個物件是否還被引

（重要！）java中資料的5種儲存位置(堆與棧) 成員變數區域性變數記憶體分配

來源： java中資料的5種儲存位置(堆與棧) http://blog.csdn.net/ghost_programmer/article/details/40891735 http://www.cnblogs.com/newveg/p/6591435.html

Linux應用開發之使Valgrind防止記憶體洩露

用C/C++開發其中最令人頭疼的一個問題就是記憶體管理，有時候為了查詢一個記憶體洩漏或者一個記憶體訪問越界，需要要花上好幾天時間，如果有一款工具能夠幫助我們做這件事情就好了，valgrind正好就是這樣的一款工具。 Valgrind是一款基於模擬linux下的程式偵錯程式

arm linux下交叉編譯valgrind工具進行記憶體洩露檢測和效能分析

C/C++等底層語言在提供強大功能及效能的同時，其靈活的記憶體訪問也帶來了各種糾結的問題。如果crash的地方正是記憶體使用錯誤的地方，說明你人品好。如果crash的地方記憶體明顯不是consistent的，或者記憶體管理資訊都已被破壞，編譯器不能發現這些問題，.執行時才能捕獲到這些錯誤並且還是隨機出現的，那

java中記憶體洩露有幾種？如何分析洩露原因

一、Java記憶體回收機制 不論哪種語言的記憶體分配方式，都需要返回所分配記憶體的真實地址，也就是返回一個指標到記憶體塊的首地址。Java中物件是採用new或者反射的方法建立的，這些物件的建立都是在堆（Heap）中分配的，所有物件的回收都是由Java虛擬機器通過垃圾回收機制完成的。GC為了能夠正確釋放物件，

記憶體洩露檢測工具Valgrind

記憶體洩露簡介 什麼是記憶體洩漏 　　記憶體洩漏（Memory Leak）是指程式中已動態分配的堆記憶體由於某種原因，程式未釋放或無法釋放，造成系統記憶體的浪費，導致程式執行速度減慢甚至系統崩潰等嚴重後果。　　記憶體洩漏缺陷具有隱蔽性、積累性的特徵，比其他記憶體非法訪問錯誤更難檢測。因為記憶體洩漏的產生原

可能會導致.NET記憶體洩露的8種行為

原文連線：https://michaelscodingspot.com/ways-to-cause-memory-leaks-in-dotnet/作者 Michael Shpilt。授權翻譯，轉載請保留原文連結。 任何有經驗的.NET開發人員都知道，即使.NET應用程式具有垃圾回收器，記憶體洩漏始終會發生。