valgrind-users — General discussion list for Valgrind users

Re: [Valgrind-users] Mismatched free/delete with GCC 4.8.3 std::string

[Philippe W. <phi...@sk...>]

On Thu, 2015-06-11 at 12:14 +0200, Julian Seward wrote:
> > I've recently switched over to Valgrind 3.10.1 and I'm now see vast numbers
> > of 'mismatched free/delete' type messages all coming from std::string
> > shipped with GCC 4.8.3.
Do you see these 'mismatches free/delete' only with Valgrind 3.10.1 ?
I.e. has it appeared with Valgrind 3.10.1 or has it appeared
with a switch to gcc 4.8.3 ?
> 
> I've seen this a lot in the past year when working with Firefox.  I believe
> that it is due to what you could call "differential inlining".  I'm not 100%
> sure of the details, but the general problem is like this:
> 
> Memcheck intercepts malloc, free, new and delete.  It expects memory
> allocated by malloc to be freed by free and memory allocated by new
> to be freed by delete (and the same for new[] and delete[]).
> 
> Imagine now that some C++ header file contains something like this
> 
>    operator new ( size_t n ) { return malloc(n); }
>    operator delete ( void* p ) { free(p); }
> 
> If g++ decides to inline new but not delete, or the other way round, then
> the code still works (of course) but from Memcheck's point of view there is
> a problem.  That's because it can't intercept the inlined function -- there
> is no single piece of code to intercept.  So what it ends up seeing is,
> for example, memory allocated by new (because that isn't inlined) but freed
> by free (because delete got inlined).  So it complains -- incorrectly.
If the problem is due to "differential inlining", then that should
be visible in the stacktraces either of the "new" or of the "delete" :
unless you specify --read-inline-info=no, valgrind stacktraces will
show both the "new/malloc" or "delete/free" in the stacktraces,
but with an identical program counter.

> 
> I couldn't figure out any sane way to work around this, so I added a new
> flag,


>  --show-mismatched-frees=no|yes [default=yes], to the trunk.  This
> disables allocator-mismatch checking and gets rid of the noise, but it of
> course also gets rid of the ability to detect genuine mismatch errors.
What might be done is (assuming that the inline info shows properly the
call to new/delete), is to have an additional check before reporting
a 'mismatched' error: if the stacktrace contains an inlined call to
the expected "freeing function", then do not report the error.
Eg, we might have a third value for --show-mismatched-frees=checkinline
which would activate this verification.
That should remove the false positive errors, and allow to
keep the true positive. The price to pay will be a translation
of program counters to function name and string comparison for
all cases of such "differential inlining" (and that might have to
be done both for the alloc and the free stacktrace).

Philippe

Re: [Valgrind-users] Handling ioctl 0x30000001 in valgrind?

[Julian S. <js...@ac...>]

> One question to you: does it make sense to be hard-coding the *0x30000001*
> case into the generalioctl handler, or should there be an NVIDIA-specific
> file in the coregrind/m_syswrap directory?

There is already a mechanism for dealing with proprietary GPU ioctls,
because of the need to run on phones with various GPUs.  Try grepping
the sources (trunk) for "KernelVariant_android_gpu_adreno3xx" and follow
your nose from there.

Presumably you'll need to add a KernelVariant_<blah>_nvidia_<blah> enum
and a --kernel-variant= sub-flag.  Have a look at m_main.c:714.

J

Re: [Valgrind-users] Mismatched free/delete with GCC 4.8.3 std::string

[Dallman, J. <joh...@si...>]

Julian Seward wrote:

> One other option is to play around with optimisation settings for your app, to see if it changes g++'s inline/no-inline decisions.

g++'s -fno-inline option may help, although it has the same limitation of not applying to libraries.

--
John Dallman
-----------------
Siemens Industry Software Limited is a limited company registered in England and Wales.
Registered number: 3476850.
Registered office: Faraday House, Sir William Siemens Square, Frimley, Surrey, GU16 8QD.

[Valgrind-users] 回复： 回复： helgrind use more than 32G memory.

[王阳 <412...@qq...>]

Hi.


I download the latest version 3.10.1,but helgrind use memory over 64G and got a error from valgrind because of over the momory limit.


I used the option --stats=yes, I noticed that valgrind print message below endless util to use 64G memory. 


--28682-- univ_laog_do_GC enter cardinality 9614
--28682-- univ_laog_do_GC exit seen 6591 next gc at cardinality 9615


why?
DRD have not that problem ,but DRD 's message is not accurate comparing with helgrind. 


------------------ 原始邮件 ------------------
发件人: "我自己的邮箱";<412...@qq...>;
发送时间: 2015年6月11日(星期四) 上午9:20
收件人: "Philippe Waroquiers"<phi...@sk...>; 
抄送: "valgrind-users"<val...@li...>; 
主题: [Valgrind-users] 回复：  helgrind use more than 32G memory.



Hi.


Thank you for your reply.
Verison is 3.6.0,very old one,I will try version 3.10.1 and svn version,and also try two options you said.




------------------ 原始邮件 ------------------
发件人: "Philippe Waroquiers";<phi...@sk...>;
发送时间: 2015年6月11日(星期四) 凌晨3:42
收件人: "王阳"<412...@qq...>; 
抄送: "valgrind-users"<val...@li...>; 
主题: Re: [Valgrind-users] helgrind use more than 32G memory.



On Wed, 2015-06-10 at 19:17 +0800, 王阳 wrote:
> My answer is that helgrind really need more than 6 times or even more
> memory than before ,is that true?
> or helgrind have a bug?
The memory needed by helgrind might depend on what your program does.
Typically, it needs twice the original, but it might be a lot more.

Which version of Valgrind are you using ?
In the SVN version, some memory improvements have been done.

The best is to get the latest SVN version, compile it,
then run with --stats=yes.

That will give some indications where the memory is taken.
More detailed information can also be obtained by using
 --profile-heap=yes

Philippe

Re: [Valgrind-users] Mismatched free/delete with GCC 4.8.3 std::string

[Julian S. <js...@ac...>]

> I've recently switched over to Valgrind 3.10.1 and I'm now see vast numbers
> of 'mismatched free/delete' type messages all coming from std::string
> shipped with GCC 4.8.3.

I've seen this a lot in the past year when working with Firefox.  I believe
that it is due to what you could call "differential inlining".  I'm not 100%
sure of the details, but the general problem is like this:

Memcheck intercepts malloc, free, new and delete.  It expects memory
allocated by malloc to be freed by free and memory allocated by new
to be freed by delete (and the same for new[] and delete[]).

Imagine now that some C++ header file contains something like this

   operator new ( size_t n ) { return malloc(n); }
   operator delete ( void* p ) { free(p); }

If g++ decides to inline new but not delete, or the other way round, then
the code still works (of course) but from Memcheck's point of view there is
a problem.  That's because it can't intercept the inlined function -- there
is no single piece of code to intercept.  So what it ends up seeing is,
for example, memory allocated by new (because that isn't inlined) but freed
by free (because delete got inlined).  So it complains -- incorrectly.

I couldn't figure out any sane way to work around this, so I added a new
flag, --show-mismatched-frees=no|yes [default=yes], to the trunk.  This
disables allocator-mismatch checking and gets rid of the noise, but it of
course also gets rid of the ability to detect genuine mismatch errors.

One other option is to play around with optimisation settings for your
app, to see if it changes g++'s inline/no-inline decisions.  For example,
at -O0 it may be that neither function is inlined, and at -O2 both are,
and it's only at -O1 (a.k.a -O) that you get into this differentially
inlined situation.  I've found -Og, which is available in 4.8 and later,
to be not-bad, but YMMV.  Plus, playing with optimisation options is
of limited use since normally you can only recompile your app, not the
vast stack of libraries on which most apps now depend.

J

Re: [Valgrind-users] Mismatched free/delete with GCC 4.8.3 std::string

[<pa...@fr...>]

----- Original Message -----
> 
> Hi,
> 
> I've recently switched over to Valgrind 3.10.1 and I'm now see vast
> numbers of 'mismatched free/delete' type messages all coming from
> std::string shipped with GCC 4.8.3.
>
> I really don't believe what Valgrind is saying but I'd like to be
> certain. Firstly, has anyone else seen this behaviour recently and
> secondly what criteria does Valgrind use to determine if a mismatch
> occurred? Is it possible to print out more information from Valgrind
> about its decision process?


Hi David

Could you post an extract of the results?

Just to eliminate a few things. The string instance isn't itself newed?

I.e, you aren't doing something like

std::string* ps = new std::string;
...

free(ps);

I guess you would have seen this before.

You aren't overloading any operator new or delete or using placement new? You're using the default allocator std::allocator<char>?

Regards
Paul

[Valgrind-users] 回复： helgrind use more than 32G memory.

[王阳 <412...@qq...>]

Hi.


Thank you for your reply.
Verison is 3.6.0,very old one,I will try version 3.10.1 and svn version,and also try two options you said.




------------------ 原始邮件 ------------------
发件人: "Philippe Waroquiers";<phi...@sk...>;
发送时间: 2015年6月11日(星期四) 凌晨3:42
收件人: "王阳"<412...@qq...>; 
抄送: "valgrind-users"<val...@li...>; 
主题: Re: [Valgrind-users] helgrind use more than 32G memory.



On Wed, 2015-06-10 at 19:17 +0800, 王阳 wrote:
> My answer is that helgrind really need more than 6 times or even more
> memory than before ,is that true?
> or helgrind have a bug?
The memory needed by helgrind might depend on what your program does.
Typically, it needs twice the original, but it might be a lot more.

Which version of Valgrind are you using ?
In the SVN version, some memory improvements have been done.

The best is to get the latest SVN version, compile it,
then run with --stats=yes.

That will give some indications where the memory is taken.
More detailed information can also be obtained by using
 --profile-heap=yes

Philippe

Re: [Valgrind-users] How to track memory peaks with Massif (or other tools)

[Peter T. <pt...@li...>]

Perfect - nothing less :-)

---
Peter Toft <pt...@li...>

Peter Bortas skrev den 2015-06-08 15:06:
> heaptrack 
> (http://milianw.de/blog/heaptrack-a-heap-memory-profiler-for-linux)
> should be perfect for this. It shows a lovely 20-spike graph when
> combined with massif-vizualiser: http://i.imgur.com/Q7cXF8N.png
> 
> Regards,
> --
> Peter Bortas
> 
> 
> On Mon, Jun 8, 2015 at 1:50 PM, Peter Toft <pt...@li...> wrote:
>> Hi guys
>> 
>> I have some C/C++ programs that use very odd memory usage. I have made 
>> a
>> small replica below
>> (it can also be taken from http://pastebin.com/1ammgpCE)
>> Save e.g. as memfun.c
>> 
>> In the C-code I generate 20 peaks of very short memory peaks, and you
>> can compile (on Linux) and run as this:
>>     gcc -o memfun memfun.c  -lm
>>     valgrind --tool=massif --massif-out-file=massif.out ./memfun
>>     massif-visualizer massif.out
>> or
>>     ms_print massif.out > massif.txt; less massif.txt)
>> 
>> (BTW; Thanx to the maintainers of massif-visualizer - this rocks)
>> 
>> 
>> However with the standard settings I only get 3 memory peaks detected 
>> -
>> not 20.
>> Obviously I can tweak --threshold= and --peak-inaccuracy= but it seems
>> that
>> I in general can be sure that I can catch all peaks. Please comment 
>> :-)
>> 
>> Are these something that I miss here? Are there other tools that are
>> better suited for
>> detecting memory peaks like this memory-hedgehog....
>> 
>> Thanx mates
>> 
>> Best
>> 
>> Peter
>> 
>> ----------------
>> #include <stdio.h>
>> #include <stdlib.h>
>> #include <math.h>
>> 
>> /*
>> Demo program:
>>   gcc -o memfun memfun.c  -lm
>>   valgrind --tool=massif --massif-out-file=massif.out ./memfun
>>   massif-visualizer massif.out
>>   (or ms_print massif.out > massif.txt; less massif.txt)
>> */
>> 
>> 
>> int main(void)
>> {
>>    int ii,jj;
>>    int *pt;
>>    int *pt2;
>>    float ac;
>>    int numberOfPeaks = 0;
>> 
>>    for (ii=0;ii<100;ii++) {
>>      /* Allocate some small linearly increasing memory block */
>>      pt = (int *)malloc((1000*ii+1)*sizeof(int));
>>      if (ii%5 == 0) {
>>        /* Allocate some gigantic memory block - but only every 10th
>> iteration */
>>        pt2 = (int *)malloc((1000000)*sizeof(int));
>>        printf("Allocating large memory block\n");
>>        numberOfPeaks++;
>>      } else {
>>        /* Allocate just one element for every 9/10 iteration */
>>        pt2 = (int *)malloc((1)*sizeof(int));
>>      }
>>      /* Put in data and print it */
>>      pt2[0] = ii;
>>      printf("   Found value %i\n",pt2[0]);
>>      /* Free the memory - note that the peak */
>>      free(pt2);
>> 
>>      /* Spend time on "something" - the actual work does not matter*/
>>      ac = 1;
>>      for (jj=0;jj<10000*(1 + ii);jj++) {
>>        ac += sin(jj*0.01) + cos(jj*0.01 + 0.3);
>>      }
>>      printf("   Found dummy value %f\n",ac);
>>      /* Free the memory */
>>      free(pt);
>>    }
>>    printf("I made %i memory peaks\n",numberOfPeaks);
>>    return 0;
>> }
>> 
>> 
>> --
>> Peter Toft <pt...@li...>
>> 
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Valgrind-users mailing list
>> Val...@li...
>> https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Mismatched free/delete with GCC 4.8.3 std::string

[Philippe W. <phi...@sk...>]

On Wed, 2015-06-10 at 19:09 +0100, David Carter wrote:
> Hi,
> 
> 
> I've recently switched over to Valgrind 3.10.1 and I'm now see vast
> numbers of 'mismatched free/delete' type messages all coming from
> std::string shipped with GCC 4.8.3.
> 
> 
> I really don't believe what Valgrind is saying but I'd like to be
> certain.  Firstly, has anyone else seen this behaviour recently and
> secondly what criteria does Valgrind use to determine if a mismatch
> occurred?  Is it possible to print out more information from Valgrind
> about its decision process?
Valgrind memcheck understands 4 types of alloc functions:
malloc/new/new[]/custom
which must be freed by the corresponding free/delete/delete[]/custom
'freeing' function.

Normally, if such a mismatch error is detected, you get the allocation
stack trace and the stack trace at which the non matching freeing is
done. That should normally give enough information.

If not, you can always try to debug your program while running it under
valgrind, using gdb+vgdb.
But it is not clear to me what is missing when you have both
stacktraces.

Philippe
 

Re: [Valgrind-users] Mismatched free/delete with GCC 4.8.3 std::string

[David C. <dc...@gm...>]

Fairly certain, yes.

On Wednesday, June 10, 2015, Brian Budge <bri...@gm...> wrote:

> Are you certain all of your libraries have been recompiled against the
> newer libstdc++?
>
> On Wed, Jun 10, 2015 at 11:09 AM, David Carter <dc...@gm...
> <javascript:;>> wrote:
> > Hi,
> >
> > I've recently switched over to Valgrind 3.10.1 and I'm now see vast
> numbers
> > of 'mismatched free/delete' type messages all coming from std::string
> > shipped with GCC 4.8.3.
> >
> > I really don't believe what Valgrind is saying but I'd like to be
> certain.
> > Firstly, has anyone else seen this behaviour recently and secondly what
> > criteria does Valgrind use to determine if a mismatch occurred?  Is it
> > possible to print out more information from Valgrind about its decision
> > process?
> >
> > Many thanks,
> > David.
> >
> >
> ------------------------------------------------------------------------------
> >
> > _______________________________________________
> > Valgrind-users mailing list
> > Val...@li... <javascript:;>
> > https://lists.sourceforge.net/lists/listinfo/valgrind-users
> >
>

Re: [Valgrind-users] helgrind use more than 32G memory.

[Philippe W. <phi...@sk...>]

On Wed, 2015-06-10 at 19:17 +0800, 王阳 wrote:
> My answer is that helgrind really need more than 6 times or even more
> memory than before ,is that true?
> or helgrind have a bug?
The memory needed by helgrind might depend on what your program does.
Typically, it needs twice the original, but it might be a lot more.

Which version of Valgrind are you using ?
In the SVN version, some memory improvements have been done.

The best is to get the latest SVN version, compile it,
then run with --stats=yes.

That will give some indications where the memory is taken.
More detailed information can also be obtained by using
 --profile-heap=yes

Philippe

Re: [Valgrind-users] Mismatched free/delete with GCC 4.8.3 std::string

[Brian B. <bri...@gm...>]

Are you certain all of your libraries have been recompiled against the
newer libstdc++?

On Wed, Jun 10, 2015 at 11:09 AM, David Carter <dc...@gm...> wrote:
> Hi,
>
> I've recently switched over to Valgrind 3.10.1 and I'm now see vast numbers
> of 'mismatched free/delete' type messages all coming from std::string
> shipped with GCC 4.8.3.
>
> I really don't believe what Valgrind is saying but I'd like to be certain.
> Firstly, has anyone else seen this behaviour recently and secondly what
> criteria does Valgrind use to determine if a mismatch occurred?  Is it
> possible to print out more information from Valgrind about its decision
> process?
>
> Many thanks,
> David.
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>

[Valgrind-users] Mismatched free/delete with GCC 4.8.3 std::string

[David C. <dc...@gm...>]

Hi,

I've recently switched over to Valgrind 3.10.1 and I'm now see vast numbers
of 'mismatched free/delete' type messages all coming from std::string
shipped with GCC 4.8.3.

I really don't believe what Valgrind is saying but I'd like to be certain.
Firstly, has anyone else seen this behaviour recently and secondly what
criteria does Valgrind use to determine if a mismatch occurred?  Is it
possible to print out more information from Valgrind about its decision
process?

Many thanks,
David.

[Valgrind-users] helgrind use more than 32G memory.

[王阳 <412...@qq...>]

hello，
  
 I noticed that Valgrind maybe use memory  more than  twice  orignal memory that program  need in your guide,
 Now I got a error from valgrind which hint me that I have use more 32G  memory on
 64-bit platform, My program orginally use 5G memory ,when I use helgrind to  analyze
 my program, I found it really used more than 32G memory(use top -p pid to  see)，
 My answer is that helgrind really need more than 6 times or even more memory than before ,is  that true?
 or helgrind have a bug?



By the way ,my program have used  mmap  function.

Re: [Valgrind-users] How to track memory peaks with Massif (or other tools)

[Konstantin T. <an...@ya...>]

08.06.2015, 15:10, "Peter Toft" <pt...@li...>:
> Hi guys
>
> I have some C/C++ programs that use very odd memory usage. I have made a
> small replica below
> (it can also be taken from http://pastebin.com/1ammgpCE)
> Save e.g. as memfun.c
>
> In the C-code I generate 20 peaks of very short memory peaks, and you
> can compile (on Linux) and run as this:
>     gcc -o memfun memfun.c -lm
>     valgrind --tool=massif --massif-out-file=massif.out ./memfun
>     massif-visualizer massif.out
> or
>     ms_print massif.out > massif.txt; less massif.txt)
>
> (BTW; Thanx to the maintainers of massif-visualizer - this rocks)
>
> However with the standard settings I only get 3 memory peaks detected -
> not 20.
> Obviously I can tweak --threshold= and --peak-inaccuracy= but it seems
> that
> I in general can be sure that I can catch all peaks. Please comment :-)
>
> Are these something that I miss here? Are there other tools that are
> better suited for
> detecting memory peaks like this memory-hedgehog....


Use --time-unit=B


>
> Thanx mates
>
> Best
>
> Peter
>
> ----------------
> #include <stdio.h>
> #include <stdlib.h>
> #include <math.h>
>
> /*
> Demo program:
>   gcc -o memfun memfun.c -lm
>   valgrind --tool=massif --massif-out-file=massif.out ./memfun
>   massif-visualizer massif.out
>   (or ms_print massif.out > massif.txt; less massif.txt)
> */
>
> int main(void)
> {
>    int ii,jj;
>    int *pt;
>    int *pt2;
>    float ac;
>    int numberOfPeaks = 0;
>
>    for (ii=0;ii<100;ii++) {
>      /* Allocate some small linearly increasing memory block */
>      pt = (int *)malloc((1000*ii+1)*sizeof(int));
>      if (ii%5 == 0) {
>        /* Allocate some gigantic memory block - but only every 10th
> iteration */
>        pt2 = (int *)malloc((1000000)*sizeof(int));
>        printf("Allocating large memory block\n");
>        numberOfPeaks++;
>      } else {
>        /* Allocate just one element for every 9/10 iteration */
>        pt2 = (int *)malloc((1)*sizeof(int));
>      }
>      /* Put in data and print it */
>      pt2[0] = ii;
>      printf(" Found value %i\n",pt2[0]);
>      /* Free the memory - note that the peak */
>      free(pt2);
>
>      /* Spend time on "something" - the actual work does not matter*/
>      ac = 1;
>      for (jj=0;jj<10000*(1 + ii);jj++) {
>        ac += sin(jj*0.01) + cos(jj*0.01 + 0.3);
>      }
>      printf(" Found dummy value %f\n",ac);
>      /* Free the memory */
>      free(pt);
>    }
>    printf("I made %i memory peaks\n",numberOfPeaks);
>    return 0;
> }
>
> --
> Peter Toft <pt...@li...>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users

-- 
Regards,
Konstantin

Re: [Valgrind-users] How to track memory peaks with Massif (or other tools)

[Peter B. <bo...@gm...>]

heaptrack (http://milianw.de/blog/heaptrack-a-heap-memory-profiler-for-linux)
should be perfect for this. It shows a lovely 20-spike graph when
combined with massif-vizualiser: http://i.imgur.com/Q7cXF8N.png

Regards,
-- 
Peter Bortas


On Mon, Jun 8, 2015 at 1:50 PM, Peter Toft <pt...@li...> wrote:
> Hi guys
>
> I have some C/C++ programs that use very odd memory usage. I have made a
> small replica below
> (it can also be taken from http://pastebin.com/1ammgpCE)
> Save e.g. as memfun.c
>
> In the C-code I generate 20 peaks of very short memory peaks, and you
> can compile (on Linux) and run as this:
>     gcc -o memfun memfun.c  -lm
>     valgrind --tool=massif --massif-out-file=massif.out ./memfun
>     massif-visualizer massif.out
> or
>     ms_print massif.out > massif.txt; less massif.txt)
>
> (BTW; Thanx to the maintainers of massif-visualizer - this rocks)
>
>
> However with the standard settings I only get 3 memory peaks detected -
> not 20.
> Obviously I can tweak --threshold= and --peak-inaccuracy= but it seems
> that
> I in general can be sure that I can catch all peaks. Please comment :-)
>
> Are these something that I miss here? Are there other tools that are
> better suited for
> detecting memory peaks like this memory-hedgehog....
>
> Thanx mates
>
> Best
>
> Peter
>
> ----------------
> #include <stdio.h>
> #include <stdlib.h>
> #include <math.h>
>
> /*
> Demo program:
>   gcc -o memfun memfun.c  -lm
>   valgrind --tool=massif --massif-out-file=massif.out ./memfun
>   massif-visualizer massif.out
>   (or ms_print massif.out > massif.txt; less massif.txt)
> */
>
>
> int main(void)
> {
>    int ii,jj;
>    int *pt;
>    int *pt2;
>    float ac;
>    int numberOfPeaks = 0;
>
>    for (ii=0;ii<100;ii++) {
>      /* Allocate some small linearly increasing memory block */
>      pt = (int *)malloc((1000*ii+1)*sizeof(int));
>      if (ii%5 == 0) {
>        /* Allocate some gigantic memory block - but only every 10th
> iteration */
>        pt2 = (int *)malloc((1000000)*sizeof(int));
>        printf("Allocating large memory block\n");
>        numberOfPeaks++;
>      } else {
>        /* Allocate just one element for every 9/10 iteration */
>        pt2 = (int *)malloc((1)*sizeof(int));
>      }
>      /* Put in data and print it */
>      pt2[0] = ii;
>      printf("   Found value %i\n",pt2[0]);
>      /* Free the memory - note that the peak */
>      free(pt2);
>
>      /* Spend time on "something" - the actual work does not matter*/
>      ac = 1;
>      for (jj=0;jj<10000*(1 + ii);jj++) {
>        ac += sin(jj*0.01) + cos(jj*0.01 + 0.3);
>      }
>      printf("   Found dummy value %f\n",ac);
>      /* Free the memory */
>      free(pt);
>    }
>    printf("I made %i memory peaks\n",numberOfPeaks);
>    return 0;
> }
>
>
> --
> Peter Toft <pt...@li...>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users

[Valgrind-users] How to track memory peaks with Massif (or other tools)

[Peter T. <pt...@li...>]

Hi guys

I have some C/C++ programs that use very odd memory usage. I have made a 
small replica below
(it can also be taken from http://pastebin.com/1ammgpCE)
Save e.g. as memfun.c

In the C-code I generate 20 peaks of very short memory peaks, and you 
can compile (on Linux) and run as this:
    gcc -o memfun memfun.c  -lm
    valgrind --tool=massif --massif-out-file=massif.out ./memfun
    massif-visualizer massif.out
or
    ms_print massif.out > massif.txt; less massif.txt)

(BTW; Thanx to the maintainers of massif-visualizer - this rocks)


However with the standard settings I only get 3 memory peaks detected - 
not 20.
Obviously I can tweak --threshold= and --peak-inaccuracy= but it seems 
that
I in general can be sure that I can catch all peaks. Please comment :-)

Are these something that I miss here? Are there other tools that are 
better suited for
detecting memory peaks like this memory-hedgehog....

Thanx mates

Best

Peter

----------------
#include <stdio.h>
#include <stdlib.h>
#include <math.h>

/*
Demo program:
  gcc -o memfun memfun.c  -lm
  valgrind --tool=massif --massif-out-file=massif.out ./memfun
  massif-visualizer massif.out
  (or ms_print massif.out > massif.txt; less massif.txt)
*/


int main(void)
{
   int ii,jj;
   int *pt;
   int *pt2;
   float ac;
   int numberOfPeaks = 0;

   for (ii=0;ii<100;ii++) {
     /* Allocate some small linearly increasing memory block */
     pt = (int *)malloc((1000*ii+1)*sizeof(int));
     if (ii%5 == 0) {
       /* Allocate some gigantic memory block - but only every 10th 
iteration */
       pt2 = (int *)malloc((1000000)*sizeof(int));
       printf("Allocating large memory block\n");
       numberOfPeaks++;
     } else {
       /* Allocate just one element for every 9/10 iteration */
       pt2 = (int *)malloc((1)*sizeof(int));
     }
     /* Put in data and print it */
     pt2[0] = ii;
     printf("   Found value %i\n",pt2[0]);
     /* Free the memory - note that the peak */
     free(pt2);

     /* Spend time on "something" - the actual work does not matter*/
     ac = 1;
     for (jj=0;jj<10000*(1 + ii);jj++) {
       ac += sin(jj*0.01) + cos(jj*0.01 + 0.3);
     }
     printf("   Found dummy value %f\n",ac);
     /* Free the memory */
     free(pt);
   }
   printf("I made %i memory peaks\n",numberOfPeaks);
   return 0;
}


-- 
Peter Toft <pt...@li...>

Re: [Valgrind-users] SVN trouble

[Philippe W. <phi...@sk...>]

On Sun, 2015-06-07 at 12:03 +0000, Andrei F wrote:
> 
> Hi guys,
> 
> 
> I cannot connect to svn.valgrind.org. It just  refuses connections. 
> Should it be still accessible?
For me, it works.
Philippe

Re: [Valgrind-users] SVN trouble

[Andrei F <an...@ho...>]

Hi guys,
I cannot connect to svn.valgrind.org. It just  refuses connections. Should it be still accessible?
Thanks,AndreiF
 		 	   		   		 	   		  

Re: [Valgrind-users] Valgrind with dynamically linked GCC plugin

[Philippe W. <phi...@sk...>]

On Thu, 2015-06-04 at 16:08 +0530, Suryansh Kumar wrote:
> Is it even possible to use valgrind on the plugin? I've searched up on
> this a lot but haven't found any concrete answer on it.
Yes, valgrind works with dynamically loaded .so

I guess that the plugin is not loaded by gcc itself, but rather by
a child process of gcc.
Then, you have to use --trace-children=yes to trace the children of gcc.

Philippe

[Valgrind-users] Valgrind with dynamically linked GCC plugin

[Suryansh K. <sur...@gm...>]

I want to use Valgrind on a dynamically linked GCC plugin, and use
massif to find the heap usage and Callgrind to view the callgraph
showing each function used in the plugin. I am running the GCC plugin
as follows:

$    gcc -fplugin=./plugin.so myfile.c

When I run the following command, valgrind reports the memory leaks
for only gcc and not for plugin.so. I need a way to run valgrind
exclusively on my plugin, which is a .so file.


$    valgrind gcc -fplugin=./plugin.so myfile.c

$    gcc -fplugin=./plugin.so myfile.c -wrapper valgrind

I specifically introduced some memory leaks in the plugin and it they
were not caught by valgrind. No memory allocations were shown in
massif too.

Preloading the plugin using LD_PRELOAD doesn't work.

Is it even possible to use valgrind on the plugin? I've searched up on
this a lot but haven't found any concrete answer on it.

Re: [Valgrind-users] Statically linked executables and memcheck

[Philippe W. <phi...@sk...>]

On Sun, 2015-05-31 at 17:55 +0200, Joakim Sindholt wrote:
> I would like to be able to run memcheck on statically linked binaries,
> so I had a look at:
> http://valgrind.org/docs/manual/faq.html#faq.hiddenbug
> 
> "Second, if your program is statically linked, most Valgrind tools will
> only work well if they are able to replace certain functions, such as
> malloc, with their own versions. By default, statically linked malloc
> functions are not replaced. A key indicator of this is if Memcheck says:
> 
> All heap blocks were freed -- no leaks are possible
> 
> when you know your program calls malloc. The workaround is to use the
> option --soname-synonyms=somalloc=NONE or to avoid statically linking
> your program"
> 
> I couldn't get it to work so here's a minimal example that illustrates
> the problem:
malloc/free replacement will be done for a statically linked malloc
library.
But the dynamic linker is still needed for that replacement to work.

I have since a long time an idea in a corner to make all this
working on fully statically linked executable.

But too many ideas, not enough time ...

Philippe

[Valgrind-users] Statically linked executables and memcheck

[Joakim S. <ope...@zh...>]

I would like to be able to run memcheck on statically linked binaries,
so I had a look at:
http://valgrind.org/docs/manual/faq.html#faq.hiddenbug

"Second, if your program is statically linked, most Valgrind tools will
only work well if they are able to replace certain functions, such as
malloc, with their own versions. By default, statically linked malloc
functions are not replaced. A key indicator of this is if Memcheck says:

All heap blocks were freed -- no leaks are possible

when you know your program calls malloc. The workaround is to use the
option --soname-synonyms=somalloc=NONE or to avoid statically linking
your program"

I couldn't get it to work so here's a minimal example that illustrates
the problem:

#include <stdlib.h>

int main(void)
{
    int *p = malloc(sizeof(*p));
    *p = 0;
    free(NULL);
    return 0;
}

Compiled without optimization gives:

0000000000400120 <main>:
  400120:       55                      push   %rbp
  400121:       48 89 e5                mov    %rsp,%rbp
  400124:       48 83 ec 10             sub    $0x10,%rsp
  400128:       b8 04 00 00 00          mov    $0x4,%eax
  40012d:       89 c7                   mov    %eax,%edi
  40012f:       c7 45 fc 00 00 00 00    movl   $0x0,-0x4(%rbp)
  400136:       e8 91 02 00 00          callq  4003cc <malloc>
  40013b:       31 c9                   xor    %ecx,%ecx
  40013d:       89 cf                   mov    %ecx,%edi
  40013f:       48 89 45 f0             mov    %rax,-0x10(%rbp)
  400143:       48 8b 45 f0             mov    -0x10(%rbp),%rax
  400147:       c7 00 00 00 00 00       movl   $0x0,(%rax)
  40014d:       e8 d4 09 00 00          callq  400b26 <free>
  400152:       31 c0                   xor    %eax,%eax
  400154:       48 83 c4 10             add    $0x10,%rsp
  400158:       5d                      pop    %rbp
  400159:       c3                      retq
  40015a:       66 90                   xchg   %ax,%ax

readelf gives us:

Symbol table '.symtab' contains 120 entries:
   Num:    Value          Size Type    Bind   Vis      Ndx Name
     0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND
...
    78: 0000000000400b26   584 FUNC    GLOBAL DEFAULT    2 free
    79: 00000000004003cc   387 FUNC    GLOBAL DEFAULT    2 malloc
...

And when running valgrind (svn co roughly 10 minutes ago) on it:

==833670== Memcheck, a memory error detector
==833670== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==833670== Using Valgrind-3.11.0.SVN and LibVEX; rerun with -h for copyright info
==833670== Command: ./6.out
==833670==
--833670-- Valgrind options:
--833670--    --soname-synonyms=somalloc=NONE
--833670--    -v
--833670-- Contents of /proc/version:
--833670--   Linux version 3.17.7-gentoo (root@wirbelwind) (gcc version 4.8.3 (Gentoo 4.8.3 p1.1, pie-0.5.9) ) #2 SMP Tue Jan 27 22:22:13 CET 2015
--833670--
--833670-- Arch and hwcaps: AMD64, LittleEndian, amd64-cx16-rdtscp-sse3-avx
--833670-- Page sizes: currently 4096, max supported 4096
--833670-- Valgrind library directory: /home/zhasha/./valgrind/.in_place
--833670-- Reading syms from /home/zhasha/6.out
--833670--    object doesn't have a dynamic symbol table
--833670-- warning: DiCfSI 0x0 .. 0x0 outside mapped rx segments (NONE)
--833670-- warning: DiCfSI 0x1 .. 0x3 outside mapped rx segments (NONE)
--833670-- warning: DiCfSI 0x4 .. 0x9 outside mapped rx segments (NONE)
--833670-- warning: DiCfSI 0xa .. 0xec outside mapped rx segments (NONE)
--833670-- warning: DiCfSI 0x0 .. 0x0 outside mapped rx segments (NONE)
--833670-- warning: DiCfSI 0x1 .. 0x3 outside mapped rx segments (NONE)
--833670-- warning: DiCfSI 0x4 .. 0x6 outside mapped rx segments (NONE)
--833670-- warning: DiCfSI 0x7 .. 0x48 outside mapped rx segments (NONE)
--833670-- warning: DiCfSI 0x49 .. 0x49 outside mapped rx segments (NONE)
--833670-- warning: DiCfSI 0x4a .. 0x4c outside mapped rx segments (NONE)
--833670-- Reading syms from /home/zhasha/valgrind/memcheck/memcheck-amd64-linux
--833670--    object doesn't have a dynamic symbol table
--833670-- Scheduler: using generic scheduler lock implementation.
--833670-- Reading suppressions file: /home/zhasha/./valgrind/.in_place/default.supp
==833670== embedded gdbserver: reading from /tmp/vgdb-pipe-from-vgdb-to-833670-by-zhasha-on-???
==833670== embedded gdbserver: writing to   /tmp/vgdb-pipe-to-vgdb-from-833670-by-zhasha-on-???
==833670== embedded gdbserver: shared mem   /tmp/vgdb-pipe-shared-mem-vgdb-833670-by-zhasha-on-???
==833670==
==833670== TO CONTROL THIS PROCESS USING vgdb (which you probably
==833670== don't want to do, unless you know exactly what you're doing,
==833670== or are doing some strange experiment):
==833670==   /home/zhasha/./valgrind/.in_place/../../bin/vgdb --pid=833670 ...command...
==833670==
==833670== TO DEBUG THIS PROCESS USING GDB: start GDB like this
==833670==   /path/to/gdb ./6.out
==833670== and then give GDB the following command
==833670==   target remote | /home/zhasha/./valgrind/.in_place/../../bin/vgdb --pid=833670
==833670== --pid is optional if only one valgrind process is running
==833670==
==833670==
==833670== HEAP SUMMARY:
==833670==     in use at exit: 0 bytes in 0 blocks
==833670==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==833670==
==833670== All heap blocks were freed -- no leaks are possible
==833670==
==833670== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==833670== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

Now, as you can see, there's no indication that malloc and free were
hooked. Am I doing something wrong here? This executable is as
un-stripped as possible. Even the libc has debug symbols. I can't get it
working with musl, nor with glibc (where malloc/free seem to be called
__libc_malloc/__cfree).

-- Joakim

Re: [Valgrind-users] Documentation for callgrind text data file format?

[Dan L. <da...@su...>]

On 29 May 2015 at 17:50, Rocky Bernstein <rb...@du...> wrote:
> I'm looking into adding into the GNU make fork remake
> (http://bashdb.sf.net/remake) profiling using a callgrind file format.
>
> Is there something that describes the format?

There's [1]. It's not complete though, JumpSpecification is missing
which I reported last year. There is some discussion of it on the
mailing list though [2]


[1] http://valgrind.org/docs/manual/cl-format.html
[2] http://valgrind.10908.n7.nabble.com/The-syntax-of-jump-and-jcnd-in-callgrind-profile-files-td51025.html
-- 
Dan Liew
PhD Student - Imperial College London

Re: [Valgrind-users] Documentation for callgrind text data file format?

[Rocky B. <rb...@du...>]

Thanks. This is what I'm looking for.

On Fri, May 29, 2015 at 1:14 PM, Dan Liew <da...@su...> wrote:

> On 29 May 2015 at 17:50, Rocky Bernstein <rb...@du...> wrote:
> > I'm looking into adding into the GNU make fork remake
> > (http://bashdb.sf.net/remake) profiling using a callgrind file format.
> >
> > Is there something that describes the format?
>
> There's [1]. It's not complete though, JumpSpecification is missing
> which I reported last year. There is some discussion of it on the
> mailing list though [2]
>
>
> [1] http://valgrind.org/docs/manual/cl-format.html
> [2]
> http://valgrind.10908.n7.nabble.com/The-syntax-of-jump-and-jcnd-in-callgrind-profile-files-td51025.html
> --
> Dan Liew
> PhD Student - Imperial College London
>