valgrind-users — General discussion list for Valgrind users

Re: [Valgrind-users] hello there is a question about callgrind on the arm64.

[Josef W. <Jos...@gm...>]

Hi Owen,

callgrind currently is somewhat broken on ARM, as the
tracking of entering/leaving functions is unreliable.

Callgrind heavily uses the stack pointer for that.
On x86, this works fine, as every call/return changes
the SP, but on ARM, this is not the case.

There are ideas and at some point, there were
patches promised by someone, but unfortunately nothing
useful up to now...

Josef


Am 12.05.2017 um 05:11 schrieb Wuweijia:
> Hi :
> 
> I ran the code through the callgrind on the x86-64, it is ok , no 
> recursive cycle existed.
> 
> But I ran the same the same code through the callgrind on the arm64, it 
> show me there is recursive cycle existed.
> 
>    Between two callgrind.out. file:
> 
>       In arm64:
> 
>          There is function name main’2. It meaning that there is 
> recursive cycle. And it annote the source failed.
> 
>       In x86_64:
> 
>       There is no  function name  main’2  only main., It mean that there 
> is no cycle.
> 
>       How can I resovle it?
> 
> The compile options : gcc –g –O0 ./main.cpp
> 
> The gcc version 4.9
> 
> Run options: valgrind --tool=callgrind ./a.out
> 
>    Callgrind_annote option callgrind_annote –auto=yes
> 
> BR
> 
> Owen
> 
> 
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> 
> 
> 
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
> 

Re: [Valgrind-users] 答复: hello there is a question about callgrind on the arm64.

[John R. <jr...@bi...>]

> 	Is there any news?

I ran the program in 64-bit mode on Raspberry Pi 3 (1GiB RAM) with:
	kernel-4.9.28-1 (Fedora 25)
	gcc-6.3.1
	glibc-2.24-4.fc25.aarch64
	valgrind-3.12.0 (compiled from .tar.bz2 in one-half hour)

A swap file of 2GiB was not enough:
=====
==22295==     Valgrind's memory management: out of memory:
==22295==        newSuperblock's request for 1835012096 bytes failed.
==22295==        1,247,584,256 bytes have already been mmap-ed ANONYMOUS.
==22295==     Valgrind cannot continue.  Sorry.
=====
A swap file of 4GiB allowed execution to finish:
	# dd if=/dev/zero of=/swap-file bs=1M count=4096
	# chmod 600 /swap-file
	# swapon /swap-file
[Side comment: Requiring more than 3GiB (1GiB RAM plus 2GiB swapspace)
for this small, short program is wildly extravagant by callgrind.]

The execution (several minutes) was:
	gcc  -g  -O0  ./main.cpp
	valgrind  --tool=callgrind  ./a.out
	callgrind_annotate  --auto=yes  callgrind.out.PID  main.cpp

The complete output from callgrind_annotate is attached (callgrind_annotate.out,
4.5 kB).  I see lines such as
=====
10,485,720  char getCommon2(char * argv) {
   5,242,860      char result = 0;
  15,728,580      result = argv[0];
  94,371,480      for(int i = 0; i < 2; i++ ) {
          34  => ./main.cpp:getCommon2(char*)'2 (1x)
  52,428,600           if( argv[1] > 20 ) {
=====
This suggests to me that callgrind's code which discovers tracebacks
has a problem, because there is no subroutine call anywhere in getCommon2,
yet callgrind thinks that getCommon2 called itself [recursively].
I have not looked carefully at what is happening.

-- 

[Valgrind-users] 答复: hello there is a question about callgrind on the arm64.

[Wuweijia <wuw...@hu...>]

Hi:
	Is there any news?

BR
Owen

-----邮件原件-----
发件人: Wuweijia 
发送时间: 2017年5月12日 12:40
收件人: 'John Reiser' <jr...@bi...>; val...@li...
抄送: Fanbohao <fan...@hu...>
主题: 答复: [Valgrind-users] hello there is a question about callgrind on the arm64.


#include <stdio.h>
#include <stdlib.h>
#include <string.h>

char getCommon(char * argv) {
    char result = 0;
    result = argv[0];
    for(int i = 0; i < 2; i++ ) {
         if( argv[1] > 100 ) {
            result += argv[1] + 10;
         }

         if( argv[2] < 30 ) {
            result += argv[2] * 2;
         }
    }    

    return result;
}

char getCommon2(char * argv) {
    char result = 0;
    result = argv[0];
    for(int i = 0; i < 2; i++ ) { 
         if( argv[1] > 20 ) { 
            result += argv[1] + 10; 
         }   

         if( argv[2] < 110 ) { 
            result += argv[2] * 3;
         }   
    }    

    return result;
}


int main(int argc, char ** argv) {
    unsigned long i = 0;
    char * p = (char *)malloc(1024 * 1024);
    memset(p, 1, 1024 * 1024); 

    
   for(int i = 0; i < 10; i++ ) {
       for(int j = 0; j < 1024 * 1024 - 3; j++) {
            if(j % 2 == 0) { 
              p[j] = getCommon(p + j);
            } else {
              p[j] = getCommon2(p + j);
            }
       }
        memset(p, 1, 1024 * 1024);
   }
   printf("p=%p\n", p); 
    return 0;
}
-----邮件原件-----
发件人: John Reiser [mailto:jr...@bi...] 
发送时间: 2017年5月12日 11:18
收件人: val...@li...
主题: Re: [Valgrind-users] hello there is a question about callgrind on the arm64.

>       In arm64:
> 
>          There is function name main’2. It meaning that there is recursive cycle. And it annote the source failed.
> 
>       In x86_64:
> 
>       There is no  function name  main’2  only main., It mean that there is no cycle.
> 
>       How can I resolve it?

Post here the source code to the smallest (shortest) program which does not behave like you expect.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________
Valgrind-users mailing list
Val...@li...
https://lists.sourceforge.net/lists/listinfo/valgrind-users

[Valgrind-users] 答复: hello there is a question about callgrind on the arm64.

[Wuweijia <wuw...@hu...>]

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

char getCommon(char * argv) {
    char result = 0;
    result = argv[0];
    for(int i = 0; i < 2; i++ ) {
         if( argv[1] > 100 ) {
            result += argv[1] + 10;
         }

         if( argv[2] < 30 ) {
            result += argv[2] * 2;
         }
    }    

    return result;
}

char getCommon2(char * argv) {
    char result = 0;
    result = argv[0];
    for(int i = 0; i < 2; i++ ) { 
         if( argv[1] > 20 ) { 
            result += argv[1] + 10; 
         }   

         if( argv[2] < 110 ) { 
            result += argv[2] * 3;
         }   
    }    

    return result;
}


int main(int argc, char ** argv) {
    unsigned long i = 0;
    char * p = (char *)malloc(1024 * 1024);
    memset(p, 1, 1024 * 1024); 

    
   for(int i = 0; i < 10; i++ ) {
       for(int j = 0; j < 1024 * 1024 - 3; j++) {
            if(j % 2 == 0) { 
              p[j] = getCommon(p + j);
            } else {
              p[j] = getCommon2(p + j);
            }
       }
        memset(p, 1, 1024 * 1024);
   }
   printf("p=%p\n", p); 
    return 0;
}
-----邮件原件-----
发件人: John Reiser [mailto:jr...@bi...] 
发送时间: 2017年5月12日 11:18
收件人: val...@li...
主题: Re: [Valgrind-users] hello there is a question about callgrind on the arm64.

>       In arm64:
> 
>          There is function name main’2. It meaning that there is recursive cycle. And it annote the source failed.
> 
>       In x86_64:
> 
>       There is no  function name  main’2  only main., It mean that there is no cycle.
> 
>       How can I resolve it?

Post here the source code to the smallest (shortest) program which does not behave like you expect.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________
Valgrind-users mailing list
Val...@li...
https://lists.sourceforge.net/lists/listinfo/valgrind-users

[Valgrind-users] 答复: hello there is a question about callgrind on the arm64.

[Wuweijia <wuw...@hu...>]

The source code(main.cpp) is in the my.rar. and the callgrind output are also in the my.rar.

Did you never receive it ?



-----邮件原件-----
发件人: John Reiser [mailto:jr...@bi...] 
发送时间: 2017年5月12日 11:18
收件人: val...@li...
主题: Re: [Valgrind-users] hello there is a question about callgrind on the arm64.

>       In arm64:
> 
>          There is function name main’2. It meaning that there is recursive cycle. And it annote the source failed.
> 
>       In x86_64:
> 
>       There is no  function name  main’2  only main., It mean that there is no cycle.
> 
>       How can I resolve it?

Post here the source code to the smallest (shortest) program which does not behave like you expect.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________
Valgrind-users mailing list
Val...@li...
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] hello there is a question about callgrind on the arm64.

[John R. <jr...@bi...>]

>       In arm64:
> 
>          There is function name main’2. It meaning that there is recursive cycle. And it annote the source failed.
> 
>       In x86_64:
> 
>       There is no  function name  main’2  only main., It mean that there is no cycle.
> 
>       How can I resolve it?

Post here the source code to the smallest (shortest) program which does not behave like you expect.

[Valgrind-users] hello there is a question about callgrind on the arm64.

[Wuweijia <wuw...@hu...>]

Hi :
I ran the code through the callgrind on the x86-64, it is ok , no recursive cycle existed.
But I ran the same the same code through the callgrind on the arm64, it show me there is recursive cycle existed.


  Between two callgrind.out. file:
     In arm64:
        There is function name main'2. It meaning that there is recursive cycle. And it annote the source failed.
     In x86_64:
     There is no  function name  main'2  only main., It mean that there is no cycle.

     How can I resovle it?

The compile options : gcc -g -O0 ./main.cpp

The gcc version 4.9

Run options: valgrind --tool=callgrind ./a.out

  Callgrind_annote option callgrind_annote -auto=yes


BR
Owen

Re: [Valgrind-users] 答复: I ran the callgrind_annotate to create the report . but it failed (in the read). Can you tell me Why?

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

This looks like a bug.
The best is to file a bug on bugzilla, and attach (preferrably) a small
reproducer.

Alternatively, it might be good enough to just attach the callgrind
output file and the source file to run the callgrind_annotate command.

Note that in the meantime, you might try kcachegrind, and see if
kcachegrind is able to read the callgrind file, and show in the
source tab the below cpp file.

Philippe

On Tue, 2017-05-09 at 10:31 +0000, Wuweijia wrote:
> Help, any guy can help me?
> 
>  
> 
> Do you need any information. Just tell me.
> 
>  
> 
> 发件人: Wuweijia 
> 发送时间: 2017年5月8日 17:55
> 收件人: val...@li...
> 抄送: Fanbohao <fan...@hu...>
> 主题: I ran the callgrind_annotate to create the report . but it
> failed (in the read). Can you tell me Why?
> 
> 
>  
> 
> $  callgrind_annotate --threshold=20 --auto=yes --tree=caller
> --auto=yes
>  ./callgrind.out.7732 /cloud/jmaster/ndk_wwj/00.Trunk/Beauty_cmd/core/build/ndk/jni/../../../source/guidedfilter.cpp
> 
> --------------------------------------------------------------------------------
> 
> Profile data file './callgrind.out.7732' (creator: callgrind-3.12.0)
> 
> --------------------------------------------------------------------------------
> 
> I1 cache: 
> 
> D1 cache: 
> 
> LL cache: 
> 
> Timerange: Basic block 0 - 2745879511
> 
> Trigger: Program termination
> 
> Profiled target:  ./beautyALL
> --gtest_filter=FACEBEAUTY_HWA_TEST_PQ.*001_001* (PID 7732, part 1)
> 
> Events recorded:  Ir
> 
> Events shown:     Ir
> 
> Event sort order: Ir
> 
> Thresholds:       20
> 
> Include dirs:     
> 
> User
> annotated:   /cloud/jmaster/ndk_wwj/00.Trunk/Beauty_cmd/core/build/ndk/jni/../../../source/guidedfilter.cpp
> 
> Auto-annotation:  on
> 
>  
> 
> --------------------------------------------------------------------------------
> 
>             Ir 
> 
> --------------------------------------------------------------------------------
> 
> 54,072,323,868  PROGRAM TOTALS
> 
>  
> 
> --------------------------------------------------------------------------------
> 
>            Ir  file:function
> 
> --------------------------------------------------------------------------------
> 
>  
> 
> 7,631,025,535  < ???:GF_mem_core_2(unsigned char const*, int, int,
> int, unsigned int, signed char, unsigned char*, int, int, unsigned
> short*, unsigned short*) (2x)
> 
> 150,733,822,449,168,850  < ???:GF_mem_core_2(unsigned char const*,
> int, int, int, unsigned int, signed char, unsigned char*, int, int,
> unsigned short*, unsigned short*)'2 (72837764x)
> 
> 7,631,015,516  *  ???:GF_mem_core_2(unsigned char const*, int, int,
> int, unsigned int, signed char, unsigned char*, int, int, unsigned
> short*, unsigned short*)'2
> 
>  
> 
> 50,453,349,559,163,015  < ???:GF_mem_core_1(unsigned char const*, int,
> int, int, int, signed char, unsigned char*, int, int, unsigned short*,
> unsigned short*)'2 (49096266x)
> 
> 5,290,859,433  *  ???:GF_mem_core_1(unsigned char const*, int, int,
> int, int, signed char, unsigned char*, int, int, unsigned short*,
> unsigned short*)'2
> 
>  
> 
> --------------------------------------------------------------------------------
> 
> -- User-annotated
> source: /cloud/jmaster/ndk_wwj/00.Trunk/Beauty_cmd/core/build/ndk/jni/../../../source/guidedfilter.cpp
> 
> --------------------------------------------------------------------------------
> 
>      Ir 
> 
>  
> 
> Use of uninitialized value $pairs[0] in numeric lt (<)
> at /usr/local/bin/callgrind_annotate line 1136.
> 
> Use of uninitialized value $high in numeric lt (<)
> at /usr/local/bin/callgrind_annotate line 1147.
> 
>  
> 
> 584,638  <counts for unidentified lines
> in /cloud/jmaster/ndk_wwj/00.Trunk/Beauty_cmd/core/build/ndk/jni/../../../source/guidedfilter.cpp>
> 
>  
> 
> Use of uninitialized value in division (/)
> at /usr/local/bin/callgrind_annotate line 1218.
> 
> --------------------------------------------------------------------------------
> 
> Ir 
> 
> --------------------------------------------------------------------------------
> 
> 0  percentage of events annotated
> 
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________ Valgrind-users mailing list Val...@li... https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Clarification on functions in pub_tool_tooliface.h

[Siddharth N. <si...@gm...>]

Oops. I started typing my response and then decided to respond inline.
Forgot to delete my partial original response. :)

On 9 May 2017 at 12:36, Siddharth Nilakantan <si...@gm...> wrote:

> Hi Ivo,
>
> The goal is to get at the
>
> Thanks,
> Sid
>
> On 9 May 2017 at 00:48, Ivo Raisr <iv...@iv...> wrote:
>
>> 2017-05-08 20:39 GMT+02:00 Siddharth Nilakantan <si...@gm...>:
>> > Hi Mike and Ivo,
>> >
>> > I noticed a thread where you guys had a discussion going.
>> >
>> > https://sourceforge.net/p/valgrind/mailman/message/35687503/
>> >
>> > I was playing around with writing a tool that does some online analysis
>> of
>> > register reads/writes. Basically, the tool needs to know every register
>> > read/write performed by the user program.
>>
>> Hi Sid,
>>
>> What is the ultimate goal of your analysis tool?
>
>
> I want to discover the critical paths in different phases of a program,
> the first step of which is to able to build paths.
>
>
>> > Due to minor ambiguity in the  documentation (both in the code and the
>> PLDI paper), I discovered the hard
>> > way that VG_(track_post_reg_write) and VG_(track_pre_reg_read) are
>> functions
>> > that are called only around syscalls. I'm guessing that any
>> VG_(track_pre_*)
>> > and VG_(track_post_*) functions occur only around syscalls.
>>
>> Yes, indeed.
>> Every tool also works with the IR (intermediate representation) - this
>> where you
>> can catch (and instrument) register reads and writes.
>>
>> I.
>>
> Yes this is what I had originally started doing. I found it a bit more
> challenging than expected. Iex_Gets represent register reads. The
> instrument function sees a lot of IRExpr* for Load data or Put data, which
> we need to recursively explore to find Iex_Gets...
>

[Valgrind-users] [Help] some question about callgrind_annotate in red and blue.

[Wuweijia <wuw...@hu...>]

I use the callgrind_annotate to analyze the source .  but there are some question in my mind.


3987             .  ^M
3988             .  static ret_status GF_mem_core_2(const UINT8 *guided_Img, INT32 width, INT32 height, INT32 radius, UINT32 eps, INT8 scale_eps, UINT8* out_Img,^M
3989             .      INT32 stride_G, INT32 stride_O, UINT16* out_mean_a, UINT16* out_mean_b)^M
3990            58  {^M
3991            66      if (!guided_Img || radius > width / 2 || radius > height / 2)^M
3992             .      {^M
3993             .          ALGLOGE("Parameters Error!");^M
3994             .          return retStsParameterInvalid;^M
3995             .      }^M
3996             .  ^M
3997            12      UINT8 filter_w = (radius << 1) + 1;^M
3998            12      UINT16 sum_count = filter_w*filter_w;^M
3999             .  ^M
4000             4      const int scale_left = 10;^M
4001             .  ^M
4002             4      const int scale_ab = 10;^M
4003             .  ^M
4004             4      int scale_tmp = 4;^M
4005             6      if (filter_w <= 31)^M
4006             .      {^M
4007            20          scale_tmp = 4;^M  ///It mean how many instructions in this line. But I do not known what it mean for the number 7,631,025,535 in the next line? can you show me some tips.
4008 7,631,025,535  => /cloud/jmaster/ndk_wwj/00.Trunk/Beauty_cmd/core/build/ndk/jni/../../../source/guidedfilter.cpp:GF_mem_core_2(unsigned char const*, int, int, int, uns     igned int, signed char, unsigned char*, int, int, unsigned short*, unsigned short*)'2 (2x)
4009             .      }^M
4010             .      else if (filter_w > 31 && filter_w <= 37)^M
4011             .      {^M
4012             .          scale_tmp = 5;^M
4013             .      }^M
4014             .      else//up to 45^M
4015             .      {^M
4016             .          scale_tmp = 6;^M

[Valgrind-users] 答复: I ran the callgrind_annotate to create the report . but it failed (in the read). Can you tell me Why?

[Wuweijia <wuw...@hu...>]

Help, any guy can help me?

Do you need any information. Just tell me.

发件人: Wuweijia
发送时间: 2017年5月8日 17:55
收件人: val...@li...
抄送: Fanbohao <fan...@hu...>
主题: I ran the callgrind_annotate to create the report . but it failed (in the read). Can you tell me Why?

$  callgrind_annotate --threshold=20 --auto=yes --tree=caller --auto=yes  ./callgrind.out.7732 /cloud/jmaster/ndk_wwj/00.Trunk/Beauty_cmd/core/build/ndk/jni/../../../source/guidedfilter.cpp
--------------------------------------------------------------------------------
Profile data file './callgrind.out.7732' (creator: callgrind-3.12.0)
--------------------------------------------------------------------------------
I1 cache:
D1 cache:
LL cache:
Timerange: Basic block 0 - 2745879511
Trigger: Program termination
Profiled target:  ./beautyALL --gtest_filter=FACEBEAUTY_HWA_TEST_PQ.*001_001* (PID 7732, part 1)
Events recorded:  Ir
Events shown:     Ir
Event sort order: Ir
Thresholds:       20
Include dirs:
User annotated:   /cloud/jmaster/ndk_wwj/00.Trunk/Beauty_cmd/core/build/ndk/jni/../../../source/guidedfilter.cpp
Auto-annotation:  on

--------------------------------------------------------------------------------
            Ir
--------------------------------------------------------------------------------
54,072,323,868  PROGRAM TOTALS

--------------------------------------------------------------------------------
           Ir  file:function
--------------------------------------------------------------------------------

7,631,025,535  < ???:GF_mem_core_2(unsigned char const*, int, int, int, unsigned int, signed char, unsigned char*, int, int, unsigned short*, unsigned short*) (2x)
150,733,822,449,168,850  < ???:GF_mem_core_2(unsigned char const*, int, int, int, unsigned int, signed char, unsigned char*, int, int, unsigned short*, unsigned short*)'2 (72837764x)
7,631,015,516  *  ???:GF_mem_core_2(unsigned char const*, int, int, int, unsigned int, signed char, unsigned char*, int, int, unsigned short*, unsigned short*)'2

50,453,349,559,163,015  < ???:GF_mem_core_1(unsigned char const*, int, int, int, int, signed char, unsigned char*, int, int, unsigned short*, unsigned short*)'2 (49096266x)
5,290,859,433  *  ???:GF_mem_core_1(unsigned char const*, int, int, int, int, signed char, unsigned char*, int, int, unsigned short*, unsigned short*)'2

--------------------------------------------------------------------------------
-- User-annotated source: /cloud/jmaster/ndk_wwj/00.Trunk/Beauty_cmd/core/build/ndk/jni/../../../source/guidedfilter.cpp
--------------------------------------------------------------------------------
     Ir

Use of uninitialized value $pairs[0] in numeric lt (<) at /usr/local/bin/callgrind_annotate line 1136.
Use of uninitialized value $high in numeric lt (<) at /usr/local/bin/callgrind_annotate line 1147.

584,638  <counts for unidentified lines in /cloud/jmaster/ndk_wwj/00.Trunk/Beauty_cmd/core/build/ndk/jni/../../../source/guidedfilter.cpp>

Use of uninitialized value in division (/) at /usr/local/bin/callgrind_annotate line 1218.
--------------------------------------------------------------------------------
Ir
--------------------------------------------------------------------------------
0  percentage of events annotated

Re: [Valgrind-users] Clarification on functions in pub_tool_tooliface.h

[Siddharth N. <si...@gm...>]

Hi Ivo,

The goal is to get at the

Thanks,
Sid

On 9 May 2017 at 00:48, Ivo Raisr <iv...@iv...> wrote:

> 2017-05-08 20:39 GMT+02:00 Siddharth Nilakantan <si...@gm...>:
> > Hi Mike and Ivo,
> >
> > I noticed a thread where you guys had a discussion going.
> >
> > https://sourceforge.net/p/valgrind/mailman/message/35687503/
> >
> > I was playing around with writing a tool that does some online analysis
> of
> > register reads/writes. Basically, the tool needs to know every register
> > read/write performed by the user program.
>
> Hi Sid,
>
> What is the ultimate goal of your analysis tool?


I want to discover the critical paths in different phases of a program, the
first step of which is to able to build paths.


> > Due to minor ambiguity in the  documentation (both in the code and the
> PLDI paper), I discovered the hard
> > way that VG_(track_post_reg_write) and VG_(track_pre_reg_read) are
> functions
> > that are called only around syscalls. I'm guessing that any
> VG_(track_pre_*)
> > and VG_(track_post_*) functions occur only around syscalls.
>
> Yes, indeed.
> Every tool also works with the IR (intermediate representation) - this
> where you
> can catch (and instrument) register reads and writes.
>
> I.
>
Yes this is what I had originally started doing. I found it a bit more
challenging than expected. Iex_Gets represent register reads. The
instrument function sees a lot of IRExpr* for Load data or Put data, which
we need to recursively explore to find Iex_Gets...

[Valgrind-users] [Question] Can dhat monitor the memory that alloc via mmap not malloc ?

[Wuweijia <wuw...@hu...>]

Re: [Valgrind-users] Clarification on functions in pub_tool_tooliface.h

[Ivo R. <iv...@iv...>]

2017-05-08 20:39 GMT+02:00 Siddharth Nilakantan <si...@gm...>:
> Hi Mike and Ivo,
>
> I noticed a thread where you guys had a discussion going.
>
> https://sourceforge.net/p/valgrind/mailman/message/35687503/
>
> I was playing around with writing a tool that does some online analysis of
> register reads/writes. Basically, the tool needs to know every register
> read/write performed by the user program.

Hi Sid,

What is the ultimate goal of your analysis tool?

> Due to minor ambiguity in the  documentation (both in the code and the PLDI paper), I discovered the hard
> way that VG_(track_post_reg_write) and VG_(track_pre_reg_read) are functions
> that are called only around syscalls. I'm guessing that any VG_(track_pre_*)
> and VG_(track_post_*) functions occur only around syscalls.

Yes, indeed.
Every tool also works with the IR (intermediate representation) - this where you
can catch (and instrument) register reads and writes.

I.

[Valgrind-users] I ran the callgrind_annotate to create the report . but it failed (in the read). Can you tell me Why?

[Wuweijia <wuw...@hu...>]

$  callgrind_annotate --threshold=20 --auto=yes --tree=caller --auto=yes  ./callgrind.out.7732 /cloud/jmaster/ndk_wwj/00.Trunk/Beauty_cmd/core/build/ndk/jni/../../../source/guidedfilter.cpp
--------------------------------------------------------------------------------
Profile data file './callgrind.out.7732' (creator: callgrind-3.12.0)
--------------------------------------------------------------------------------
I1 cache:
D1 cache:
LL cache:
Timerange: Basic block 0 - 2745879511
Trigger: Program termination
Profiled target:  ./beautyALL --gtest_filter=FACEBEAUTY_HWA_TEST_PQ.*001_001* (PID 7732, part 1)
Events recorded:  Ir
Events shown:     Ir
Event sort order: Ir
Thresholds:       20
Include dirs:
User annotated:   /cloud/jmaster/ndk_wwj/00.Trunk/Beauty_cmd/core/build/ndk/jni/../../../source/guidedfilter.cpp
Auto-annotation:  on

--------------------------------------------------------------------------------
            Ir
--------------------------------------------------------------------------------
54,072,323,868  PROGRAM TOTALS

--------------------------------------------------------------------------------
           Ir  file:function
--------------------------------------------------------------------------------

7,631,025,535  < ???:GF_mem_core_2(unsigned char const*, int, int, int, unsigned int, signed char, unsigned char*, int, int, unsigned short*, unsigned short*) (2x)
150,733,822,449,168,850  < ???:GF_mem_core_2(unsigned char const*, int, int, int, unsigned int, signed char, unsigned char*, int, int, unsigned short*, unsigned short*)'2 (72837764x)
7,631,015,516  *  ???:GF_mem_core_2(unsigned char const*, int, int, int, unsigned int, signed char, unsigned char*, int, int, unsigned short*, unsigned short*)'2

50,453,349,559,163,015  < ???:GF_mem_core_1(unsigned char const*, int, int, int, int, signed char, unsigned char*, int, int, unsigned short*, unsigned short*)'2 (49096266x)
5,290,859,433  *  ???:GF_mem_core_1(unsigned char const*, int, int, int, int, signed char, unsigned char*, int, int, unsigned short*, unsigned short*)'2

--------------------------------------------------------------------------------
-- User-annotated source: /cloud/jmaster/ndk_wwj/00.Trunk/Beauty_cmd/core/build/ndk/jni/../../../source/guidedfilter.cpp
--------------------------------------------------------------------------------
     Ir

Use of uninitialized value $pairs[0] in numeric lt (<) at /usr/local/bin/callgrind_annotate line 1136.
Use of uninitialized value $high in numeric lt (<) at /usr/local/bin/callgrind_annotate line 1147.

584,638  <counts for unidentified lines in /cloud/jmaster/ndk_wwj/00.Trunk/Beauty_cmd/core/build/ndk/jni/../../../source/guidedfilter.cpp>

Use of uninitialized value in division (/) at /usr/local/bin/callgrind_annotate line 1218.
--------------------------------------------------------------------------------
Ir
--------------------------------------------------------------------------------
0  percentage of events annotated

[Valgrind-users] 答复: 答复: [Help] I run test application throght the massif with --pages-as-heap, it failed. But I run the same application throught the massif with no --pages-as-heap, it is ok.why?

[Wuweijia <wuw...@hu...>]

Hi
   I can not access svn address that you show me. Can you show the code you modify, and I merge it .

BR
Owen

-----邮件原件-----
发件人: Philippe Waroquiers [mailto:phi...@sk...] 
发送时间: 2017年4月20日 4:23
收件人: Wuweijia <wuw...@hu...>
抄送: val...@li...; Fanbohao <fan...@hu...>
主题: Re: 答复: [Valgrind-users] [Help] I run test application throght the massif with --pages-as-heap, it failed. But I run the same application throught the massif with no --pages-as-heap, it is ok.why?

On Tue, 2017-04-18 at 02:33 +0000, Wuweijia wrote:
> Hi Philippe:
>   This is the android project.
>   
>   No matter the LD_PRELOAD , the valgrind always failed. The output is the same.
>   
>   I do not want to set it , I just try it when run the massif failed with --pages-as-heap and no LD_PRELOAD.
> 
>   I can not access web address. So can you help me to create a bug report and analyze it .

Looking at the traces you have sent, we see that in the working run, we have 2 successive open syscalls:
run_with_page_as_heap_no.log:381:SYSCALL[25925,1](56) sys_openat ( 4294967196, 0x494d050(/system/lib64/valgrind/vgpreload_core-arm64-linux.so), 524288 ) --> [async] ... 
run_with_page_as_heap_no.log:412:SYSCALL[25925,1](56) sys_openat ( 4294967196, 0x494d090(/system/lib64/valgrind/vgpreload_massif-arm64-linux.so), 524288 ) --> [async] ... 

the failed run contains:
run_with_page_as_heap_yes.log:2063:SYSCALL[25913,1](56) sys_openat ( 4294967196, 0x494d050(/system/lib64/valgrind/vgpreload_core-arm64-linux.so), 524288 ) --> [async] ... 
run_with_page_as_heap_yes.log:2139:SYSCALL[25913,1](56) sys_openat ( 4294967196, 0xffeffe908(/system/lib64/), 524288 ) --> [async] ... 

Massif uses a hack to remove vgpreload_massif-arm64-linux.so from the LD_PRELOAD, by replacing the full entry with spaces.
I am guessing that on android, the dynamic linker tries to open such an 'all spaces' entry by appending it to a system lib path, causing then the open syscall to fail and cause a dynamic linking error.

I have reworked the way vgpreload_massif-arm64-linux.so is removed from LD_PRELOAD, as part of revision 16306, so that the entry is really removed, rather than replaced with spaces.

Can you get + compile + test the SVN version ?
(see http://www.valgrind.org/downloads/repository.html
to get the SVN version, README.android indicates how to build for android)

Thanks

Philippe

Re: [Valgrind-users] 答复: [Help] I run test application throght the massif with --pages-as-heap, it failed. But I run the same application throught the massif with no --pages-as-heap, it is ok.why?

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

On Tue, 2017-04-18 at 02:33 +0000, Wuweijia wrote:
> Hi Philippe:
>   This is the android project.
>   
>   No matter the LD_PRELOAD , the valgrind always failed. The output is the same.
>   
>   I do not want to set it , I just try it when run the massif failed with --pages-as-heap and no LD_PRELOAD.
> 
>   I can not access web address. So can you help me to create a bug report and analyze it .

Looking at the traces you have sent, we see that in the working run,
we have 2 successive open syscalls:
run_with_page_as_heap_no.log:381:SYSCALL[25925,1](56) sys_openat ( 4294967196, 0x494d050(/system/lib64/valgrind/vgpreload_core-arm64-linux.so), 524288 ) --> [async] ... 
run_with_page_as_heap_no.log:412:SYSCALL[25925,1](56) sys_openat ( 4294967196, 0x494d090(/system/lib64/valgrind/vgpreload_massif-arm64-linux.so), 524288 ) --> [async] ... 

the failed run contains:
run_with_page_as_heap_yes.log:2063:SYSCALL[25913,1](56) sys_openat ( 4294967196, 0x494d050(/system/lib64/valgrind/vgpreload_core-arm64-linux.so), 524288 ) --> [async] ... 
run_with_page_as_heap_yes.log:2139:SYSCALL[25913,1](56) sys_openat ( 4294967196, 0xffeffe908(/system/lib64/), 524288 ) --> [async] ... 

Massif uses a hack to remove vgpreload_massif-arm64-linux.so from the LD_PRELOAD, by replacing the
full entry with spaces.
I am guessing that on android, the dynamic linker tries to open such an 'all spaces' entry by appending
it to a system lib path, causing then the open syscall to fail and cause a dynamic linking error.

I have reworked the way vgpreload_massif-arm64-linux.so is removed from LD_PRELOAD,
as part of revision 16306, so that the entry is really removed, rather than replaced
with spaces.

Can you get + compile + test the SVN version ?
(see http://www.valgrind.org/downloads/repository.html
to get the SVN version, README.android indicates how to
build for android)

Thanks

Philippe

[Valgrind-users] Valgrind file operation apis

[Yang L. <yan...@em...>]

Hi, all!

I'm working on cachegrind source code and would like to read a file when an
option is specified. I've found the file writing apt VG_(open)(...) and
VG_(write) by examing some source code. But I have no clue which function
to use to read a file at valgrind source code level. Is there any
documentation available?

In other words, I'm trying to find the following equivalent C code using
valgrind library functions.
FILE* file = fopen(fileName, "r"); /* should check the result */
    char line[256];

    while (fgets(line, sizeof(line), file)) {
              ...
    }

    fclose(file);

Thanks in advance for any suggestion!

Re: [Valgrind-users] [Help] I run test application throght the massif with --pages-as-heap, it failed. But I run the same application throught the massif with no --pages-as-heap, it is ok.why?

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

On Mon, 2017-04-17 at 06:36 +0000, Wuweijia wrote:
>  
> 
> The output as below:
...
> localhost:/system/bin # LD_PRELOAD=/system/bin/linker64 ./valgrind
> --tool=massif -v  --pages-as-heap=yes  ./mcfPQ
> --gtest_filter=*DISTANCE_001_001*
...
> CANNOT LINK EXECUTABLE "./mcfPQ": can't read file "/system/lib64": Is
> a directory--------------------------why it link failed with –
> pages-as-heap ?  How can I resovle it ?
> 
> libc: CANNOT LINK EXECUTABLE "./mcfPQ": can't read file
> "/system/lib64": Is a directory
> 
> libc: Fatal signal 6 (SIGABRT), code -6 in tid 20333 (massif-arm64-li)
> 
> libc: Unable to open connection to debuggerd: Connection refused
> 

--pages-as-heap=yes means massif will do some hacks on the LD_PRELOAD
variable to remove the preloaded valgrind shared object that replaces
malloc/free/...

So a guess is that there is a bad interaction between your LD_PRELOAD
setting to /system/bin/linker64 and the way massif modifies LD_PRELOAD
for --pages-as-heap=yes.

A few questions:
Is this an android platform ?
why do you need to set this variable ?

The best is probably to file a bug report on bugzilla with 
the above information
and attach the output of
   valgrind --tool=massif -v -v -v -d -d -d --pages-as-heap=yes --trace-syscalls=yes ....
and
   valgrind --tool=massif -v -v -v -d -d -d --pages-as-heap=no  --trace-syscalls=yes ....


Philippe

[Valgrind-users] [Help] I run test application throght the massif with --pages-as-heap, it failed. But I run the same application throught the massif with no --pages-as-heap, it is ok.why?

[Wuweijia <wuw...@hu...>]

The output as below:

localhost:/system/bin # LD_PRELOAD=/system/bin/linker64 ./valgrind --tool=massif -v  --pages-as-heap=yes  ./mcfPQ --gtest_filter=*DISTANCE_001_001*
==20333== Massif, a heap profiler
==20333== Copyright (C) 2003-2015, and GNU GPL'd, by Nicholas Nethercote
==20333== Using Valgrind-3.12.0 and LibVEX; rerun with -h for copyright info
==20333== Command: ./mcfPQ --gtest_filter=*DISTANCE_001_001*
==20333==
--20333-- Valgrind options:
--20333--    --tool=massif
--20333--    -v
--20333--    --pages-as-heap=yes
--20333-- Contents of /proc/version:
--20333--   Linux version 4.4.7+ (root@baixin-HP-Compaq-8200-Elite-MT-PC) (gcc version 4.9.3 20151223 (prerelease) (SDK V100R005C00SPC030B080) ) #1 SMP PREEMPT Fri Sep 9 14:57:05 CST 2016
--20333--
--20333-- Arch and hwcaps: ARM64, LittleEndian, baseline
--20333-- Page sizes: currently 4096, max supported 65536
--20333-- Valgrind library directory: /system/lib64/valgrind
--20333-- Massif: alloc-fns:
--20333-- Massif:   malloc
--20333-- Massif:   __builtin_new
--20333-- Massif:   operator new(unsigned)
--20333-- Massif:   operator new(unsigned long)
--20333-- Massif:   __builtin_vec_new
--20333-- Massif:   operator new[](unsigned)
--20333-- Massif:   operator new[](unsigned long)
--20333-- Massif:   calloc
--20333-- Massif:   realloc
--20333-- Massif:   memalign
--20333-- Massif:   posix_memalign
--20333-- Massif:   valloc
--20333-- Massif:   operator new(unsigned, std::nothrow_t const&)
--20333-- Massif:   operator new[](unsigned, std::nothrow_t const&)
--20333-- Massif:   operator new(unsigned long, std::nothrow_t const&)
--20333-- Massif:   operator new[](unsigned long, std::nothrow_t const&)
--20333-- Massif: ignore-fns:
--20333-- Massif:   <empty>
--20333-- Reading syms from /system/bin/mcfPQ
--20333-- Reading syms from /system/bin/linker64
--20333-- Reading syms from /system/lib64/valgrind/massif-arm64-linux
--20333--    object doesn't have a dynamic symbol table
--20333-- Scheduler: using generic scheduler lock implementation.
CANNOT LINK EXECUTABLE "./mcfPQ": can't read file "/system/lib64": Is a directory--------------------------why it link failed with -pages-as-heap ?  How can I resovle it ?
libc: CANNOT LINK EXECUTABLE "./mcfPQ": can't read file "/system/lib64": Is a directory
libc: Fatal signal 6 (SIGABRT), code -6 in tid 20333 (massif-arm64-li)
libc: Unable to open connection to debuggerd: Connection refused
--20333-- WARNING: unhandled arm64-linux syscall: 240
==20333==    at 0x40D8B80: __dl_syscall (syscall.S:44)
==20333==    by 0x4007397: __dl__ZL24debuggerd_signal_handleriP7siginfoPv (debugger.cpp:294)
==20333==    by 0x38088B8B: ??? (in /system/lib64/valgrind/massif-arm64-linux)
--20333-- You may be able to write your own handler.
--20333-- Read the file README_MISSING_SYSCALL_OR_IOCTL.
--20333-- Nevertheless we consider this a bug.  Please report
--20333-- it at http://valgrind.org/support/bug_reports.html.
libc: failed to resend signal during crash: Function not implemented

Re: [Valgrind-users] 答复: [Help] There is the problem.

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

With the below command, valgrind will only analyse the shell sh.
If you want to analyse what is launched by the shell, then you have
to give the option --trace-children=yes

Philippe

     

On Wed, 2017-04-05 at 01:08 +0000, Wuweijia wrote:
> no, I ran the valgrind on sh, but sh call applicant test0; test0 is the external tools
> 
> -----邮件原件-----
> 发件人: Alex Bligh [mailto:al...@al...] 
> 发送时间: 2017年4月2日 23:13
> 收件人: Wuweijia <wuw...@hu...>
> 抄送: Alex Bligh <al...@al...>; val...@li...; Fanbohao <fan...@hu...>
> 主题: Re: [Valgrind-users] [Help] There is the problem.
> 
> 
> > On 1 Apr 2017, at 12:22, Wuweijia <wuw...@hu...> wrote:
> > 
> >     I ran the valgrind with sh cmd. There is no output. That is why?
> >      
> >  
> > Run the valgrind cmd:   valgrind --xml=yes --xml-file=./r.xml sh -c ./test0
> 
> You're running valgrind on sh, not on test0. Is that intentional?
> 
> -- 
> Alex Bligh
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users

[Valgrind-users] 答复: [Help] There is the problem.

[Wuweijia <wuw...@hu...>]

no, I ran the valgrind on sh, but sh call applicant test0; test0 is the external tools

-----邮件原件-----
发件人: Alex Bligh [mailto:al...@al...] 
发送时间: 2017年4月2日 23:13
收件人: Wuweijia <wuw...@hu...>
抄送: Alex Bligh <al...@al...>; val...@li...; Fanbohao <fan...@hu...>
主题: Re: [Valgrind-users] [Help] There is the problem.


> On 1 Apr 2017, at 12:22, Wuweijia <wuw...@hu...> wrote:
> 
>     I ran the valgrind with sh cmd. There is no output. That is why?
>      
>  
> Run the valgrind cmd:   valgrind --xml=yes --xml-file=./r.xml sh -c ./test0

You're running valgrind on sh, not on test0. Is that intentional?

-- 
Alex Bligh

Re: [Valgrind-users] [Help] There is the problem.

[Alex B. <al...@al...>]

> On 1 Apr 2017, at 12:22, Wuweijia <wuw...@hu...> wrote:
> 
>     I ran the valgrind with sh cmd. There is no output. That is why?
>      
>  
> Run the valgrind cmd:   valgrind --xml=yes --xml-file=./r.xml sh -c ./test0

You're running valgrind on sh, not on test0. Is that intentional?

-- 
Alex Bligh

[Valgrind-users] [Help] There is the problem.

[Wuweijia <wuw...@hu...>]

HI:
    I ran the valgrind with sh cmd. There is no output. That is why?


Run the valgrind cmd:   valgrind --xml=yes --xml-file=./r.xml sh -c ./test0

The output as below:
fd=4, errno=0
va=0x2800
0

There is no xml file generated;

The code (tes0) as below:
#include <stdio.h>
#include <stdlib.h>
#include<fcntl.h>
#include <sys/types.h>
#include<sys/mman.h>
#include<unistd.h>
#include<string.h>

#define ALLOC_SIZE 1024  * 10

int main(int argc, char ** argv) {
        int fd = open("./test.log", O_RDWR );
        int errno = 0;
        int tmp = 0;
        printf("fd=%d, errno=%d\n", fd, errno);
        while(1) {
                void * va = mmap(NULL, ALLOC_SIZE, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
                printf("va=%p\n");
                tmp = *((int *)va + 5);
                printf("%d\n", tmp);
                munmap(va, ALLOC_SIZE);
                usleep(1000 * 100);
                break;
        }

        close(fd);
        return 0;
}

Re: [Valgrind-users] regtest failure on Centos

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

bar_bad test was reworked in 3.13SVN
I think it is supposed to work deterministically now.

Philippe


On Wed, 2017-03-22 at 12:38 -0700, Mark Roberts wrote:
> Running CentOS 7.3.1611 on amd64 box.  Valgrind release 3.12.0 with no
> mods.
> 
>  
> 
> Builds without error and runs all regtests without error except for
> helgrind/tests/bar_bad (and, I assume, that’s why the drd versions
> fail as well.)
> 
>  
> 
> Running bar_bad without Valgrind appears to work fine.  When run under
> Valgrind seems to run find until the end, then there is a long pause –
> as much as five minutes – and it produces the attached stderr.diff.
> I’ve run it directly under valgrind (i.e. no perl vg_regtest) and
> attached that log as well.
> 
>  
> 
> Any ideas or suggestions for further debug info?
> 
>  
> 
> Thank you,
> 
> Mark Roberts
> 
> UW PLSE 
> 
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________ Valgrind-users mailing list Val...@li... https://lists.sourceforge.net/lists/listinfo/valgrind-users