When running in low memory scenarious, everything is fine. When running the testcase I'm interested in, massif terminates before anything interesting is happening. There is no message about why it terminates so early. I downloaded valgrind 3.8.1 and compiled it from source. This repeatable. The command: valgrind --tool=massif --max-snapshots=1000 --depth=30 /home/peterf/myapp.exe | & tee 1.log The output: ==6426== Massif, a heap profiler ==6426== Copyright (C) 2003-2012, and GNU GPL'd, by Nicholas Nethercote ==6426== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info ==6426== Command: /home/peterf/Myapp.exe ==6426== ==6426== A massif.out.pid file is being produced and contains valid content. I tried different --time-unit arguments. I cannot use google memory profiler, as it hangs when trying to establish the stack using libunwind. Reproducible: Always
[peterf@tmp68 ~]$ limit cputime unlimited filesize unlimited datasize unlimited stacksize unlimited coredumpsize 0 kbytes memoryuse unlimited vmemoryuse unlimited descriptors 1024 memorylocked 32 kbytes maxproc 794624 [peterf@tmp68 ~]$
with --time-unit=ms it terminates with a message: ==11696== Massif, a heap profiler ==11696== Copyright (C) 2003-2012, and GNU GPL'd, by Nicholas Nethercote ==11696== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info ==11696== Command: /home/peterf/Myapp.exe ==11696== ==11696== ==11696== Valgrind's memory management: out of memory: ==11696== newSuperblock's request for 4194304 bytes failed. ==11696== 34164117504 bytes have already been allocated. ==11696== Valgrind cannot continue. Sorry. ==11696== ==11696== There are several possible reasons for this. ==11696== - You have some kind of memory limit in place. Look at the ==11696== output of 'ulimit -a'. Is there a limit on the size of ==11696== virtual memory or address space? ==11696== - You have run out of swap space. ==11696== - Valgrind has a bug. If you think this is the case or you are ==11696== not sure, please let us know and we'll try to fix it. ==11696== Please note that programs can take substantially more memory than ==11696== normal when running under Valgrind tools, eg. up to twice or ==11696== more, depending on the tool. On a 64-bit machine, Valgrind ==11696== should be able to make use of up 32GB memory. On a 32-bit ==11696== machine, Valgrind should be able to use all the memory available ==11696== to a single process, up to 4GB if that's how you have your ==11696== kernel configured. Most 32-bit Linux setups allow a maximum of ==11696== 3GB per process. ==11696== ==11696== Whatever the reason, Valgrind cannot continue. Sorry.
I've been running processes consuming 70GB on this machine. So this is not a system limit.
In 3.8.1 the maximum usable memory is about 32GB (a long story). But on 29 Jan this year, that was changed in the trunk to increase it to 64GB. So it would be worth trying the trunk instead. svn co svn://svn.valgrind.org/valgrind/trunk trunk cd trunk ./autogen.sh Then configure and build in the normal way.
Can you try the trunk?
Closing as Worksforme due to inactivity for more than 15 days as per: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging#Policies Fanis
Please don't apply KDE policies to non-KDE packages.