一个内存增长问题的分析和处理(二)——valgrind工具的用法

简介:

valgrind是linux下对C++和C程序进行内存泄露检测的工具,除了内存检测,valgrind还提供了很多其他的功能,这里主要介绍下valgrind的内存检测的功能。

  首先是文件的下载,valgrind的官方网址是http://valgrind.org/,最新版本的valgrind是3.9,下载地址如下:http://valgrind.org/downloads/。下载好的文件是tar.bz2格式的文件——valgrind-3.9.0.tar.bz2,linux下可以使用tar命令对压缩包进行解压,命令如下:

  

1
tar jxf valgrind-3.9.0.tar.bz2

  解压后,需要对软件进行编译安装,进入解压目录,执行配置命令

1
./configure

  可以指定路径安装,使用 --prefix + 路径 ,默认的安装路径为/usr/local/bin,如果指定了安装路径,后续需要把valgrind的安装路径配置到PATH环境变量中,接下来是编译安装,执行下面的命令

1
make install

  如果执行命令时发现没有权限创建目录,可以使用管理员权限执行,Ubuntu下使用sudo命令即可,安装完成,执行valgrind --version,如果有版本信息出现,就安装成功,否则是安装失败。

1
2
3
mengpl@mengpl- virtual -machine:/usr/local$ valgrind --version
valgrind-3.9.0
mengpl@mengpl- virtual -machine:/usr/local$

  安装过程中,还遇到另外一个问题

1
2
3
4
5
6
7
8
9
valgrind --leak-check=yes ls -l
==7674== Memcheck, a memory error detector
==7674== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==7674== Using Valgrind-3.8.1 and LibVEX; rerun with -h  for  copyright info
==7674== Command: ls -l
==7674==
 
valgrind:  Fatal error at startup: a function redirection
valgrind:  which is mandatory  for  this  platform-tool combination

  此时需要安装libc6-dbg库,Ubuntu下的安装命令为:

1
sudo apt-get install libc6-dbg

  正常使用valgrind检测内存的输出如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
mengpl@mengpl- virtual -machine:/usr/local$ valgrind --leak-check=yes ls
==8260== Memcheck, a memory error detector
==8260== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==8260== Using Valgrind-3.9.0 and LibVEX; rerun with -h  for  copyright info
==8260== Command: ls
==8260==
bin  etc  games  include  lib  man  sbin  share  src
==8260==
==8260== HEAP SUMMARY:
==8260==     in use at  exit : 21,373 bytes in 15 blocks
==8260==   total heap usage: 50 allocs, 35 frees, 58,571 bytes allocated
==8260==
==8260== LEAK SUMMARY:
==8260==    definitely lost: 0 bytes in 0 blocks
==8260==    indirectly lost: 0 bytes in 0 blocks
==8260==      possibly lost: 0 bytes in 0 blocks
==8260==    still reachable: 21,373 bytes in 15 blocks
==8260==         suppressed: 0 bytes in 0 blocks
==8260== Reachable blocks (those to which a pointer was found) are not shown.
==8260== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==8260==
==8260== For counts of detected and suppressed errors, rerun with: -v
==8260== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2)

  使用valgrind对程序进行分析,主要的使用就是内存泄露的分析,也是valgrind默认的工具,valgrind的具体用法,请看man手册,我这里只介绍一种用法,一条命令

1
valgrind --leak-check=full --show-leak-kinds=all -v

  这个命令 + 需要测试的程序,就可以输出一套valgrind的统计报告,下面我重点介绍下对于报告的分析,由于我这个程序比较复杂,里面执行到了很多的内容,我把程序的最终内容进行了归类,主要分为四部分的内容:

  1)内存泄露统计

1
2
3
4
5
6
==6622== LEAK SUMMARY:
==6622==    definitely lost: 1,636 bytes in 9 blocks
==6622==    indirectly lost: 9,421 bytes in 92 blocks
==6622==      possibly lost: 186,418 bytes in 840 blocks
==6622==    still reachable: 728,283 bytes in 1,917 blocks
==6622==         suppressed: 0 bytes in 0 blocks

  2、错误统计

1
ERROR SUMMARY: 3465 errors from 1182 contexts (suppressed: 2 from 2)

  3、内存泄露明细

1
2
3
4
5
6
7
8
9
10
11
12
13
==6622== 152 bytes in 19 blocks are indirectly lost in loss record 1,814 of 1,979
==6622==    at 0x4C2C857:  malloc  (vg_replace_malloc.c:291)
==6622==    by 0x7614CDB: link_nfa_nodes (regex_internal.c:1000)
==6622==    by 0x761D115: re_compile_internal (regcomp.c:1227)
==6622==    by 0x7620E7E: regcomp (regcomp.c:506)
==6622==    by 0xCE694B5: sal::routecfg::CalRouteHId( long  long int &) (routesalcfg_info.cpp:555)
==6622==    by 0xFC15A46: MRoute::CalcHorIdByMajorDim( long  long ) (route_common.cpp:141)
==6622==    by 0xFC38736: MRoute::CIRouteImp::query_routeByStr(SOBSession*,  short  const &, std::string  const &, std::string  const &, MRouteDef::SRouteInfo&, CBSErrorMsg&) (route_inf_sdl_i.cpp:411)
==6622==    by 0xFC40E59: MRoute::SearchDbRouteSync(std::string  const &, MRouteDef::SRouteInfo&) (route_interface.cpp:10)
==6622==    by 0xFC48D0D: MRoute::search_routing_info(lua_State*) (route_lua_api.cpp:58)
==6622==    by 0xA3899E5: luaD_precall (ldo.cpp:320)
==6622==    by 0xA389C9D: luaD_call (ldo.cpp:377)
==6622==    by 0xA37F1AF: f_call(lua_State*,  void *) (lapi.cpp:800)

  4、错误明细

1
2
3
4
5
6
7
8
9
10
11
12
13
==6622== Use of uninitialised value of size 8
==6622==    at 0x9643FD8: ztcedecb (in /opt/oracle/product/10.2.0/client_1/lib/libclntsh.so.11.1)
==6622==    by 0x96439C1: ztcedencbk (in /opt/oracle/product/10.2.0/client_1/lib/libclntsh.so.11.1)
==6622==    by 0x9643126: ztcebn (in /opt/oracle/product/10.2.0/client_1/lib/libclntsh.so.11.1)
==6622==    by 0x9642C46: ztcen (in /opt/oracle/product/10.2.0/client_1/lib/libclntsh.so.11.1)
==6622==    by 0x7DDE0C8: ztceenc (in /opt/oracle/product/10.2.0/client_1/lib/libclntsh.so.11.1)
==6622==    by 0x7E91769: ztcrbm (in /opt/oracle/product/10.2.0/client_1/lib/libclntsh.so.11.1)
==6622==    by 0x7E912F3: ztcrbh (in /opt/oracle/product/10.2.0/client_1/lib/libclntsh.so.11.1)
==6622==    by 0x7E911B5: ztcrbp (in /opt/oracle/product/10.2.0/client_1/lib/libclntsh.so.11.1)
==6622==    by 0x7E910BE: ztcr2seed (in /opt/oracle/product/10.2.0/client_1/lib/libclntsh.so.11.1)
==6622==    by 0x7E91081: ztcrseed3 (in /opt/oracle/product/10.2.0/client_1/lib/libclntsh.so.11.1)
==6622==    by 0x7DDECC7: ztcsh (in /opt/oracle/product/10.2.0/client_1/lib/libclntsh.so.11.1)
==6622==    by 0x7D35A08: kpusattr (in /opt/oracle/product/10.2.0/client_1/lib/libclntsh.so.11.1)

  首先要对统计信息进行分析,分为四类信息,我们来看下官方对于这四类的解释:

  1、"definitely lost" means your program is leaking memory -- fix those leaks

    这就是内存泄露,需要修改

  2、"indirectly lost" means your program is leaking memory in a pointer-based structure. (E.g. if the root node of a binary tree is "definitely lost", all the children will be "indirectly lost".) If you fix the "definitely lost" leaks, the "indirectly lost" leaks should go away.

    这个意思就是说,泄露的内存是一个指针,也就是我们平常讲的野指针的问题

  3、"still reachable" means your program is probably ok -- it didn’t free some memory it could have. This is quite common and often reasonable. Don’t use --show-reachable=yes if you don’t want to see these reports.

    你的程序可能是好的,意思是,在程序没有结束之前,这部分内存一直都没有释放

  4、"suppressed" means that a leak error has been suppressed. There are some suppressions in the default suppression files. You can ignore suppressed errors.

    这个可以直接忽略

  内存泄露的明细中,会表示出来每一个可能存在内存泄露的地方,可以逐个进行分析,当遇到情况比较多的情况,可以对这些进行分类,在具体分析代码。

  错误明细中,也会存在几种情况,我例子中提到的Use of uninitialised value of size 8 内存没有初始化等。具体的valgrind的用法,推荐一篇文件

https://www.ibm.com/developerworks/cn/linux/l-cn-valgrind/

  这里面介绍的非常详细和周到。

  关于内存增长的问题,还没有定位到具体的位置,后续如果定位到,会把结果补充上来。

目录
相关文章
|
13天前
|
Web App开发 监控 JavaScript
监控和分析 JavaScript 内存使用情况
【10月更文挑战第30天】通过使用上述的浏览器开发者工具、性能分析工具和内存泄漏检测工具,可以有效地监控和分析JavaScript内存使用情况,及时发现和解决内存泄漏、过度内存消耗等问题,从而提高JavaScript应用程序的性能和稳定性。在实际开发中,可以根据具体的需求和场景选择合适的工具和方法来进行内存监控和分析。
|
1月前
|
编译器 C语言
动态内存分配与管理详解(附加笔试题分析)(上)
动态内存分配与管理详解(附加笔试题分析)
49 1
|
2月前
|
程序员 编译器 C++
【C++核心】C++内存分区模型分析
这篇文章详细解释了C++程序执行时内存的四个区域:代码区、全局区、栈区和堆区,以及如何在这些区域中分配和释放内存。
51 2
|
8天前
|
开发框架 监控 .NET
【Azure App Service】部署在App Service上的.NET应用内存消耗不能超过2GB的情况分析
x64 dotnet runtime is not installed on the app service by default. Since we had the app service running in x64, it was proxying the request to a 32 bit dotnet process which was throwing an OutOfMemoryException with requests >100MB. It worked on the IaaS servers because we had the x64 runtime install
|
18天前
|
Web App开发 JavaScript 前端开发
使用 Chrome 浏览器的内存分析工具来检测 JavaScript 中的内存泄漏
【10月更文挑战第25天】利用 Chrome 浏览器的内存分析工具,可以较为准确地检测 JavaScript 中的内存泄漏问题,并帮助我们找出潜在的泄漏点,以便采取相应的解决措施。
127 9
|
22天前
|
并行计算 算法 IDE
【灵码助力Cuda算法分析】分析共享内存的矩阵乘法优化
本文介绍了如何利用通义灵码在Visual Studio 2022中对基于CUDA的共享内存矩阵乘法优化代码进行深入分析。文章从整体程序结构入手,逐步深入到线程调度、矩阵分块、循环展开等关键细节,最后通过带入具体值的方式进一步解析复杂循环逻辑,展示了通义灵码在辅助理解和优化CUDA编程中的强大功能。
|
1月前
|
存储 监控 算法
JVM调优深度剖析:内存模型、垃圾收集、工具与实战
【10月更文挑战第9天】在Java开发领域,Java虚拟机(JVM)的性能调优是构建高性能、高并发系统不可或缺的一部分。作为一名资深架构师,深入理解JVM的内存模型、垃圾收集机制、调优工具及其实现原理,对于提升系统的整体性能和稳定性至关重要。本文将深入探讨这些内容,并提供针对单机几十万并发系统的JVM调优策略和Java代码示例。
49 2
|
1月前
|
程序员 编译器 C语言
动态内存分配与管理详解(附加笔试题分析)(下)
动态内存分配与管理详解(附加笔试题分析)(下)
46 2
|
1月前
|
SQL 安全 算法
ChatGPT高效提问—prompt实践(漏洞风险分析-重构建议-识别内存泄漏)
ChatGPT高效提问—prompt实践(漏洞风险分析-重构建议-识别内存泄漏)
|
3月前
|
存储 编译器 C语言
【C语言篇】数据在内存中的存储(超详细)
浮点数就采⽤下⾯的规则表⽰,即指数E的真实值加上127(或1023),再将有效数字M去掉整数部分的1。
370 0