目的：總結linux程序記憶體洩漏導致crash的分析方法及解決過程
問題背景：插入usb裝置並配置啟動dlna功能，測試較長一段時間後會導致cpu和記憶體佔用率很高以致開發板crash，有ps下的程序狀態截圖和crash日誌
關鍵節點：
1.問題crash復現
2.在陌生的原始碼中尋找突破口
3.分析日誌
4.分析主程序及子程序**
分析過程：
節點1——
節點2——
原始碼檔案那麼多怎麼找突破口，一般是從主程序入手。由於該功能啟動時會用到乙個重要引數，即對應的目錄路徑path，開始研究程序如何使用該引數，發現乙個重要子程序scan，會迭代掃瞄path路徑下所有的目錄和檔案並寫入資料庫db檔案，檔案越多掃瞄程序持續時間越長（可超過1個小時），top觀察記憶體和cpu使用率佔比很高，一段時間後即crash，由於記憶體耗盡導致voice需要大量申請記憶體失敗最終crash。開始懷疑是迭代掃瞄導致大量記憶體未及時釋放所致。
節點3——
節點4——
回到主程序整體分析，無論前面如何除錯，記憶體總是消耗很大沒有變好趨勢，到底在什麼地方會消耗很大記憶體呢？於是在主程序中去掉兩個子程序，果然記憶體消耗很小。根據前面的除錯，scan程序中沒有記憶體洩漏，scan程序和inotify程序均採用pthread_create方式建立，scan掃瞄結束後程序也會結束，inotify程序則一直生存。上網查詢發現pthread_create方式使用不當會導致大量記憶體洩漏，缺省會消耗2-8m左右記憶體（可調整），根據網上眾多的解決方法調整不起效果，不知緣何。於是想到可不可以將scan和inotify整合到乙個程序中，或者採用fork方式來取代pthread_create方式調整scan程序，採用後一種方式調整測試，功能正常，不會crash和卡死現象，效果有改觀，記憶體占用比降低明顯，掃瞄結束後趨於穩定。
Linux程序記憶體分析和記憶體洩漏定位
在linux產品開發過程中，通常需要注意系統記憶體使用量，和評估單一程序的記憶體使用情況，便於我們選取合適的機器配置，來部署我們的產品。linux本身提供了一些工具方便我們達成這些需求，檢視程序實時資源top工具，更詳細的程序記憶體堆疊情況，pmap工具，linux程序執行時狀態資訊也會儲存在pro...
QT之記憶體洩漏
以入門的hello world 為例 我們將 main.cpp 修改如下 include include intmain int argc,char ar 示例程式我們已經講解完畢。下面再說一點。我們可以將上面的程式改寫成下面的 嗎？include include intmain int argc,...
C 之記憶體洩漏篇
前段時間面試經常被問到記憶體洩漏。今天小總結一下 記憶體洩漏的發生是由於使用者在堆上分配了空間，但卻沒有釋放它。持續的記憶體洩漏最終將導致堆的耗盡，後繼的記憶體分配將會失敗。引發記憶體洩漏的原因是用new分配的記憶體沒有用delete釋放掉。如 可能在onpaint這樣的繪畫視窗的函式中分配了空間，...