2

I'm using the new_handler in C++ to try and free up some memory when an allocation fails. Is it possible to use massif in a way to profile this? I would like to see how much memory is actually freed by the handler and ideally have a detailed snapshot before and after calling the new_handler.

Just calling massif on the process doesn't work because it is limited by the same limit as the program:

> cat run
#!/bin/bash
ulimit -v 128000
my_program

> valgrind --tool=massif --trace-children=yes --detailed-freq=1 ./run
==7602== Massif, a heap profiler
==7602== Copyright (C) 2003-2011, and GNU GPL'd, by Nicholas Nethercote
==7602== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==7602== Command: ./run
==7602== 
==7605== Massif, a heap profiler
==7605== Copyright (C) 2003-2011, and GNU GPL'd, by Nicholas Nethercote
==7605== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==7605== Command: ./my_program
==7605== 
ERROR: ld.so: object '/usr/lib/valgrind/vgpreload_core-amd64-linux.so' from LD_PRELOAD cannot be preloaded: ignored.
ERROR: ld.so: object '/usr/lib/valgrind/vgpreload_massif-amd64-linux.so' from LD_PRELOAD cannot be preloaded: ignored.
[output of program snipped]
==7605== 
==7605==     Valgrind's memory management: out of memory:
==7605==        newSuperblock's request for 4194304 bytes failed.
==7605==        122073088 bytes have already been allocated.
==7605==     Valgrind cannot continue.  Sorry.
==7605== 
==7605==     There are several possible reasons for this.
==7605==     - You have some kind of memory limit in place.  Look at the
==7605==       output of 'ulimit -a'.  Is there a limit on the size of
==7605==       virtual memory or address space?
==7605==     - You have run out of swap space.
==7605==     - Valgrind has a bug.  If you think this is the case or you are
==7605==     not sure, please let us know and we'll try to fix it.
==7605==     Please note that programs can take substantially more memory than
==7605==     normal when running under Valgrind tools, eg. up to twice or
==7605==     more, depending on the tool.  On a 64-bit machine, Valgrind
==7605==     should be able to make use of up 32GB memory.  On a 32-bit
==7605==     machine, Valgrind should be able to use all the memory available
==7605==     to a single process, up to 4GB if that's how you have your
==7605==     kernel configured.  Most 32-bit Linux setups allow a maximum of
==7605==     3GB per process.
==7605== 
==7605==     Whatever the reason, Valgrind cannot continue.  Sorry.
==7602==
Flogo
  • 1,673
  • 4
  • 20
  • 33
  • Some ideas for you: You could replace your program's allocater with a limited one by either wrapping `malloc` and `free` http://valgrind.org/docs/manual/manual-core-adv.html#manual-core-adv.wrapping with a counting implementation, and adding your wrapped implementation to `LD_PRELOAD`. Alternatly, you can use one of several memory debugging `malloc` libraries. This way valgrind won't be under the same limits – Hasturkun Jul 03 '13 at 09:40

0 Answers0