精华内容
下载资源
问答
  • Valgrind Massif valgrind 是什么,这里直接引用其他人的博客: Valgrind是一套Linux下,开放源代码(GPL V2)的仿真调试工具的集合。Valgrind由内核(core)以及基于内核的其他调试工具组成。 内核类似于一个...

    旧博文,搬到 csdn
    原文:http://rebootcat.com/2020/06/16/valgrind_massif_memory_analysing/

    Valgrind Massif

    valgrind 是什么,这里直接引用其他人的博客:

    Valgrind是一套Linux下,开放源代码(GPL
    V2)的仿真调试工具的集合。Valgrind由内核(core)以及基于内核的其他调试工具组成。

    内核类似于一个框架(framework),它模拟了一个CPU环境,并提供服务给其他工具;而其他工具则类似于插件 (plug-in),利用内核提供的服务完成各种特定的内存调试任务。

    Valgrind的体系结构如下图所示:

    Massif 命令行选项

    关于 massif 命令行选项,可以直接查看 valgrind 的 help 信息:

    
    MASSIF OPTIONS
           --heap=<yes|no> [default: yes]
               Specifies whether heap profiling should be done.
    
           --heap-admin=<size> [default: 8]
               If heap profiling is enabled, gives the number of administrative bytes per block to use. This should be an estimate of the average, since it may vary. For example, the
               allocator used by glibc on Linux requires somewhere between 4 to 15 bytes per block, depending on various factors. That allocator also requires admin space for freed blocks,
               but Massif cannot account for this.
    
           --stacks=<yes|no> [default: no]
               Specifies whether stack profiling should be done. This option slows Massif down greatly, and so is off by default. Note that Massif assumes that the main stack has size zero
               at start-up. This is not true, but doing otherwise accurately is difficult. Furthermore, starting at zero better indicates the size of the part of the main stack that a user
               program actually has control over.
    
           --pages-as-heap=<yes|no> [default: no]
               Tells Massif to profile memory at the page level rather than at the malloc'd block level. See above for details.
    
           --depth=<number> [default: 30]
               Maximum depth of the allocation trees recorded for detailed snapshots. Increasing it will make Massif run somewhat more slowly, use more memory, and produce bigger output
               files.
    
           --alloc-fn=<name>
               Functions specified with this option will be treated as though they were a heap allocation function such as malloc. This is useful for functions that are wrappers to malloc or
               new, which can fill up the allocation trees with uninteresting information. This option can be specified multiple times on the command line, to name multiple functions.
    
               Note that the named function will only be treated this way if it is the top entry in a stack trace, or just below another function treated this way. For example, if you have a
               function malloc1 that wraps malloc, and malloc2 that wraps malloc1, just specifying --alloc-fn=malloc2 will have no effect. You need to specify --alloc-fn=malloc1 as well.
               This is a little inconvenient, but the reason is that checking for allocation functions is slow, and it saves a lot of time if Massif can stop looking through the stack trace
               entries as soon as it finds one that doesn't match rather than having to continue through all the entries.
    
               Note that C++ names are demangled. Note also that overloaded C++ names must be written in full. Single quotes may be necessary to prevent the shell from breaking them up. For
               example:
    
                   --alloc-fn='operator new(unsigned, std::nothrow_t const&)'
    
           --ignore-fn=<name>
               Any direct heap allocation (i.e. a call to malloc, new, etc, or a call to a function named by an --alloc-fn option) that occurs in a function specified by this option will be
               ignored. This is mostly useful for testing purposes. This option can be specified multiple times on the command line, to name multiple functions.
    
               Any realloc of an ignored block will also be ignored, even if the realloc call does not occur in an ignored function. This avoids the possibility of negative heap sizes if
               ignored blocks are shrunk with realloc.
    
               The rules for writing C++ function names are the same as for --alloc-fn above.
    
           --threshold=<m.n> [default: 1.0]
               The significance threshold for heap allocations, as a percentage of total memory size. Allocation tree entries that account for less than this will be aggregated. Note that
               this should be specified in tandem with ms_print's option of the same name.
    
           --peak-inaccuracy=<m.n> [default: 1.0]
               Massif does not necessarily record the actual global memory allocation peak; by default it records a peak only when the global memory allocation size exceeds the previous peak
               by at least 1.0%. This is because there can be many local allocation peaks along the way, and doing a detailed snapshot for every one would be expensive and wasteful, as all
               but one of them will be later discarded. This inaccuracy can be changed (even to 0.0%) via this option, but Massif will run drastically slower as the number approaches zero.
    
           --time-unit=<i|ms|B> [default: i]
               The time unit used for the profiling. There are three possibilities: instructions executed (i), which is good for most cases; real (wallclock) time (ms, i.e. milliseconds),
               which is sometimes useful; and bytes allocated/deallocated on the heap and/or stack (B), which is useful for very short-run programs, and for testing purposes, because it is
               the most reproducible across different machines.
    
           --detailed-freq=<n> [default: 10]
               Frequency of detailed snapshots. With --detailed-freq=1, every snapshot is detailed.
    
           --max-snapshots=<n> [default: 100]
               The maximum number of snapshots recorded. If set to N, for all programs except very short-running ones, the final number of snapshots will be between N/2 and N.
    
           --massif-out-file=<file> [default: massif.out.%p]
               Write the profile data to file rather than to the default output file, massif.out.<pid>. The %p and %q format specifiers can be used to embed the process ID and/or the
               contents of an environment variable in the name, as is the case for the core option --log-file.
    

    对其中几个常用的选项做一个说明:

    • –stacks: 栈内存的采样开关,默认关闭。打开后,会针对栈上的内存也进行采样,会使 massif 性能变慢;
    • –time-unit:指定用来分析的时间单位。这个选项三个有效值:执行的指令(i),即默认值,用于大多数情况;即时(ms,单位毫秒),可用于某些特定事务;以及在堆(/或者)栈中分配/取消分配的字节(B),用于很少运行的程序,且用于测试目的,因为它最容易在不同机器中重现。这个选项在使用 ms_print 输出结果画图是游泳
    • –detailed-freq: 针对详细内存快照的频率,默认是 10, 即每 10 个快照会有采集一个详细的内存快照
    • –massif-out-file: 采样结束后,生成的采样文件(后续可以使用 ms_print 或者 massif-visualizer 进行分析)

    开始采集

    经过上面的了解,接下来可以开始内存数据采集了,假设我们需要采集的二进制程序名为 xprogram:

    valgrind -v --tool=massif --time-unit=B --detailed-freq=1 --massif-out-file=./massif.out  ./xprogram someargs
    

    运行一段时间后,采集到足够多的内存数据之后,我们需要停止程序,让它生成采集的数据文件,使用 kill 命令让 valgrind 程序退出。

    attention: 这里禁止使用 kill -9 模式去杀进程,不然不会产生采样文件

    ms_print 分析采样文件

    ms_print 是用来分析 massif 采样得到的内存数据文件的,使用命令为:

    ms_print ./massif.out
    

    或者把输出保存到文件:

    ms_print ./massif.out > massif.result
    

    打开 massif.result 看看长啥样:

    --------------------------------------------------------------------------------
    Command:            ./xprogram someargs
    Massif arguments:   --time-unit=B --massif-out-file=./massif.out
    ms_print arguments: massif.out
    --------------------------------------------------------------------------------
    
    
        GB
    1.279^                                                                       #
         |                                                                       #
         |                                                                   @  @#
         |                                                                   @::@#
         |                                                                 @:@: @#
         |                                                            @::  @:@: @#
         |                                                      : ::::@: ::@:@: @#
         |                                             @ @@@@ :::::: :@: : @:@: @#
         |                                          :  @:@ @ @: :::: :@: : @:@: @#
         |                                     @  :::::@:@ @ @: :::: :@: : @:@: @#
         |                               @@:::@@::: :: @:@ @ @: :::: :@: : @:@: @#
         |                            :::@ : :@@: : :: @:@ @ @: :::: :@: : @:@: @#
         |                    :: @@::::: @ : :@@: : :: @:@ @ @: :::: :@: : @:@: @#
         |                 :::: :@ :: :: @ : :@@: : :: @:@ @ @: :::: :@: : @:@: @#
         |          @  :::::::: :@ :: :: @ : :@@: : :: @:@ @ @: :::: :@: : @:@: @#
         |        ::@::: : :::: :@ :: :: @ : :@@: : :: @:@ @ @: :::: :@: : @:@: @#
         |      ::::@: : : :::: :@ :: :: @ : :@@: : :: @:@ @ @: :::: :@: : @:@: @#
         |     :: ::@: : : :::: :@ :: :: @ : :@@: : :: @:@ @ @: :::: :@: : @:@: @#
         |   @@:: ::@: : : :::: :@ :: :: @ : :@@: : :: @:@ @ @: :::: :@: : @:@: @#
         | ::@ :: ::@: : : :::: :@ :: :: @ : :@@: : :: @:@ @ @: :::: :@: : @:@: @#
       0 +----------------------------------------------------------------------->GB
         0                                                                   813.9
    
    Number of snapshots: 68
     Detailed snapshots: [2, 7, 16, 21, 24, 25, 30, 32, 33, 34, 41, 44, 46, 48, 51, 52, 58, 59, 61, 64, 65, 66, 67 (peak)]
    
    

    这张图大概意思就表示堆内存的分配量随着采样时间的变化。从上图可以看到堆内存一直在增长,可能存在一些内存泄露等问题。

    往下看还能看到内存的分配栈:

      0              0                0                0             0            0
      1 20,021,463,688      133,278,776      124,687,612     8,591,164            0
      2 45,201,848,936      204,228,232      191,089,596    13,138,636            0
    93.57% (191,089,596B) (heap allocation functions) malloc/new/new[], --alloc-fns, etc.
    ->41.07% (83,886,080B) 0xF088E6: rocksdb::Arena::AllocateNewBlock(unsigned long) (in /chain/xtopchain)
    | ->41.07% (83,886,080B) 0xF08500: rocksdb::Arena::AllocateFallback(unsigned long, bool) (in /chain/xtopchain)
    |   ->41.07% (83,886,080B) 0xF0886C: rocksdb::Arena::AllocateAligned(unsigned long, unsigned long, rocksdb::Logger*) (in /chain/xtopchain)
    |     ->41.07% (83,886,080B) 0xDE62BC: rocksdb::ConcurrentArena::AllocateAligned(unsigned long, unsigned long, rocksdb::Logger*)::{lambda()
    |     | ->41.07% (83,886,080B) 0xDE7D9A: char* rocksdb::ConcurrentArena::AllocateImpl<rocksdb::ConcurrentArena::AllocateAligned(unsigned long, unsigned long, rocksdb::Logger*)::{lambda()
    |     |   ->41.07% (83,886,080B) 0xDE6371: rocksdb::ConcurrentArena::AllocateAligned(unsigned long, unsigned long, rocksdb::Logger*) (in /chain/xtopchain)
    |     |     ->41.07% (83,886,080B) 0xE6FAB0: rocksdb::InlineSkipList<rocksdb::MemTableRep::KeyComparator const&>::AllocateNode(unsigned long, int) (in /chain/xtopchain)
    |     |       ->41.07% (83,886,080B) 0xE6F472: rocksdb::InlineSkipList<rocksdb::MemTableRep::KeyComparator const&>::AllocateKey(unsigned long) (in /chain/xtopchain)
    |     |         ->41.07% (83,886,080B) 0xE6E40A: rocksdb::(anonymous namespace)::SkipListRep::Allocate(unsigned long, char**) (in /chain/xtopchain)
    |     |           ->41.07% (83,886,080B) 0xDE32E3: rocksdb::MemTable::Add(unsigned long, rocksdb::ValueType, rocksdb::Slice const&, rocksdb::Slice const&, bool, rocksdb::MemTablePostProcessInfo*) (in /chain/xtopchain)
    |     |             ->41.07% (83,886,080B) 0xE5C218: rocksdb::MemTableInserter::PutCFImpl(unsigned int, rocksdb::Slice const&, rocksdb::Slice const&, rocksdb::ValueType) (in /chain/xtopchain)
    |     |               ->41.07% (83,886,080B) 0xE5C92C: rocksdb::MemTableInserter::PutCF(unsigned int, rocksdb::Slice const&, rocksdb::Slice const&) (in /chain/xtopchain)
    |     |                 ->41.07% (83,886,080B) 0xE570E4: rocksdb::WriteBatch::Iterate(rocksdb::WriteBatch::Handler*) const (in /chain/xtopchain)
    |     |                   ->41.07% (83,886,080B) 0xE598D5: rocksdb::WriteBatchInternal::InsertInto(rocksdb::WriteThread::WriteGroup&, unsigned long, rocksdb::ColumnFamilyMemTables*, rocksdb::FlushScheduler*, bool, unsigned long, rocksdb::DB*, bool, bool, bool) (in /chain/xtopchain)
    |     |                     ->41.07% (83,886,080B) 0xD45AD7: rocksdb::DBImpl::WriteImpl(rocksdb::WriteOptions const&, rocksdb::WriteBatch*, rocksdb::WriteCallback*, unsigned long*, unsigned long, bool, unsigned long*, unsigned long, rocksdb::PreReleaseCallback*) (in /chain/xtopchain)
    |     |                       ->28.75% (58,720,256B) 0x1013B9C: rocksdb::WriteCommittedTxn::CommitWithoutPrepareInternal() (in /chain/xtopchain)
    |     |                       | ->28.75% (58,720,256B) 0x1013653: rocksdb::PessimisticTransaction::Commit() (in /chain/xtopchain)
    |     |                       |   ->28.75% (58,720,256B) 0xF40E17: rocksdb::PessimisticTransactionDB::Put(rocksdb::WriteOptions const&, rocksdb::ColumnFamilyHandle*, rocksdb
    

    能看到内存分配的调用堆栈情况,据此可以看到哪里分配的内存较多。

    massif-visualizer 可视化分析采样文件

    ms_print 一定程度上不够直观,所以祭出另外一个分析内存采样数据的大杀器 – massif-visualizer,它能可视化的展示内存分配随着采样时间的变化情况,并能直观的看到内存分配的排行榜

    注意: massif-visualizer 目前好像只支持 linux 环境,并且具有桌面环境的 Linux. (mac/windows 的版本我没有找到)。

    故我们采用 ubuntu-20.04-lts 作为分析环境。

    安装软件

    直接在软件中心搜索 massif-visualizer,然后安装

    启动软件,分析数据

    双击 massif-visualizer 启动软件之后,打开并选中某个 massif.out 文件,或者用命令行的方式打开:

    massif-visualizer ./massif.out
    
    

    启动后,能直观的看到内存随采样时间的变化情况:

    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-e4FpxC7z-1599172693405)(https://cdn.jsdelivr.net/gh/smaugx/MyblogImgHosting/rebootcat/valgrind_massif_memory_analysing/2.png)]

    调整上面的选项 Stacked diagrams 值后:

    鼠标悬停之后也能看到每条曲线某个 snapshot 对应的内存分配情况。

    界面右边是内存调用的堆栈:

    点击界面下面的 Allocators 按钮之后,可以看到内存分配的排行榜:

    是不是很方便?

    写在最后

    其实用于分析内存分配情况的利器还可以采用 google-perftools,也是采用对内存采样的方式进行采集,然后生成不同的内存采样文件,结束之后比较两个内存采样文件,就可以分析内存分配情况,同时也能展示初内存分配的函数调用栈。不过相比较于 valgrind 的 massif 插件,google-perftools 是需要代码侵入的,并且不能直观的展示内存随采样时间的变化情况

    而 massif 采样的内存数据文件,借助 massif-visualizer 工具就能直观的感受到内存分配随采样时间的变化情况。

    Blog:

    2020-06-16 于杭州
    By 史矛革

    展开全文
  • valgrind massif内存分析

    千次阅读 2018-07-30 21:07:55
    valgrind检查内存泄露 #valgrind ./程序 内存泄漏问题,我们有memcheck工具来检查。很爽。但是有时候memcheck工具查了没泄漏,程序一跑,内存还是狂飙。这又是什么问题。。。 其实memcheck检查的内存泄漏只是...

    valgrind检查内存泄露

    #valgrind   ./程序

    内存泄漏问题,我们有memcheck工具来检查。很爽。但是有时候memcheck工具查了没泄漏,程序一跑,内存还是狂飙。这又是什么问题。。。

    其实memcheck检查的内存泄漏只是狭义的内存泄漏,或者说是严格的内存泄漏,也就是说,在程序运行的生命周期内,这部分内存你是彻底释放不了了,即,你失去了这些地址。

    其实还有第二种类型的内存泄漏,就是,长期闲置的内存堆积。这部分内存虽然你还保存了地址,想要释放的时候还是能释放。关键就是你忘了释放。。。杯具啊。这种问题memcheck就不给力了。这就引出了第二个内存工具valgrind –tool=massif。

    会产生massif.out.****的文件,然后使用

    # ms_print massif.out.*** >massif.log

     

    massif 可以的帮我们发现很多问题,比如现实中总是遇到一些内存一直上涨,可以就是没有memory leaker的情况, 其实这样的情况并不奇怪,非常容易发生,比如每次循环的时候你并没有把上次的内存释放,同时不断在后面添加更多的内容,这显然不会有memory leaker,倒是到了一定的程度,自然会发生bad alloc的问题。对于这样的问题massif就可以大显身手,比较一下两个内存的切片,增加的部分自然就发现了。

     

    官方主页教程:http://valgrind.org/docs/manual/ms-manual.html

    先看一个图是分析firefox内存使用的:

     

     

    安装massif-visualizer

    massif-visualizer是ubuntu下的图形化分析工具

    http://get.ubuntusoft.com/app/massif-visualizer

    项目主页:

    https://projects.kde.org/projects/extragear/sdk/massif-visualizer

    massif-visualizer下载:

    http://tel.mirrors.163.com/ubuntu/pool/universe/m/massif-visualizer/

    软件包详细信息

    http://packages.ubuntu.com/massif-visualizer

    安装massif-visualizer:


    ------------------------------------------------------------------------------------

     

    官方示例代码:

     

     
    1. #include <stdlib.h>

    2.  
    3. void g(void){

    4. malloc(4000);

    5. }

    6.  
    7. void f(void){

    8. malloc(2000);

    9. g();

    10. }

    11.  
    12. int main(void){

    13. int i;

    14. int* a[10];

    15.  
    16. for(i = 0; i < 10; i++){

    17. a[i] = malloc(1000);

    18. }

    19.  
    20. f();

    21. g();

    22.  
    23. for(i = 0; i < 10; i++){

    24. free(a[i]);

    25. }

    26.  
    27. return 0;

    28. }

    # cc -o  test test.c
    # valgrind --tool=massif ./test
    # ms_print massif.out.4144

     

     

     

    Why is most of the graph empty, with only a couple of bars at the veryend? By default, Massif uses "instructions executed" as the unit of time.For very short-run programs such as the example, most of the executedinstructions involve the loading and dynamic linking of the program. Theexecution of main (and thus the heapallocations) only occur at the very end. For a short-running program likethis, we can use the--time-unit=B optionto specify that we want the time unit to instead be the number of bytesallocated/deallocated on the heap and stack(s).

    If we re-run the program under Massif with this option, and thenre-run ms_print, we get this more useful graph:

     

    在massif-visualizer下看图形化的:massif.out.4144

     

    在massif-visualizer下看图形化的:massif.out.4164

     

    再看这个C++程序:

     

     
    1. #include <stdlib.h>

    2. #include <stdio.h>

    3.  
    4. int *fa()

    5. {

    6. int *p=(int*)malloc(10000);

    7. return p;

    8. }

    9.  
    10. int *fb(int *p)

    11. {

    12. delete p;

    13. }

    14.  
    15. int main(void)

    16. {

    17. printf("ok\n");

    18.  
    19. printf("really ok?\n");

    20.  
    21. int *vec[10000];

    22.  
    23. for(int i=0;i<10000;i++)

    24. {

    25. vec[i]=fa();

    26. }

    27.  
    28.  
    29. for(int i=0;i<10000;i++)

    30. {

    31. fb(vec[i]);

    32. }

    33.  
    34. return 0;

    35. }


    # g++ test.cc -o testcpp

     

     

    监控nginx,redis,memcached

    # valgrind --tool=massif /usr/local/nginx/sbin/nginx -c /usr/local/nginx/conf/nginx.conf
    # valgrind --tool=massif /usr/local/memcached/bin/memcached -d -m 64 -uroot -l 0.0.0.0 -p 11211 -c 1024
    # valgrind --tool=massif /usr/redis-2.8.1/src/redis-server

     

    redis:

     

    memcached:

     

    nginx:

     

    安装一个插件可以看到函数调用关系:

     

    firefox:

    -----------------------------------------------------------------------------

    非常好的使用实例:

    Memory profiling Firefox with Massif

     

    http://blog.mozilla.org/nnethercote/2010/12/09/memory-profiling-firefox-with-massif/

     

    Here’s the command line I used:

      valgrind --smc-check=all --trace-children=yes --tool=massif --pages-as-heap=yes \
        --detailed-freq=1000000 optg64/dist/bin/firefox -P cad20 -no-remote

    Here’s what that means:

    • --smc-check=all tells Valgrind that the program may use self-modifying code (or, in Firefox’s case, overwrite dynamically generated code).
    • --trace-children tells Valgrind to trace into child processes exec’d by the program.  This is necessary because optg64/dist/bin/firefox is a wrapper script.
    • --tool=massif tells Valgrind to run Massif.
    • --pages-as-heap=yes tells Massif to profile allocations of all memory at the page level, rather than just profiling the heap (ie. memory allocated via malloc/new).  This is important because the heap is less than half of Firefox’s memory consumption.
    • --detailed-freq=1000000 tells Massif to do detailed snapshots (which are more informative but more costly) only every 1,000,000th snapshot, which is less often than the default of every 10th snapshot.  This makes it run a bit faster.  This is fine because Massif always takes a detailed snapshot at the peak memory consumption point, and that’s the one I’m interested in.
    • optg64/ is the name of my build directory.
    • -P cad20 tells Firefox to use a particular profile that I set up appropriately.
    • -no-remote tells Firefox to start a new instance;  this is necessary because I had a Firefox 3.6 process already running.

    ms_print massif.out.22722

    更多参考:http://www.cs.washington.edu/education/courses/cse326/05wi/valgrind-doc/ms_main.html

    展开全文
  • valgrind工具之massif

    2011-10-26 21:48:24
    今天小试了一把valgrindmassif工具。Massifvalgrind中的介绍是这样的: Massif Massif is a heap profiler. It performs detailed heap profiling by taking regular snapshots of a program's heap. It ...

    今天小试了一把valgrind的massif工具。Massif在valgrind中的介绍是这样的:

    Massif

    Massif is a heap profiler. It performs detailed heap profiling by taking regular snapshots of a program's heap. It produces a graph showing heap usage over time, including information about which parts of the program are responsible for the most memory allocations. The graph is supplemented by a text or HTML file that includes more information for determining where the most memory is being allocated. Massif runs programs about 20x slower than normal.

     

    可以看出Massif是一个内存剖析工具。通过不断的取程序堆的快照来达到监视程序内存分配的目的。


     

    我们来编写一个这样的C++文件:test.cc

     

     

    #include <stdlib.h>
    #include <stdio.h>
    
    int *fa()
    {
      int *p=(int*)malloc(10000);
      return p;
    }
    
    int *fb(int *p) 
    {
      delete p;
    }
    
    int main(void)
    {
      printf("ok\n");
    
      printf("really ok?\n");
    
      int *vec[10000];
    
      for(int i=0;i<10000;i++)
      {
        vec[i]=fa();
      }
    
    
      for(int i=0;i<10000;i++)
      {
        fb(vec[i]);
      }
    
      return 0;
    }

    使用g++进行编译:

     

    g++ test.cc -o test
    

    然后使用valgrind的massif:

     

    valgrind --tool=massif ./test

    最后就得到一个massif文件:massif.out.32682 (32682代码进程pid)

    使用ms_print来解析这个输出文件:

     

    ms_print massif.out.32682

     最后得到解析结果:



    通过图形可以看出Heap随时间变化的变化,可以通过分析下面的函数信息得到究竟是那些函数占用了大量的内存。

     

     

     

     

     

     

     

     

    展开全文
  • 关于Valgrind的简介可以参考:https://blog.csdn.net/fengbingchun/article/details/50196189 Valgrind在Ubuntu上的安装可以参考:...可以使用Valgrind的memcheck工具来检查是否有内存泄漏,可以...

    关于Valgrind的简介可以参考:https://blog.csdn.net/fengbingchun/article/details/50196189

    Valgrind在Ubuntu上的安装可以参考:https://blog.csdn.net/fengbingchun/article/details/78164837

    可以使用Valgrind的memcheck工具来检查是否有内存泄漏,可以使用massif工具来对内存使用情况进行分析。这里简单介绍下massif工具的使用。

    Massif工具的官网介绍可以参考:http://valgrind.org/docs/manual/ms-manual.html

    Massif是一个堆分析器,它能够测量程序使用了多少堆内存,是一个内存剖析工具,通过不断的取程序堆的快照来达到监视程序内存分配的目的。可以非常容易的获取到内存使用峰值。它也可以测量程序使用栈的大小,默认情况下此选项是关闭的。通过对结果的分析,Massif工具可以帮助减少程序的内存使用量,它会提供非常详细的信息,指出程序中的哪一部分负责分配堆内存。

    这里通过GitHub中的Messy_Test(https://github.com/fengbingchun/Messy_Test )项目对Massif工具的使用过程进行说明,以调用二叉树接口为例:binary_search_tree_::test_binary_search_tree(),将终端定位到prj/linux_cmake_CppBaseTest目录下,依次执行以下命令:

    ./build.sh
    valgrind --tool=massif ./build/CppBaseTest

    执行结果如下:

    并会在当前目录下生成massif.out.24949文本文件,其中24949为进程号,此文件中详细记录了执行此测试程序时内存的使用情况,执行以下命令:

    ms_print massif.out.24949

    结果如下:显示内存使用峰值为87.35KB以及程序中的哪一行有内存分配等详细信息。

    使用ms_print显示可视化效果不好,可以通过massif-visualizer对结果进行可视化显示。

    massif-visualizer在Ubuntu 14.04上安装过程如下:

    1. 从 https://launchpad.net/ubuntu/trusty/amd64/massif-visualizer/0.3-0ubuntu3 下载 massif-visualizer_0.3-0ubuntu3_amd64.deb;

    2. 双击massif-visualizer_0.3-0ubuntu3_amd64.deb进行安装(通过Ubuntu Software Center)。

    执行命令:

    massif-visualizer massif.out.24949

    结果如下:

    如果程序执行时间较短,可以增加--time-unit=B选项,即:

    valgrind --tool=massif --time-unit=B ./build/CppBaseTest

    为了获得每个快照详尽的信息,可以增加--detailed-freq=1选项,详细的快照信息在图表中由”@”字符组成的条形图表示。默认情况下,10个快照中只有第10个快照是详细的。即:

    valgrind --tool=massif --detailed-freq=1 ./build/CppBaseTest

     

    展开全文
  • http://valgrind.org/docs/manual/mc-manual.html Memcheck是一个内存错误检测器。它可以检测C和C ++程序中常见的以下问题。 访问内存不应该,例如超越和不足堆积块,超出堆栈顶部,并在释放后访问内存。 ...
  • valgrind --tool=massif ./a.out a.out 是可执行程序,当程序执行结束之后,会生成一个分析报告,分析报告的名称一般为 massif.out.pid 。 如果是循环程序,可以使用 top 查看内存,当内存增长到一定程序之后 Ctrl ...
  • valgrind massif

    千次阅读 2013-01-30 11:29:46
    Massif: a heap profiler massif 已经成功的帮我发现了很多问题,比如现实中总是遇到一些内存一直上涨,可以就是没有memory leaker的情况, 其实这样的情况并不奇怪,非常容易发生,比如每次循环的时候你并没有把...
  • Massif是一个堆分析器。它测量程序使用的堆内存量。这包括有用空间和为记账和对齐目的分配的额外字节。它也可以测量程序堆栈的大小,但默认情况下不会这样做。 堆分析可以帮助您减少程序使用的内存量。在具有虚拟...
  • valgrind Massif

    千次阅读 2013-07-15 12:01:00
    这就引出了第二个内存工具valgrind –tool=massif。 会产生massif.out.****的文件,然后使用 # ms_print massif.out.*** >massif.log massif 可以的帮我们发现很多问题,比如现实中总是遇到一些内存...
  • Massif 堆栈分析器,它能测量程序在堆栈中使用了多少内存,告诉我们堆块,堆管理块和栈的大小。Massif能帮助我们减少内存的使用,在带有虚拟内存的现代系统中,它还能够加速我们程序的运行,减少程序停留在交换区中...
  • 文章目录valgrind 搭配的相关工具安装massif-visualizer抓取massif分析Ceph-mon运行时内存数据massif的详细参数vgdb配合valgrind结合massif的相关monitor指令调试进程打开vgdb调试进行massif的monitor指令调试massif...
  • 2020_05_Massif_Visual Grafičkoi interaktivno prikazivanje izlaza valgrind-ovog alata Massif
  • valgrind安装与使用

    2020-03-10 20:37:32
    valgrind是一款可用于检测内存、分析函数调用的程序,程序内部可以仿真模拟指定的进程。 下载与安装 http://valgrind.org/downloads/current.html下载source code后,参照目录下的README文件安装: ./configure --...
  • 1、Valgrind概述 Valgrind是一套Linux下,开放源代码(GPL V2)的仿真调试工具的集合。 Valgrind由内核(core)以及基于内核的其他调试工具组成。内核类似于一个框架(framework),它模拟了一个CPU环境,并提供服务...
  • valgrind检查内存泄露 #valgrind ./程序 内存泄漏问题,我们有memcheck工具来检查。很爽。但是有时候memcheck工具查了没泄漏,程序一跑,内存还是狂飙。这又是什么问题。。。 其实memcheck检查的内存泄漏只是狭义...
  • valgrind工具使用

    2019-07-26 15:31:27
    强烈推荐被调试的目标程序在编译时加入-g参数,这样再运行valgrind memcheck时,可以拿到更为丰富的调试信息,比如行号,调用栈等。 b. 当使用-O0编译目标程序时,valgrind可以保证输出的所有警告、错误提示信息都...
  • valgrind是一款强大的C++程序调试工具,可帮助我们检测程序中的内存泄露、死锁等,valgrind的安装比较简单。下载了valgrind后,在linux系统中输入下列命令: $ sudo apt-get install automake $ tar jxf valgrind-...
  • Ubuntu 14.04 64位上安装Valgrind 3.13.0 操作步骤
  • valgrind简介与使用

    万次阅读 多人点赞 2019-08-11 14:19:17
    一、valgrind简介 Valgrind是一款用于内存调试、内存泄漏检测以及性能分析、检测线程错误的软件开发工具。 Valgrind 是运行在Linux 上的多用途代码剖析和内存调试软件。主要包括Memcheck、Callgrind、Cachegrind ...
  • valgrind安装及使用

    千次阅读 2019-02-17 21:03:01
    valgrind安装及使用 微信公众号:幼儿园的学霸 个人的学习笔记,关于OpenCV,关于机器学习, … 问题或建议,请公众号留言; 目录 valgrind介绍 valgrind安装 valgrind运行界面分析 valgrind介绍 Valgrind是...
  • Valgrind 基本用法

    2021-04-12 17:05:14
    Valgrind 是一套 Linux 下的开源仿真调试工具集,遵循 GPLv2 许可协议,可用于内存调试、内存泄漏检测以及性能分析。 Valgrind 由内核(core)以及基于内核的其他调试工具组成,内核类似于一个框架(framework),它...
  • valgrind massif检测内存使用比例

    千次阅读 2015-02-17 09:44:53
    http://valgrind.org/docs/manual/ms-manual.html 9. Massif: a heap profiler Table of Contents 9.1. Overview9.2. Using Massif and ms_print 9.2.1. An Example Program9.2.2. Running ...
  • 在Ubuntu 14.04 64bit上安装massif visualizer

    千次阅读 2015-04-10 17:57:30
    massifValgrind工具集中的一个堆栈分析器,它指示程序中使用了多少堆内存等信息,而massif visualizer就是将massif记录的内存使用情况可视化,也就是一个GUI工具。当你使用Valgrind附带 --tool=massif 选项来测试...
  • Valgrind通常用来成分析程序性能及程序中的内存泄露错误 一 Valgrind工具集简绍 Valgrind包含下列工具:  1、memcheck:检查程序中的内存问题,如泄漏、越界、非法指针等。  2、callgrind:检测...
  • ubuntu 上使用valgrind

    2014-08-09 16:01:00
    Valgrind是一个GPL的软件,用于Linux(For x86, amd64 and ppc32)程序的内存调试和代码剖析。你可以在它的环境中运行你的程序来监视内存的使用情况,比如C 语言中的malloc和free或者 C++中的new和 delete。使用...
  • 环境准备 valgrind-3.15.0官网下载地址:http://valgrind.org/ ...下载好valgrind-3.15.0.tar.bz2文件后进行解压 tar xvf valgrind-3.15.0.tar.bz2 安装automake apt-get install automake 运行autog...
  • valgrind安装及使用方法详解

    万次阅读 2018-03-13 13:51:05
     valgrind介绍:l Valgrind查找内存泄露利器Valgrind是一个GPL的软件,用于Linux(For x86, amd64 and ppc32)程序的内存调试和代码剖析。你可以在它的环境中运行你的程序来监视内存的使用情况,比如C 语言中的...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 1,225
精华内容 490
热门标签
关键字:

massifvalgrind