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

2022-07-01 12:01:15

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