内存泄漏定位工具之 valgrind 使用

1 前言

前面介绍了 GCC 自带的 mtrace 内存泄漏检查工具，该篇主要介绍开源的内存泄漏工具 valgrind，valgrind 是一套 Linux 下，开放源代码的动态调试工具集合，能够检测内存管理错误、线程 BUG 等，valgrind 由内核（core）以及基于内核的其他调试工具组成。内核类似于一个框架（framework），它模拟了一个 CPU 环境，并提供服务给其他工具；而其他工具则类似于插件 (plug-in)，利用内核提供的服务完成各种特定的内存调试任务。

该篇主要是介绍 valgrind 在联咏 NT98X 系列芯片的 ARM 平台上的编译使用及在使用过程中遇到的问题。

1.1 介绍

valgrind 包括的工具如下：

memcheck，这是valgrind应用最广泛的工具，一个重量级的内存检查器，能够发现开发中绝大多数内存错误使用情况，比如：使用未初始化的内存，使用已经释放了的内存，内存访问越界等。
callgrind，主要用来检查程序中函数调用过程中出现的问题。
cachegrind，主要用来检查程序中缓存使用出现的问题。
helgrind，主要用来检查多线程程序中出现的竞争问题。
massif，主要用来检查程序中堆栈使用中出现的问题。
extension，可以利用core提供的功能，自己编写特定的内存调试工具。

2 编译

2.1 前期准备

1、下载 valgrind (//www.valgrind.org/downloads/)

wget //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

解决方案有两种：

按照上述编译期间环境配置中的 –prefix 的路径保证目标板上的路径一致，如果不确定可以打开 valgrind//lib/pkgconfig/valgrind.pc 文件查看，第一行的 prefix= 为编译安装后的路径

在目标板上设置 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

Tags: 内存泄漏嵌入式 Linux 开发经验

内存泄漏定位工具之 valgrind 使用

1 前言

1.1 介绍

2 编译

2.1 前期准备

2.2 环境配置

3 使用

3.1 前期准备

3.2 执行

4 常见问题

4.1 编译配置期间的常见问题

4.2 使用期间的常见问题

VirMach 便宜 VPS

QNews

内存泄漏定位工具之 valgrind 使用

1 前言

1.1 介绍

2 编译

2.1 前期准备

2.2 环境配置

3 使用

3.1 前期准备

3.2 执行

4 常见问题

4.1 编译配置期间的常见问题

4.2 使用期间的常见问题

分享此文：

Related Posts

keycloak集群化的思考

CornerNet: 成对关键点物体检测 | CSDN博文精选

编译调试Net6源码

小米高端路由器年度新品官宣：轻松覆盖全屋 告别死角

VirMach 便宜 VPS

QNews

热门搜寻

小米高端路由器年度新品官宣：轻松覆盖全屋告别死角