記憶體洩漏定位工具之 valgrind 使用

大橙子瘋發表於2022-07-01
記憶體

1 前言

        前面介紹了 GCC 自帶的 mtrace 記憶體洩漏檢查工具，該篇主要介紹開源的記憶體洩漏工具 valgrind，valgrind 是一套 Linux 下，開放原始碼的動態除錯工具集合，能夠檢測記憶體管理錯誤、執行緒 BUG 等，valgrind 由核心（core）以及基於核心的其他除錯工具組成。核心類似於一個框架（framework），它模擬了一個 CPU 環境，並提供服務給其他工具；而其他工具則類似於外掛 (plug-in)，利用核心提供的服務完成各種特定的記憶體除錯任務。

        該篇主要是介紹 valgrind 在聯詠 NT98X 系列晶片的 ARM 平臺上的編譯使用及在使用過程中遇到的問題。

1.1 介紹

valgrind 包括的工具如下：

  1. memcheck，這是valgrind應用最廣泛的工具，一個重量級的記憶體檢查器，能夠發現開發中絕大多數記憶體錯誤使用情況，比如：使用未初始化的記憶體，使用已經釋放了的記憶體，記憶體訪問越界等。
  2. callgrind，主要用來檢查程式中函式呼叫過程中出現的問題。
  3. cachegrind，主要用來檢查程式中快取使用出現的問題。
  4. helgrind，主要用來檢查多執行緒程式中出現的競爭問題。
  5. massif，主要用來檢查程式中堆疊使用中出現的問題。
  6. extension，可以利用core提供的功能，自己編寫特定的記憶體除錯工具。

2 編譯

2.1 前期準備

1、下載 valgrind (https://www.valgrind.org/downloads/)

wget http://valgrind.org/downloads/valgrind-3.12.0.tar.bz2

2、解壓縮，輸入指令解壓

 tar -jxvf valgrind-3.12.0.tar.bz2

3、進入解壓後的目錄中

cd valgrind-3.12.0

4、執行指令碼

./autogen.sh

2.2 環境配置

執行指令碼完成後，需要先修改 configure 指令碼，將 armv7*)  改為 armv7* | arm )，然後按照下面執行（根據自己的交叉編譯環境修改）

./configure --host=arm-ca9-linux-gnueabihf CC=arm-ca9-linux-gnueabihf-gcc CPP=arm-ca9-linux-gnueabihf-cpp CXX=arm-ca9-linux-gnueabihf-g++ --prefix=/mnt/valgrind

其中 --prefix 設定的編譯生成後的路徑要保證在目標板上的路徑一致，否則在實際使用時會報錯，當然如果條件不允許的話，在使用前可以設定 valgrind 的環境變數解決，具體在“遇到的問題”章節中會提及。

make -j;make install

會在 --prefix 指定的目錄下生成四個子目錄：bin、include、lib 和 share，我們需要的 valgrind 就在其中的bin目錄下。

3 使用

3.1 前期準備

        可以選擇通過拷貝或者掛載的方式，但是不管哪一種，都需要將bin、include、lib 和 share 放置在 /mnt/valgrind 下（上面我設定 --prefix 的路徑是 /mnt/valgrind），比如我通過掛載的方式（我已經將 /mnt/valgrind 的 bin、include 和 lib 資料夾拷貝到 /home/const/workspace/valgrind）

mount -t nfs -o nolock,tcp 192.168.1.100:/home/const/workspace/valgrind /mnt/valgrind

3.2 執行

可輸入以下指令測試 valgrind 是否可以正常執行，如果出現一大堆選項解釋，則表示成功

/mnt/valgrind/bin/valgrind --help

通過檢查記憶體洩漏的問題使用（./sample為可執行程式名）：

/mnt/valgrind/bin/valgrind --error-limit=no --leak-check=full --tool=memcheck ./sample

4 常見問題

4.1 編譯配置期間的常見問題

1、配置 configure 時遇到類似以下問題，解決方案請參考上述中編譯期間的“環境配置”，修改 configure 檔案儲存。

checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for arm-ca9-linux-gnueabihf-strip... no
checking for strip... strip
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking whether ln -s works... yes
checking for arm-ca9-linux-gnueabihf-gcc... /opt/arm-ca9-linux-gnueabihf-6.5/bin/arm-ca9-linux-gnueabihf-gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... yes
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether /opt/arm-ca9-linux-gnueabihf-6.5/bin/arm-ca9-linux-gnueabihf-gcc accepts -g... yes
checking for /opt/arm-ca9-linux-gnueabihf-6.5/bin/arm-ca9-linux-gnueabihf-gcc option to accept ISO C89... none needed
checking whether /opt/arm-ca9-linux-gnueabihf-6.5/bin/arm-ca9-linux-gnueabihf-gcc understands -c and -o together... yes
checking for style of include used by make... GNU
checking dependency style of /opt/arm-ca9-linux-gnueabihf-6.5/bin/arm-ca9-linux-gnueabihf-gcc... gcc3
checking how to run the C preprocessor... /opt/arm-ca9-linux-gnueabihf-6.5/bin/arm-ca9-linux-gnueabihf-cpp
checking whether we are using the GNU C++ compiler... yes
checking whether /opt/arm-ca9-linux-gnueabihf-6.5/bin/arm-ca9-linux-gnueabihf-g++ accepts -g... yes
checking dependency style of /opt/arm-ca9-linux-gnueabihf-6.5/bin/arm-ca9-linux-gnueabihf-g++... gcc3
checking for arm-ca9-linux-gnueabihf-ranlib... no
checking for ranlib... ranlib
configure: WARNING: using cross tools not prefixed with host triplet
checking for a sed that does not truncate output... /bin/sed
checking for ar... /usr/bin/ar
checking for perl... /usr/bin/perl
checking for gdb... /usr/bin/gdb
checking dependency style of /opt/arm-ca9-linux-gnueabihf-6.5/bin/arm-ca9-linux-gnueabihf-gcc... gcc3
checking for diff -u... yes
checking for a supported version of gcc... ok (6.5.0)
checking build system type... x86_64-unknown-linux-gnu
checking host system type... arm-ca9-linux-gnueabihf
checking for a supported CPU... no (arm)
configure: error: Unsupported host architecture. Sorry

2、配置 configure 時遇到類似以下問題，原因是交叉編譯工具鏈在環境中沒有新增，checking 找不到對應路徑的工具鏈

checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for arm-ca9-linux-gnueabihf-strip... no
checking for strip... strip
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking whether ln -s works... yes
checking for arm-ca9-linux-gnueabihf-gcc... arm-ca9-linux-gnueabihf-gcc
checking whether the C compiler works... no
configure: error: in `/home/const/workspace/Download/valgrind-3.12.0':
configure: error: C compiler cannot create executables
See `config.log' for more details

解決方案：除了--host 外，其他都需要絕對路徑（根據自己的交叉編譯鏈工具路徑修改）：

./configure --host=arm-ca9-linux-gnueabihf CC=/opt/arm-ca9-linux-gnueabihf-6.5/bin/arm-ca9-linux-gnueabihf-gcc CPP=/opt/arm-ca9-linux-gnueabihf-6.5/bin/arm-ca9-linux-gnueabihf-cpp CXX=/opt/arm-ca9-linux-gnueabihf-6.5/bin/arm-ca9-linux-gnueabihf-g++ --prefix=/mnt/valgrind

4.2 使用期間的常見問題

1、測試 valgrind 或者使用時，出現以下錯誤，其原因是沒有找到 valgrind 的 lib 庫（不要試圖修改 LD_LIBRARY_PATH，沒有用）。

valgrind: failed to start tool 'memcheck' for platform 'arm-linux': No such file or directory

解決方案有兩種：

  1. 按照上述編譯期間環境配置中的 --prefix 的路徑保證目標板上的路徑一致，如果不確定可以開啟 valgrind//lib/pkgconfig/valgrind.pc 檔案檢視，第一行的 prefix= 為編譯安裝後的路徑
  2. 在目標板上設定 valgrind 的環境變數：export VALGRIND_LIB=/mnt/valgrind/lib/valgrind（根據自己存放的 valgrind 路徑修改）

2、使用時出現 ld-linux-armhf.so.3 的錯誤，原因是目標板上的 ld-2.29.so（ld-linux-armhf.so.3是 ld-2.29.so 的軟連結）是被 stripped 後的。

# /mnt/valgrind/bin/valgrind --error-limit=no --leak-check=full --tool=memcheck /usr/local/bin/sample
==701== Memcheck, a memory error detector
==701== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==701== Using Valgrind-3.12.0 and LibVEX; rerun with -h for copyright info
==701== Command: /usr/local/bin/sample
==701== 

valgrind:  Fatal error at startup: a function redirection
valgrind:  which is mandatory for this platform-tool combination
valgrind:  cannot be set up.  Details of the redirection are:
valgrind:  
valgrind:  A must-be-redirected function
valgrind:  whose name matches the pattern:      strcmp
valgrind:  in an object with soname matching:   ld-linux-armhf.so.3
valgrind:  was not found whilst processing
valgrind:  symbols from the object with soname: ld-linux-armhf.so.3
valgrind:  
valgrind:  Possible fixes: (1, short term): install glibc's debuginfo
valgrind:  package on this machine.  (2, longer term): ask the packagers
valgrind:  for your Linux distribution to please in future ship a non-
valgrind:  stripped ld.so (or whatever the dynamic linker .so is called)
valgrind:  that exports the above-named function using the standard
valgrind:  calling conventions for this platform.  The package you need
valgrind:  to install for fix (1) is called
valgrind:  
valgrind:    On Debian, Ubuntu:                 libc6-dbg
valgrind:    On SuSE, openSuSE, Fedora, RHEL:   glibc-debuginfo
valgrind:  
valgrind:  Note that if you are debugging a 32 bit process on a
valgrind:  64 bit system, you will need a corresponding 32 bit debuginfo
valgrind:  package (e.g. libc6-dbg:i386).
valgrind:  
valgrind:  Cannot continue -- exiting now.  Sorry.

        關於這個問題，網上有很多都說用 not stripped 的 ld-2.29.so 替換目標板上 /lib/ld-2.29.so ，解決方法簡單，但是依舊困擾了我幾天時間，因為我使用的是目標板是隻讀檔案系統（不要問我為啥不設定成可讀寫的，因為工作內容限制），不能修改 /lib 的內容導致無法被替換，因此下面的方式是通過指定路徑的 ld-2.29.so 來解決該問題，不要試圖用環境變數 LD_PRELOAD 去優先選擇 ld-2.29.so 或者 ld-linux-armhf.so.3 來執行，沒有任何意義（因為 ld-2.29.so 不是一個普通的動態庫，它是會使用環境變數 LD_PRELOAD，可以百度搜它們之間的關係）。

        在這幾天中，試了很多方式，由於一開始的定位問題的思路錯了，導致後面一直沒有成功（以為只要用 not stripped 的 ld-2.29.so 去執行 valgrind 就可以了，自從解決後，回頭看想想其實從之前的 valgrind --help 成功後表示 valgrind 已經是可以正常使用的了 ），而本質的問題是被檢測的可執行程式才是需要被 not stripped 的 ld-2.29.so 去執行。

        通過 readelf 檢視可執行檔案的 ELF 資訊，可以看到動態庫載入器 interpreter 為 /lib/ld-linux-armhf.so.3，表示該執行程式使用的是 /lib 路徑下的

ld-linux-armhf.so.3（/lib/ld-2.29.so 的軟連線），那現在解決問題的思路清晰了，只要改變它就可以了。

const@const-virtual-machine:~/workspace/valgrind/bin$ readelf -l sample                                                              
Elf 檔案型別為 EXEC (可執行檔案)
Entry point 0x12d18
There are 10 program headers, starting at offset 52

程式頭：
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  PHDR           0x000034 0x0000f034 0x0000f034 0x00140 0x00140 R   0x4
  GNU_STACK      0x001000 0x00000000 0x00000000 0x00000 0x00000 RW  0x10
  LOAD           0x000000 0x0000f000 0x0000f000 0x01000 0x01000 RW  0x1000
  INTERP         0x000174 0x0000f174 0x0000f174 0x00031 0x00031 R   0x1
      [Requesting program interpreter: /lib/ld-linux-armhf.so.3]
  LOAD           0x001000 0x00010000 0x00010000 0x08148 0x08148 R E 0x1000
  NOTE           0x001170 0x00010170 0x00010170 0x00020 0x00020 R   0x4
  EXIDX          0x008eac 0x00017eac 0x00017eac 0x00298 0x00298 R   0x4
  LOAD           0x009e70 0x00028e70 0x00028e70 0x002d4 0x002e4 RW  0x1000
  GNU_RELRO      0x009e70 0x00028e70 0x00028e70 0x00190 0x00190 R   0x1
  DYNAMIC        0x009ed8 0x00028ed8 0x00028ed8 0x00128 0x00128 RW  0x4

首先我們需要找到 not stripped 的 ld-2.29.so，一般在交叉編譯工具鏈裡的 target/lib 能夠找到，通過以下指令可以確定

const@const-virtual-machine:/$ file /opt/arm-ca9-linux-gnueabihf-6.5/target/lib/ld-2.29.so 
/opt/arm-ca9-linux-gnueabihf-6.5/target/lib/ld-2.29.so: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, not stripped

比如我將這個 target 中的 lib 資料夾拷貝到掛載的指定目錄下（目標板的路徑則是 /mnt/valgrind/lib/target/lib）

cp -rf /opt/arm-ca9-linux-gnueabihf-6.5/target/lib /home/const/workspace/valgrind/target/lib/

解決方案有三種：

1、在編譯期間，通過編譯選項指定使用對應路徑下的 ld-linux-armhf.so.3（是 ld-2.29.so 的軟連線）進行編譯，再通過 readelf 讀取確認

LDFLAGS+=-Wl,--dynamic-linker='/mnt/valgrind/lib/target/lib/ld-linux-armhf.so.3'

2、通過 patchelf 修改編譯後的可執行檔案，再通過 readelf 讀取確認

const@const-virtual-machine:~/worksapce/bin$ patchelf --set-interpreter /mnt/valgrind/lib/target/lib/ld-linux-armhf.so.3 sample 
const@const-virtual-machine:~/worksapce/bin$ readelf -l sample 

Elf 檔案型別為 EXEC (可執行檔案)
Entry point 0x12d18
There are 10 program headers, starting at offset 52

程式頭：
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  PHDR           0x000034 0x0000f034 0x0000f034 0x00140 0x00140 R   0x4
  GNU_STACK      0x001000 0x00000000 0x00000000 0x00000 0x00000 RW  0x10
  LOAD           0x000000 0x0000f000 0x0000f000 0x01000 0x01000 RW  0x1000
  INTERP         0x000174 0x0000f174 0x0000f174 0x00031 0x00031 R   0x1
      [Requesting program interpreter: /mnt/valgrind/lib/target/lib/ld-linux-armhf.so.3]
  LOAD           0x001000 0x00010000 0x00010000 0x08148 0x08148 R E 0x1000
  NOTE           0x001170 0x00010170 0x00010170 0x00020 0x00020 R   0x4
  EXIDX          0x008eac 0x00017eac 0x00017eac 0x00298 0x00298 R   0x4
  LOAD           0x009e70 0x00028e70 0x00028e70 0x002d4 0x002e4 RW  0x1000
  GNU_RELRO      0x009e70 0x00028e70 0x00028e70 0x00190 0x00190 R   0x1
  DYNAMIC        0x009ed8 0x00028ed8 0x00028ed8 0x00128 0x00128 RW  0x4

3、不需要修改編譯選項，也不需要修改可執行檔案，在目標板直接輸入以下指令即可

/mnt/valgrind/bin/valgrind --error-limit=no --leak-check=full --tool=memcheck /mnt/valgrind/lib/target/lib/ld-linux-armhf.so.3  /usr/local/bin/sample

 

相關文章