valgrind-users — General discussion list for Valgrind users

[Valgrind-users] Unsupported Clone Flags: 0x800600

[Adam S. <ada...@gm...>]

I'm hoping someone else has seen this issue and is able to help me. I have
search all over the internet for a solution and haven't been able to find
one. I am trying to run Valgrind on armv7 architecture, and after compiling
Valgrind and getting it onto the target I am able to run Valgrind
successfully on 'ls -l' but when I run Valgrind on my executable it starts
and then always fails after printing out this error:

==2333== Unsupported clone() flags: 0x800600
==2333==
==2333== The only supported clone() uses are:
==2333==  - via a threads library (LinuxThreads or NPTL)
==2333==  - via the implementation of fork or vfork
==2333==
==2333== Valgrind detected that your program requires
==2333== the following unimplemented functionality:
==2333==    Valgrind does not support general clone().
==2333== This may be because the functionality is hard to implement,
==2333== or because no reasonable program would behave this way,
==2333== or because nobody has yet needed it.  In any case, let us know at
==2333== www.valgrind.org and/or try to work around the problem, if you can.
==2333==
==2333== Valgrind has to exit now.  Sorry.  Bye!
==2333==

sched status:
  running_tid=9

The thread that has the crash has the following stack:
Thread 9: status = VgTs_Runnable (lwpid 2354)
==2333==    at 0x6C5BCC: sys_clone (linux_syscall_support.h:2666)
==2333==    by 0x6C5BCC:
google_breakpad::ExceptionHandler::GenerateDump(google_breakpad::ExceptionHandler::CrashContext*)
(exception_handler.cc:527)
==2333==    by 0x6C60C3:
google_breakpad::ExceptionHandler::SignalHandler(int, siginfo_t*, void*)
(exception_handler.cc:368)
==2333==    by 0x4CE5ACF: ??? (in /lib/libc-2.22.so)

Re: [Valgrind-users] 答复: 答复: 答复: 答复: [Help] Valgrind sometime run the program very slowly sometimes , it last at least one hour. can you show me why or some way to analyze it?

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

Have you tried with --fair-sched=yes, as suggested in an earlier mail ?
What were/are the results ?

Philippe

On Wed, 2018-02-07 at 07:52 +0000, Wuweijia wrote:
> Hi:
> 	There are some news about this question. The new code as below,  I change from  __sync_fetch_and_add to  pthread_mutex_xxx
> 	
>         pthread_mutex_lock(&g_mutex);
>         int curr = m_nCurrent;
>         m_nCurrent += m_nStep;
>         pthread_mutex_unlock(&g_mutex);
> 	
> 	Now there is no testcases with valgrind running too long, and failed.
>                 
> 	But pthread_mutex_lock is not efficient as __sync_fetch_and_add,   so the pthread_mutex_lock is just for now, for testing.
> 
> 	And I think there is something related to schedule module of valgrind . why it last too long?
> 
> BR
> Owen
> 
> 
> -----邮件原件-----
> 发件人: John Reiser [mailto:jr...@bi...] 
> 发送时间: 2018年1月26日 12:44
> 收件人: val...@li...
> 主题: Re: [Valgrind-users] 答复: 答复: 答复: [Help] Valgrind sometime run the program very slowly sometimes , it last at least one hour. can you show me why or some way to analyze it?
> 
> On 01/25/2018 15:37 UTC, Wuweijia wrote:
> 
> > 	Function1:
> > bool CDynamicScheduling::GetProcLoop(
> >          int& nBegin,
> >          int& nEndPlusOne)
> > {
> >          int curr = __sync_fetch_and_add(&m_nCurrent, m_nStep);
> 
> How large is 'm_nStep'?  [Are you sure?] The overhead expense of switching threads in valgrind would be reduced by making m_nStep as large as possible.  It looks like the code in Function2 would produce the same values regardless.
> 
> 
> >          if (curr > m_nEnd)
> >          {
> >                  return false;
> >          }
> > 
> >          nBegin = curr;
> >          int limit = m_nEnd + 1;
> 
> Local variable 'limit' is unused.  By itself this is unimportant, but it might be a clue to something that is not shown here.
> 
> >          nEndPlusOne = curr + m_nStep;
> >          return true;
> > }
> > 	
> > 	
> > 	Function2:
> > 	....
> > 	int beginY, endY;
> >    while (pDS->GetProcLoop(beginY, endY)){
> >      for (y = beginY; y < endY; y++){
> >        for(x = 0; x < dstWDiv2-7; x+=8){
> >          vtmp0 = vld2q_u16(&pSrc[(y<<1)*srcStride+(x<<1)]);
> >          vtmp1 = vld2q_u16(&pSrc[((y<<1)+1)*srcStride+(x<<1)]);
> 
> I hope the actual source contains a comment such as:
>      Compute pDst[] as the rounded average of non-overlapping 2x2 blocks of pixels in pSrc[].
> 
> >          vst1q_u16(&pDst[y*dstStride+x], (vtmp0.val[0] + vtmp0.val[1] + vtmp1.val[0] + vtmp1.val[1] + vdupq_n_u16(2)) >> vdupq_n_u16(2));
> >        }
> >        for(; x < dstWDiv2; x++){
> >          pDst[y*dstStride+x] = (pSrc[(y<<1)*srcStride+(x<<1)] + pSrc[(y<<1)*srcStride+(x<<1)+1] + pSrc[((y<<1)+1)*srcStride+(x<<1)] + pSrc[((y<<1)+1)*srcStride+((x<<1)+1)] + 2) >> 2;
> >        }
> >      }
> >    }
> > 
> >    return;
> > }	
> 
> ------------------------------------------------------------------------------
> 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
> ------------------------------------------------------------------------------
> 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] Valgrind sometime run the program very slowly sometimes , it last at least one hour. can you show me why or some way to analyze it?

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

Hi:
	There are some news about this question. The new code as below,  I change from  __sync_fetch_and_add to  pthread_mutex_xxx
	
        pthread_mutex_lock(&g_mutex);
        int curr = m_nCurrent;
        m_nCurrent += m_nStep;
        pthread_mutex_unlock(&g_mutex);
	
	Now there is no testcases with valgrind running too long, and failed.
                
	But pthread_mutex_lock is not efficient as __sync_fetch_and_add,   so the pthread_mutex_lock is just for now, for testing.

	And I think there is something related to schedule module of valgrind . why it last too long?

BR
Owen


-----邮件原件-----
发件人: John Reiser [mailto:jr...@bi...] 
发送时间: 2018年1月26日 12:44
收件人: val...@li...
主题: Re: [Valgrind-users] 答复: 答复: 答复: [Help] Valgrind sometime run the program very slowly sometimes , it last at least one hour. can you show me why or some way to analyze it?

On 01/25/2018 15:37 UTC, Wuweijia wrote:

> 	Function1:
> bool CDynamicScheduling::GetProcLoop(
>          int& nBegin,
>          int& nEndPlusOne)
> {
>          int curr = __sync_fetch_and_add(&m_nCurrent, m_nStep);

How large is 'm_nStep'?  [Are you sure?] The overhead expense of switching threads in valgrind would be reduced by making m_nStep as large as possible.  It looks like the code in Function2 would produce the same values regardless.


>          if (curr > m_nEnd)
>          {
>                  return false;
>          }
> 
>          nBegin = curr;

>          int limit = m_nEnd + 1;

Local variable 'limit' is unused.  By itself this is unimportant, but it might be a clue to something that is not shown here.

>          nEndPlusOne = curr + m_nStep;
>          return true;
> }
> 	
> 	
> 	Function2:
> 	....
> 	int beginY, endY;
>    while (pDS->GetProcLoop(beginY, endY)){
>      for (y = beginY; y < endY; y++){
>        for(x = 0; x < dstWDiv2-7; x+=8){
>          vtmp0 = vld2q_u16(&pSrc[(y<<1)*srcStride+(x<<1)]);
>          vtmp1 = vld2q_u16(&pSrc[((y<<1)+1)*srcStride+(x<<1)]);

I hope the actual source contains a comment such as:
     Compute pDst[] as the rounded average of non-overlapping 2x2 blocks of pixels in pSrc[].

>          vst1q_u16(&pDst[y*dstStride+x], (vtmp0.val[0] + vtmp0.val[1] + vtmp1.val[0] + vtmp1.val[1] + vdupq_n_u16(2)) >> vdupq_n_u16(2));
>        }
>        for(; x < dstWDiv2; x++){
>          pDst[y*dstStride+x] = (pSrc[(y<<1)*srcStride+(x<<1)] + pSrc[(y<<1)*srcStride+(x<<1)+1] + pSrc[((y<<1)+1)*srcStride+(x<<1)] + pSrc[((y<<1)+1)*srcStride+((x<<1)+1)] + 2) >> 2;
>        }
>      }
>    }
> 
>    return;
> }	

------------------------------------------------------------------------------
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] callgring doesn't annotate my source code

[Joel M. <jo...@sa...>]

  Hi,

I'm a new Valgrind / Callgrind user, and I'm trying to perform some profiling of my code at source level, per C++ line of code.
My code is running on Android platform, it was built under ndk-build with debug information included (-g option)
I activated valgrind with the following command in adb shell : valgrind --tool=callgrind ...
It successfully activated my code and generated as output an 898 Kbyte file - callgrind.out.6265
I then ran callgrind_annotate with the following command : callgrind_annotate --auto=yes callgrind.out.6265 > callgrind.out.txt
When reading callgrind.out.txt I could find some of my code - actually 1 function, with its correct function name, under "Ir  file:function", with a count of 4,262,514
But no code-line level annotation was provided for this function (nor for any other function).
When I tried to run callgrind_annotate without the --auto=yes option but explicitly specifying my source file xyz.cpp, I got the following output :
No information has been collected for xyz.cpp

Does anyone have a clue regarding what can cause this behavior ?

Thanks,
Joel

Re: [Valgrind-users] 答复: 答复: 答复: 答复: [Help] Valgrind sometime run the program very slowly sometimes , it last at least one hour. can you show me why or some way to analyze it?

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

It might be worth trying with --fair-sched=yes, just in case what you see
is due to the unfairness of thread scheduling.

Philippe

On Fri, 2018-01-26 at 06:57 +0000, Wuweijia wrote:
> Hi:
> 
> How large is 'm_nStep'?  [Are you sure?]
> 
> The source  as below, all are the integer. Do you care what value ?.
> class CDynamicScheduling
> {
> public:
>         static const int m_nDefaultStepUnit;
>         static const int m_nDefaultStepFactor;
> 
> private:
>         int m_nBegin;
>         int m_nEnd;
>         int m_nStep;
> #if defined(_MSC_VER)
>         std::atomic<int> m_nCurrent;
> #else
>         int m_nCurrent;
> #endif
> 
> 
> I hope the actual source contains a comment such as:
>      Compute pDst[] as the rounded average of non-overlapping 2x2 blocks of pixels in pSrc[].
> 
>     Yes, you are right. It just compute the average of 2 * 2 blocks
> 
> I show you just the aarch64 neon code:
> This is same function, but implement is x86.
> 
>       UINT16 *pDstL;
>         UINT16 *pSrcL;
>         INT32 dstWDiv2 = srcW >> 1;
> //      INT32 dstHDiv2 = srcH >> 1;
>         INT32 x, y;
>         INT32 posDst,posSrc;
> 
>         pSrcL = pSrc;
>         pDstL = pDst;
> 
>         int beginY, endY;
>         while (pDS->GetProcLoop(beginY, endY))
>         {
> //              for (y = 0; y < dstHDiv2; y++)
>                 for (y = beginY; y < endY; y++)
>                 {
>                         for (x = 0; x < dstWDiv2; x++)
>                         {
>                                 posDst = y*dstStride + x;
>                                 posSrc = (y<<1)*srcStride + (x<<1);
>                                 pDstL[posDst] = (pSrcL[posSrc] + pSrcL[posSrc + 1] + pSrcL[posSrc+srcStride] + pSrcL[posSrc+srcStride + 1] + 2) >> 2;
>                         }
>                 }
>         }
>      
>        pSrc is image  buffer,  about 11m.  Width:3968  Height: 2976  srcStride: 3968
>       It meant  four thread compute the average of 2 * 2 blocks
>       pSrc is divided into many small pieces , and compute the average of every piceces, not by designed,  by status of the running threads, maybe some threads  hold the cpu ,so they compute more pieces, Maybe some thread not hold the cpu, compute less pieces ;
>      
>        
> BR
> Owen
> 
> -----邮件原件-----
> 发件人: John Reiser [mailto:jr...@bi...] 
> 发送时间: 2018年1月26日 12:44
> 收件人: val...@li...
> 主题: Re: [Valgrind-users] 答复: 答复: 答复: [Help] Valgrind sometime run the program very slowly sometimes , it last at least one hour. can you show me why or some way to analyze it?
> 
> On 01/25/2018 15:37 UTC, Wuweijia wrote:
> 
> > 	Function1:
> > bool CDynamicScheduling::GetProcLoop(
> >          int& nBegin,
> >          int& nEndPlusOne)
> > {
> >          int curr = __sync_fetch_and_add(&m_nCurrent, m_nStep);
> 
> How large is 'm_nStep'?  [Are you sure?] The overhead expense of switching threads in valgrind would be reduced by making m_nStep as large as possible.  It looks like the code in Function2 would produce the same values regardless.
> 
> 
> >          if (curr > m_nEnd)
> >          {
> >                  return false;
> >          }
> > 
> >          nBegin = curr;
> >          int limit = m_nEnd + 1;
> 
> Local variable 'limit' is unused.  By itself this is unimportant, but it might be a clue to something that is not shown here.
> 
> >          nEndPlusOne = curr + m_nStep;
> >          return true;
> > }
> > 	
> > 	
> > 	Function2:
> > 	....
> > 	int beginY, endY;
> >    while (pDS->GetProcLoop(beginY, endY)){
> >      for (y = beginY; y < endY; y++){
> >        for(x = 0; x < dstWDiv2-7; x+=8){
> >          vtmp0 = vld2q_u16(&pSrc[(y<<1)*srcStride+(x<<1)]);
> >          vtmp1 = vld2q_u16(&pSrc[((y<<1)+1)*srcStride+(x<<1)]);
> 
> I hope the actual source contains a comment such as:
>      Compute pDst[] as the rounded average of non-overlapping 2x2 blocks of pixels in pSrc[].
> 
> >          vst1q_u16(&pDst[y*dstStride+x], (vtmp0.val[0] + vtmp0.val[1] + vtmp1.val[0] + vtmp1.val[1] + vdupq_n_u16(2)) >> vdupq_n_u16(2));
> >        }
> >        for(; x < dstWDiv2; x++){
> >          pDst[y*dstStride+x] = (pSrc[(y<<1)*srcStride+(x<<1)] + pSrc[(y<<1)*srcStride+(x<<1)+1] + pSrc[((y<<1)+1)*srcStride+(x<<1)] + pSrc[((y<<1)+1)*srcStride+((x<<1)+1)] + 2) >> 2;
> >        }
> >      }
> >    }
> > 
> >    return;
> > }	
> 
> ------------------------------------------------------------------------------
> 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
> ------------------------------------------------------------------------------
> 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] Valgrind sometime run the program very slowly sometimes , it last at least one hour. can you show me why or some way to analyze it?

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

Hi:

How large is 'm_nStep'?  [Are you sure?]

The source  as below, all are the integer. Do you care what value ?.
class CDynamicScheduling
{
public:
        static const int m_nDefaultStepUnit;
        static const int m_nDefaultStepFactor;

private:
        int m_nBegin;
        int m_nEnd;
        int m_nStep;
#if defined(_MSC_VER)
        std::atomic<int> m_nCurrent;
#else
        int m_nCurrent;
#endif


I hope the actual source contains a comment such as:
     Compute pDst[] as the rounded average of non-overlapping 2x2 blocks of pixels in pSrc[].

    Yes, you are right. It just compute the average of 2 * 2 blocks

I show you just the aarch64 neon code:
This is same function, but implement is x86.

      UINT16 *pDstL;
        UINT16 *pSrcL;
        INT32 dstWDiv2 = srcW >> 1;
//      INT32 dstHDiv2 = srcH >> 1;
        INT32 x, y;
        INT32 posDst,posSrc;

        pSrcL = pSrc;
        pDstL = pDst;

        int beginY, endY;
        while (pDS->GetProcLoop(beginY, endY))
        {
//              for (y = 0; y < dstHDiv2; y++)
                for (y = beginY; y < endY; y++)
                {
                        for (x = 0; x < dstWDiv2; x++)
                        {
                                posDst = y*dstStride + x;
                                posSrc = (y<<1)*srcStride + (x<<1);
                                pDstL[posDst] = (pSrcL[posSrc] + pSrcL[posSrc + 1] + pSrcL[posSrc+srcStride] + pSrcL[posSrc+srcStride + 1] + 2) >> 2;
                        }
                }
        }
     
       pSrc is image  buffer,  about 11m.  Width:3968  Height: 2976  srcStride: 3968
      It meant  four thread compute the average of 2 * 2 blocks
      pSrc is divided into many small pieces , and compute the average of every piceces, not by designed,  by status of the running threads, maybe some threads  hold the cpu ,so they compute more pieces, Maybe some thread not hold the cpu, compute less pieces ;
     
       
BR
Owen

-----邮件原件-----
发件人: John Reiser [mailto:jr...@bi...] 
发送时间: 2018年1月26日 12:44
收件人: val...@li...
主题: Re: [Valgrind-users] 答复: 答复: 答复: [Help] Valgrind sometime run the program very slowly sometimes , it last at least one hour. can you show me why or some way to analyze it?

On 01/25/2018 15:37 UTC, Wuweijia wrote:

> 	Function1:
> bool CDynamicScheduling::GetProcLoop(
>          int& nBegin,
>          int& nEndPlusOne)
> {
>          int curr = __sync_fetch_and_add(&m_nCurrent, m_nStep);

How large is 'm_nStep'?  [Are you sure?] The overhead expense of switching threads in valgrind would be reduced by making m_nStep as large as possible.  It looks like the code in Function2 would produce the same values regardless.


>          if (curr > m_nEnd)
>          {
>                  return false;
>          }
> 
>          nBegin = curr;

>          int limit = m_nEnd + 1;

Local variable 'limit' is unused.  By itself this is unimportant, but it might be a clue to something that is not shown here.

>          nEndPlusOne = curr + m_nStep;
>          return true;
> }
> 	
> 	
> 	Function2:
> 	....
> 	int beginY, endY;
>    while (pDS->GetProcLoop(beginY, endY)){
>      for (y = beginY; y < endY; y++){
>        for(x = 0; x < dstWDiv2-7; x+=8){
>          vtmp0 = vld2q_u16(&pSrc[(y<<1)*srcStride+(x<<1)]);
>          vtmp1 = vld2q_u16(&pSrc[((y<<1)+1)*srcStride+(x<<1)]);

I hope the actual source contains a comment such as:
     Compute pDst[] as the rounded average of non-overlapping 2x2 blocks of pixels in pSrc[].

>          vst1q_u16(&pDst[y*dstStride+x], (vtmp0.val[0] + vtmp0.val[1] + vtmp1.val[0] + vtmp1.val[1] + vdupq_n_u16(2)) >> vdupq_n_u16(2));
>        }
>        for(; x < dstWDiv2; x++){
>          pDst[y*dstStride+x] = (pSrc[(y<<1)*srcStride+(x<<1)] + pSrc[(y<<1)*srcStride+(x<<1)+1] + pSrc[((y<<1)+1)*srcStride+(x<<1)] + pSrc[((y<<1)+1)*srcStride+((x<<1)+1)] + 2) >> 2;
>        }
>      }
>    }
> 
>    return;
> }	

------------------------------------------------------------------------------
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] 答复: 答复: 答复: [Help] Valgrind sometime run the program very slowly sometimes , it last at least one hour. can you show me why or some way to analyze it?

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

On 01/25/2018 15:37 UTC, Wuweijia wrote:

> 	Function1:
> bool CDynamicScheduling::GetProcLoop(
>          int& nBegin,
>          int& nEndPlusOne)
> {
>          int curr = __sync_fetch_and_add(&m_nCurrent, m_nStep);

How large is 'm_nStep'?  [Are you sure?]
The overhead expense of switching threads in valgrind would be reduced
by making m_nStep as large as possible.  It looks like the code
in Function2 would produce the same values regardless.


>          if (curr > m_nEnd)
>          {
>                  return false;
>          }
> 
>          nBegin = curr;

>          int limit = m_nEnd + 1;

Local variable 'limit' is unused.  By itself this is unimportant,
but it might be a clue to something that is not shown here.

>          nEndPlusOne = curr + m_nStep;
>          return true;
> }
> 	
> 	
> 	Function2:
> 	....
> 	int beginY, endY;
>    while (pDS->GetProcLoop(beginY, endY)){
>      for (y = beginY; y < endY; y++){
>        for(x = 0; x < dstWDiv2-7; x+=8){
>          vtmp0 = vld2q_u16(&pSrc[(y<<1)*srcStride+(x<<1)]);
>          vtmp1 = vld2q_u16(&pSrc[((y<<1)+1)*srcStride+(x<<1)]);

I hope the actual source contains a comment such as:
     Compute pDst[] as the rounded average of non-overlapping 2x2 blocks of pixels in pSrc[].

>          vst1q_u16(&pDst[y*dstStride+x], (vtmp0.val[0] + vtmp0.val[1] + vtmp1.val[0] + vtmp1.val[1] + vdupq_n_u16(2)) >> vdupq_n_u16(2));
>        }
>        for(; x < dstWDiv2; x++){
>          pDst[y*dstStride+x] = (pSrc[(y<<1)*srcStride+(x<<1)] + pSrc[(y<<1)*srcStride+(x<<1)+1] + pSrc[((y<<1)+1)*srcStride+(x<<1)] + pSrc[((y<<1)+1)*srcStride+((x<<1)+1)] + 2) >> 2;
>        }
>      }
>    }
> 
>    return;
> }	

[Valgrind-users] 答复: 答复: 答复: [Help] Valgrind sometime run the program very slowly sometimes , it last at least one hour. can you show me why or some way to analyze it?

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

Hi
	About this problem how to analyze why the valgrind slow, I analyze the source code. I found the source to use atomic function  __sync_fetch_and_add to finish the job.
	There are  four thread  use __sync_fetch_and_add to sync the compute status.
	The source as below:
	Function1:
bool CDynamicScheduling::GetProcLoop(
        int& nBegin,
        int& nEndPlusOne)
{
        int curr = __sync_fetch_and_add(&m_nCurrent, m_nStep);
        if (curr > m_nEnd)
        {
                return false;
        }

        nBegin = curr;
        int limit = m_nEnd + 1;
        nEndPlusOne = curr + m_nStep;
        return true;
}
	
	
	Function2:
	....
	int beginY, endY;
  while (pDS->GetProcLoop(beginY, endY)){
    for (y = beginY; y < endY; y++){
      for(x = 0; x < dstWDiv2-7; x+=8){
        vtmp0 = vld2q_u16(&pSrc[(y<<1)*srcStride+(x<<1)]);
        vtmp1 = vld2q_u16(&pSrc[((y<<1)+1)*srcStride+(x<<1)]);
        vst1q_u16(&pDst[y*dstStride+x], (vtmp0.val[0] + vtmp0.val[1] + vtmp1.val[0] + vtmp1.val[1] + vdupq_n_u16(2)) >> vdupq_n_u16(2));
      }
      for(; x < dstWDiv2; x++){
        pDst[y*dstStride+x] = (pSrc[(y<<1)*srcStride+(x<<1)] + pSrc[(y<<1)*srcStride+(x<<1)+1] + pSrc[((y<<1)+1)*srcStride+(x<<1)] + pSrc[((y<<1)+1)*srcStride+((x<<1)+1)] + 2) >> 2;
      }
    }
  }

  return;
}	

	Function 2 call function1 (GetProcLoop) to get start and end index, Is there something relate to problem of valgrind last too long.

	Before  I heard some guy who maintained the valgrind said the valgrind 3.13 modify the lock algorithm. So the lock algorithm  of valgirnd 3.13 is different from valgirnd 3.12's.  
	Can you show me  some details why you modify the lock algorithm, what improvement. I need to know whether I need to upgrade the valgrind .  Upgrade is the hard work, a lot of testing.
	
	Background, I have down load the source code , but I still compile the source code failed in arm32, I need both aarch64 and arm32. They run together.
	So I want to try new way, build the valgrind 3.13 and try it.

BR
Owen




-----邮件原件-----
发件人: Ivo Raisr [mailto:iv...@iv...] 
发送时间: 2018年1月24日 12:36
收件人: Wuweijia <wuw...@hu...>
抄送: val...@li...; Fanbohao <fan...@hu...>
主题: Re: 答复: 答复: [Valgrind-users] [Help] Valgrind sometime run the program very slowly sometimes , it last at least one hour. can you show me why or some way to analyze it?

2018-01-24 1:36 GMT+01:00 Wuweijia <wuw...@hu...>:
> Hi:
>         But I can not access the git of valgrind. Is there any way to 
> get the newest source code; Maybe the network configuration do not 
> allow it;

It is hard to help you without any specific error shown.
If this is indeed a network configuration, there is a git mirror of Valgrind accessible over http or https.
Have a look at http://repo.or.cz/w/valgrind.git

I.

[Valgrind-users] other quesion about running in android-aarch64.

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

Hi：
	Do you never compile  in arm32 mode.
	I want to know how to modify the code to pass the compilation.
	
	
localhost:/system/bin # ./valgrind --undef-value-errors=no  -v ./hdrpALL --gtest_filter=*image_HDRP_TEST_PQ_OUTDOOR_NIGHT_LANDSCAPE_001_xml_standard
valgrind: mmap(0x108000, 4239360) failed in UME with error 22 (Invalid argument).
valgrind: this can be caused by executables with very large text, data or bss segments.

BR
Owen

-----邮件原件-----
发件人: Ivo Raisr [mailto:iv...@iv...] 
发送时间: 2018年1月24日 12:36
收件人: Wuweijia <wuw...@hu...>
抄送: val...@li...; Fanbohao <fan...@hu...>
主题: Re: 答复: 答复: [Valgrind-users] [Help] Valgrind sometime run the program very slowly sometimes , it last at least one hour. can you show me why or some way to analyze it?

2018-01-24 1:36 GMT+01:00 Wuweijia <wuw...@hu...>:
> Hi:
>         But I can not access the git of valgrind. Is there any way to 
> get the newest source code; Maybe the network configuration do not 
> allow it;

It is hard to help you without any specific error shown.
If this is indeed a network configuration, there is a git mirror of Valgrind accessible over http or https.
Have a look at http://repo.or.cz/w/valgrind.git

I.

[Valgrind-users] 答复: other quesion about running in android-aarch64.

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

It is valgrind 3.14

-----邮件原件-----
发件人: Wuweijia 
发送时间: 2018年1月25日 11:35
收件人: 'Ivo Raisr' <iv...@iv...>
抄送: val...@li...; Fanbohao <fan...@hu...>
主题: other quesion about running in android-aarch64.

Hi：
	Do you never compile  in arm32 mode.
	I want to know how to modify the code to pass the compilation.
	
	
localhost:/system/bin # ./valgrind --undef-value-errors=no  -v ./hdrpALL --gtest_filter=*image_HDRP_TEST_PQ_OUTDOOR_NIGHT_LANDSCAPE_001_xml_standard
valgrind: mmap(0x108000, 4239360) failed in UME with error 22 (Invalid argument).
valgrind: this can be caused by executables with very large text, data or bss segments.

BR
Owen

-----邮件原件-----
发件人: Ivo Raisr [mailto:iv...@iv...]
发送时间: 2018年1月24日 12:36
收件人: Wuweijia <wuw...@hu...>
抄送: val...@li...; Fanbohao <fan...@hu...>
主题: Re: 答复: 答复: [Valgrind-users] [Help] Valgrind sometime run the program very slowly sometimes , it last at least one hour. can you show me why or some way to analyze it?

2018-01-24 1:36 GMT+01:00 Wuweijia <wuw...@hu...>:
> Hi:
>         But I can not access the git of valgrind. Is there any way to 
> get the newest source code; Maybe the network configuration do not 
> allow it;

It is hard to help you without any specific error shown.
If this is indeed a network configuration, there is a git mirror of Valgrind accessible over http or https.
Have a look at http://repo.or.cz/w/valgrind.git

I.

[Valgrind-users] 答复: 答复: 答复: [Help] Valgrind sometime run the program very slowly sometimes , it last at least one hour. can you show me why or some way to analyze it?

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

Hi  
	I compile the source in arm32 mode, there is some error occurred, some function lack of param.


BR
Owen



-----邮件原件-----
发件人: Ivo Raisr [mailto:iv...@iv...] 
发送时间: 2018年1月24日 12:36
收件人: Wuweijia <wuw...@hu...>
抄送: val...@li...; Fanbohao <fan...@hu...>
主题: Re: 答复: 答复: [Valgrind-users] [Help] Valgrind sometime run the program very slowly sometimes , it last at least one hour. can you show me why or some way to analyze it?

2018-01-24 1:36 GMT+01:00 Wuweijia <wuw...@hu...>:
> Hi:
>         But I can not access the git of valgrind. Is there any way to 
> get the newest source code; Maybe the network configuration do not 
> allow it;

It is hard to help you without any specific error shown.
If this is indeed a network configuration, there is a git mirror of Valgrind accessible over http or https.
Have a look at http://repo.or.cz/w/valgrind.git

I.

[Valgrind-users] 答复: 答复: 答复: [Help] Valgrind sometime run the program very slowly sometimes , it last at least one hour. can you show me why or some way to analyze it?

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

Hi
     I download the source code , and I build arm32 version. That is some different with 3.12.
     There is onequestion:

      Question:
     I build the android -arm32  version, that is some compile error . I need to sure there is no need to include this file?
      Error as below:
     
external/valgrind-3.14-GIT/coregrind/m_syswrap/syscall-arm-linux.S:35:34: fatal error: libvex_guest_offsets.h: No such file or directory
 #include "libvex_guest_offsets.h"

The compile cmd:
	out/debug/target/product/kirin970/obj_arm/STATIC_LIBRARIES/libcoregrind-arm-linux_intermediates/coregrind/m_syswrap/syscall-arm-linux.o
/bin/bash -c "PWD=/proc/self/cwd    prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.9/bin/arm-linux-androideabi-gcc         -I external/valgrind-3.14-GIT -I external/valgrind-3.14-GIT/include -I external/valgrind-3.14-GIT/VEX/pub -I external/valgrind-3.14-GIT/coregrind -I external/valgrind-3.14-GIT -I out/debug/target/product/kirin970/obj_arm/STATIC_LIBRARIES/libcoregrind-arm-linux_intermediates -I out/debug/target/product/kirin970/gen/STATIC_LIBRARIES/libcoregrind-arm-linux_intermediates -I libnativehelper/include/nativehelper \$(cat out/debug/target/product/kirin970/obj_arm/STATIC_LIBRARIES/libcoregrind-arm-linux_intermediates/import_includes)  -I system/core/include -I system/media/audio/include -I hardware/libhardware/include -I hardware/libhardware_legacy/include -I hardware/ril/include -I libnativehelper/include -I frameworks/native/include -I frameworks/native/opengl/include -isystem frameworks/av/include -isystem out/debug/target/product/kirin970/obj/include -isystem bionic/libc/arch-arm/include -isystem bionic/libc/include -isystem bionic/libc/kernel/uapi -isystem bionic/libc/kernel/uapi/asm-arm -isystem bionic/libc/kernel/android/uapi -c  -fno-exceptions -Wno-multichar -ffunction-sections -fdata-sections -funwind-tables -fstack-protector-strong -Wa,--noexecstack -Werror=format-security -D_FORTIFY_SOURCE=2 -fno-short-enums -no-canonical-prefixes -fno-canonical-system-headers -fno-builtin-sin -fno-strict-volatile-bitfields -DNDEBUG -g -Wstrict-aliasing=2 -fgcse-after-reload -frerun-cse-after-loop -frename-registers -DANDROID -DOEMINFO_VERSION6 -fmessage-length=0 -W -Wall -Wno-unused -Winit-self -Wpointer-arith -DNDEBUG -UDEBUG -DBOARD_VENDORIMAGE_FILE_SYSTEM_TYPE -Wformat -fdebug-prefix-map=/proc/self/cwd= -fdiagnostics-color -Werror=return-type -Werror=non-virtual-dtor -Werror=address -Werror=sequence-point -Werror=date-time -mthumb-interwork -msoft-float -mfloat-abi=softfp -mfpu=neon -mcpu=cortex-a15 -D__ARM_FEATURE_LPAE=1   -std=gnu99 -O2 -fomit-frame-pointer -fstrict-aliasing -funswitch-loops   -Wall -Wmissing-prototypes -Wshadow -Wpointer-arith -Wmissing-declarations -Wno-pointer-sign -Wno-sign-compare -Wno-unused-parameter -Wno-shadow -fno-strict-aliasing -fno-stack-protector -DVGO_linux=1 -v -DANDROID_SYMBOLS_DIR=\\\"/data/local/symbols\\\" -std=gnu99  -DANDROID_HARDWARE_generic -DVGA_arm=1 -DVGP_arm_linux=1 -DVGPV_arm_linux_android=1 -DVG_LIBDIR=\\\"/system/lib64/valgrind\\\" -DVG_PLATFORM=\\\"arm-linux\\\"  -D__ASSEMBLY__ -MD -MF out/debug/target/product/kirin970/obj_arm/STATIC_LIBRARIES/libcoregrind-arm-linux_intermediates/coregrind/m_syswrap/syscall-arm-linux.d -o out/debug/target/product/kirin970/obj_arm/STATIC_LIBRARIES/libcoregrind-arm-linux_intermediates/coregrind/m_syswrap/syscall-arm-linux.o external/valgrind-3.14-GIT/coregrind/m_syswrap/syscall-arm-linux.S"
	
BR
Owen

-----邮件原件-----
发件人: Ivo Raisr [mailto:iv...@iv...] 
发送时间: 2018年1月24日 12:36
收件人: Wuweijia <wuw...@hu...>
抄送: val...@li...; Fanbohao <fan...@hu...>
主题: Re: 答复: 答复: [Valgrind-users] [Help] Valgrind sometime run the program very slowly sometimes , it last at least one hour. can you show me why or some way to analyze it?

2018-01-24 1:36 GMT+01:00 Wuweijia <wuw...@hu...>:
> Hi:
>         But I can not access the git of valgrind. Is there any way to 
> get the newest source code; Maybe the network configuration do not 
> allow it;

It is hard to help you without any specific error shown.
If this is indeed a network configuration, there is a git mirror of Valgrind accessible over http or https.
Have a look at http://repo.or.cz/w/valgrind.git

I.

Re: [Valgrind-users] 答复: 答复: [Help] Valgrind sometime run the program very slowly sometimes , it last at least one hour. can you show me why or some way to analyze it?

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

2018-01-24 1:36 GMT+01:00 Wuweijia <wuw...@hu...>:
> Hi:
>         But I can not access the git of valgrind. Is there any way to get the newest source code; Maybe the network configuration do not allow it;

It is hard to help you without any specific error shown.
If this is indeed a network configuration, there is a git mirror of
Valgrind accessible over http or https.
Have a look at http://repo.or.cz/w/valgrind.git

I.

[Valgrind-users] 答复: 答复: [Help] Valgrind sometime run the program very slowly sometimes , it last at least one hour. can you show me why or some way to analyze it?

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

Hi:
	But I can not access the git of valgrind. Is there any way to get the newest source code; Maybe the network configuration do not allow it;

BR
Owen

-----邮件原件-----
发件人: Ivo Raisr [mailto:iv...@iv...] 
发送时间: 2018年1月23日 21:54
收件人: Wuweijia <wuw...@hu...>
抄送: val...@li...; Fanbohao <fan...@hu...>
主题: Re: 答复: [Valgrind-users] [Help] Valgrind sometime run the program very slowly sometimes , it last at least one hour. can you show me why or some way to analyze it?

2018-01-23 12:27 GMT+01:00 Wuweijia <wuw...@hu...>:
> Hi
>      Thanks for your advise.  You mean I need to download valgrind 3.13. and merge your commit, compile it.

Actually not.
I meant you should build Valgrind from source code as per instructions
at: http://valgrind.org/downloads/repository.html

I.

[Valgrind-users] valgrind-3.13.0 (Fedora 27) and gfortran (experimental) 8.0.1: bogus false positives?

[Jorge D'E. <jd...@in...>]

Hi,

(a) DRD tool: in Sec. 8.1 (Overview) of the Valgrind User Manual 
(release 3.13.0 15 June 2017), it is indicated that the DRD Valgrind 
tool "is a Valgrind tool for detecting errors in multithreaded C and 
C++ programs". Then, Fortran programs are excluded? If so, why? 

(b) Helgrind tool: in Sec. 7.5 (Hints and Tips for Effective Use of Helgrind) 
of the same manual, lists 9 tips and suggestions. The false positives 
explained in point 8 due to standard I/O are (almost) not shown in simple 
programs, but they tend to appear in rather large programs. For example, 
the following (reduced) simple test:

program simple_test
  use omp_lib
  implicit none
  integer :: ih, im, nh, np
  im = 0
  !$omp parallel private (ih) shared (nh,np) reduction (max: im) 
  ih = omp_get_thread_num()
  nh = omp_get_num_threads()
  np = omp_get_num_procs()
  im = max (im,ih)
  !$omp end parallel
  write (*,*) np, nh, im
end program simple_test

compiled with: 

$ gfortran --version
GNU Fortran (GCC) 8.0.1 20180122 (experimental)

on an Intel(R) Core(TM) i7-3930K CPU @ 3.20GHz machine (6 cores) 
with Fedora 27:

$ cat /proc/version                                
Linux version 4.14.13-300.fc27.x86_64 (moc...@bk...) 
(gcc version 7.2.1 20170915 (Red Hat 7.2.1-2) (GCC)) 
#1 SMP Thu Jan 11 04:00:01 UTC 2018

using valgrind-3.13.0 and:

$ export OMP_NUM_THREADS=2

three tests are performed:

Test 1/3: 
  $ valgrind --tool=memcheck --leak-check=full --show-leak-kinds=all ... 
  it gives:
  Conditional jump or move depends on uninitialised value(s)
  at 0x505EA5B: write_decimal.constprop.10 (write.c:808)
  by 0x505EE13: write_integer (write.c:1351)
  by 0x505FCBD: list_formatted_write_scalar (write.c:1865)
  by 0x5060994: _gfortrani_list_formatted_write (write.c:1943)
  by 0x4009D6: MAIN__ (valtest-002.F90:19)
    definitely lost: 0 bytes in 0 blocks
    indirectly lost: 0 bytes in 0 blocks
      possibly lost: 288 bytes in 1 blocks
    still reachable: 2,000 bytes in 4 blocks
         suppressed: 0 bytes in 0 blocks

Test 2/3):
  $ valgrind --tool=helgrind --free-is-write=yes --track-lockorders=no 
    --check-stack-refs=no --read-var-info=yes 
    --sim-hints=no-nptl-pthread-stackcache --fair-sched=try ...
  it gives:
    Possible data race with a previous ...
    This conflicts with a previous ... 
    ERROR SUMMARY: 9 errors from 9 contexts (suppressed: 1 from 1)

Test 3/3 (forgetting comment (a)): 
  $ valgrind --tool=drd --read-var-info=yes --first-race-only=yes ...
  it gives:
  Conflicting store by thread ...
  ERROR SUMMARY: 5 errors from 5 contexts (suppressed: 3 from 2)

Then, 

(i)  It would be interesting to avoid (bogus?) messages like as:  
     "Conditional jump or move depends on uninitialised value(s)" 
     in Fortran programs that use "free-format" read/write, e.g. 
     line (valtest-002.F90:19) of Test 1, or "Possible data race" 
     (Test 2) and "Conflicting store by thread" (Test 3) in 
     OpenMP programs compiled/linked with the gcc/fortran flag 
     "-fopenmp" (which implies "-pthread"); 

(ii) In addition to the tips and suggestions given in the user 
     manual, could there be other means to mitigate these (bogus?) 
     messages?


Thanks in advance.

Regards.
Jorge D'Elia.
-- 
CIMEC (UNL-CONICET), http://www.cimec.org.ar/
Predio CONICET-Santa Fe, Colec. Ruta Nac. 168, 
Paraje El Pozo, 3000, Santa Fe, ARGENTINA. 
Tel +54-342-4511594/95 ext 7062, fax: +54-342-4511169

Re: [Valgrind-users] 答复: [Help] Valgrind sometime run the program very slowly sometimes , it last at least one hour. can you show me why or some way to analyze it?

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

2018-01-23 12:27 GMT+01:00 Wuweijia <wuw...@hu...>:
> Hi
>      Thanks for your advise.  You mean I need to download valgrind 3.13. and merge your commit, compile it.

Actually not.
I meant you should build Valgrind from source code as per instructions
at: http://valgrind.org/downloads/repository.html

I.

[Valgrind-users] 答复: [Help] Valgrind sometime run the program very slowly sometimes , it last at least one hour. can you show me why or some way to analyze it?

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

Hi
     Thanks for your advise.  You mean I need to download valgrind 3.13. and merge your commit, compile it.
      And Is there any api that I can dump the call stack of  the threads.
      I want  to add it to the code to show me more information to debug the program.

BR
Owen

-----邮件原件-----
发件人: Ivo Raisr [mailto:iv...@iv...] 
发送时间: 2018年1月23日 17:43
收件人: Wuweijia <wuw...@hu...>
抄送: val...@li...; Fanbohao <fan...@hu...>
主题: Re: [Valgrind-users] [Help] Valgrind sometime run the program very slowly sometimes , it last at least one hour. can you show me why or some way to analyze it?

2018-01-23 4:02 GMT+01:00 Wuweijia <wuw...@hu...>:
> Hi
>
>             I ran the program with mem-check,  99%  is okay, it will 
> not last long. But sometimes it last very long, at least one hour in 
> one function. And then I add the –trace-signals=yes to find what it happen.
> Valgrind show me some signal happened. Is there something related to 
> the time that the mem-check last too long. Or can you show me some 
> ways to analyze why the mem-check run too long sometimes.

Perhaps you will find useful a simple progress reporting facility recently integrated into Valgrind repo by Julian.
https://bugs.kde.org/show_bug.cgi?id=384633
Remark: you need to build Valgrind from the latest source as per http://valgrind.org/downloads/repository.html


Excerpt from the documentation:
---------------------------------------------
A new command line flag, --progress-interval=number, causes Valgrind to print a 1-line summary of progress every |number| seconds.
For example, when starting Firefox with --progress-interval=10, I get lines like this:

--32411-- PROGRESS: U 110s, W 113s, 97.3% CPU, EvC 414.79M, TIn 616.7k, TOut 0.5k, #thr 67
--32411-- PROGRESS: U 120s, W 124s, 96.8% CPU, EvC 505.27M, TIn 636.6k, TOut 3.0k, #thr 64
--32411-- PROGRESS: U 130s, W 134s, 97.0% CPU, EvC 574.90M, TIn 657.5k, TOut 3.0k, #thr 63
--32411-- PROGRESS: U 140s, W 144s, 97.2% CPU, EvC 636.34M, TIn 659.9k, TOut 3.0k, #thr 62
--32411-- PROGRESS: U 150s, W 155s, 96.8% CPU, EvC 710.21M, TIn 664.0k, TOut 17.7k, #thr 61
--32411-- PROGRESS: U 160s, W 201s, 79.6% CPU, EvC 822.38M, TIn 669.9k, TOut 75.8k, #thr 60

Each line shows:
   U:    total user time
   W:    total wallclock time
   CPU:  overall average cpu use
   EvC:  number of event checks.  An event check is a backwards branch
         in the simulated program, so this is a measure of forward progress
         of the program
   TIn:  number of code blocks instrumented by the JIT
   TOut: number of instrumented code blocks that have been thrown away
   #thr: number of threads in the program

From the progress of these, it is possible to observe:

* when the program is compute bound (TIn rises slowly, EvC rises rapidly)
* when the program is in a spinloop (TIn/TOut fixed, EvC rises rapidly)
* when the program is JIT-bound (TIn rises rapidly)
* when the program is rapidly discarding code (TOut rises rapidly)
* when the program is about to achieve some expected state (EvC arrives
  at some value you expect)
* when the program is idling (U rises more slowly than W)

I.

Re: [Valgrind-users] [Help] Valgrind sometime run the program very slowly sometimes , it last at least one hour. can you show me why or some way to analyze it?

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

2018-01-23 4:02 GMT+01:00 Wuweijia <wuw...@hu...>:
> Hi
>
>             I ran the program with mem-check,  99%  is okay, it will not
> last long. But sometimes it last very long, at least one hour in one
> function. And then I add the –trace-signals=yes to find what it happen.
> Valgrind show me some signal happened. Is there something related to the
> time that the mem-check last too long. Or can you show me some ways to
> analyze why the mem-check run too long sometimes.

Perhaps you will find useful a simple progress reporting facility
recently integrated into Valgrind repo by Julian.
https://bugs.kde.org/show_bug.cgi?id=384633
Remark: you need to build Valgrind from the latest source as per
http://valgrind.org/downloads/repository.html


Excerpt from the documentation:
---------------------------------------------
A new command line flag, --progress-interval=number, causes Valgrind
to print a 1-line summary of progress every |number| seconds.
For example, when starting Firefox with --progress-interval=10, I get
lines like this:

--32411-- PROGRESS: U 110s, W 113s, 97.3% CPU, EvC 414.79M, TIn
616.7k, TOut 0.5k, #thr 67
--32411-- PROGRESS: U 120s, W 124s, 96.8% CPU, EvC 505.27M, TIn
636.6k, TOut 3.0k, #thr 64
--32411-- PROGRESS: U 130s, W 134s, 97.0% CPU, EvC 574.90M, TIn
657.5k, TOut 3.0k, #thr 63
--32411-- PROGRESS: U 140s, W 144s, 97.2% CPU, EvC 636.34M, TIn
659.9k, TOut 3.0k, #thr 62
--32411-- PROGRESS: U 150s, W 155s, 96.8% CPU, EvC 710.21M, TIn
664.0k, TOut 17.7k, #thr 61
--32411-- PROGRESS: U 160s, W 201s, 79.6% CPU, EvC 822.38M, TIn
669.9k, TOut 75.8k, #thr 60

Each line shows:
   U:    total user time
   W:    total wallclock time
   CPU:  overall average cpu use
   EvC:  number of event checks.  An event check is a backwards branch
         in the simulated program, so this is a measure of forward progress
         of the program
   TIn:  number of code blocks instrumented by the JIT
   TOut: number of instrumented code blocks that have been thrown away
   #thr: number of threads in the program

>From the progress of these, it is possible to observe:

* when the program is compute bound (TIn rises slowly, EvC rises rapidly)
* when the program is in a spinloop (TIn/TOut fixed, EvC rises rapidly)
* when the program is JIT-bound (TIn rises rapidly)
* when the program is rapidly discarding code (TOut rises rapidly)
* when the program is about to achieve some expected state (EvC arrives
  at some value you expect)
* when the program is idling (U rises more slowly than W)

I.

[Valgrind-users] [Help] Valgrind sometime run the program very slowly sometimes , it last at least one hour. can you show me why or some way to analyze it?

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

Hi
            I ran the program with mem-check,  99%  is okay, it will not last long. But sometimes it last very long, at least one hour in one function. And then I add the -trace-signals=yes to find what it happen.  Valgrind show me some signal happened. Is there something related to the time that the mem-check last too long. Or can you show me some ways to analyze why the mem-check run too long sometimes.

The log as below:

[2018-01-19 14:10:38] [HDRP_AP][I] getSkinMask : 2660 [MedianFilter3x3_v2] BaseSize=770048, FilterSize=761856

[2018-01-19 14:10:38] [HDRP_AP][I] getSkinMask : 2661 [MedianFilter3x3_v2] BaseStride=1024,BaseHeight_16=752

[2018-01-19 14:10:38] [HDRP_AP][I] getSkinMask : 2662 [MedianFilter3x3_v2] width=992, height=744, stride=1024

--4195-- sync signal handler: signal=11, si_code=1, EIP=0x41753d4, eip=0x8046b2504, from kernel
--4195-- SIGSEGV: si_code=1 faultaddr=0xffefedf30 tid=1 ESP=0xffefedef0 seg=0xffe801000-0xffefedfff
--4195-- -> extended stack base to 0xffefed000
--4195-- sys_sigaltstack: tid 10, ss 0x3191C430{0x4B0A000,sz=16384,flags=0x0}, oss 0x0 (current SP 0x3191C410)
--4195-- sys_sigaltstack: tid 10, ss 0x3191C400{0x0,sz=0,flags=0x2}, oss 0x0 (current SP 0x3191C3B0)
--4195-- sys_sigaltstack: tid 10, ss 0x3191C430{0x4B0A000,sz=16384,flags=0x0}, oss 0x0 (current SP 0x3191C410)
--4195-- sys_sigaltstack: tid 10, ss 0x3191C400{0x0,sz=0,flags=0x2}, oss 0x0 (current SP 0x3191C3B0)
--4195-- sys_sigaltstack: tid 10, ss 0x3191C430{0x4B0A000,sz=16384,flags=0x0}, oss 0x0 (current SP 0x3191C410)
--4195-- sys_sigaltstack: tid 10, ss 0x3191C400{0x0,sz=0,flags=0x2}, oss 0x0 (current SP 0x3191C3B0)
--4195-- sys_sigaltstack: tid 10, ss 0x3191C430{0x4B0A000,sz=16384,flags=0x0}, oss 0x0 (current SP 0x3191C410)
--4195-- sys_sigaltstack: tid 10, ss 0x3191C400{0x0,sz=0,flags=0x2}, oss 0x0 (current SP 0x3191C3B0)
[2018-01-19 15:29:39] [HDRP_AP][I] rawnr_guidedfilter_self_u16 : 1310 enter.

--4195-- sys_sigaltstack: tid 10, ss 0x3191C430{0x4B0F000,sz=16384,flags=0x0}, oss 0x0 (current SP 0x3191C410)
--4195-- sys_sigaltstack: tid 11, ss 0x31A19430{0x4B19000,sz=16384,flags=0x0}, oss 0x0 (current SP 0x31A19410)

Env: android -arm64
Valgrind-3.12.

BR
owen

Re: [Valgrind-users] memcheck linking error for armv7

[Mahesh V <mah...@gm...>]

Hello folks,

I compiled the valgrind and memcheck for powerpc and it went through fine.
However I see that leak is not getting detected.
Compiled the below program with -O0 -g flags

[mv_mm-dev valgrind-3.12.0 (IAP-MASTERSON)]$ cat valg.c
#include <stdlib.h>

  void f(void)
  {
     int* x = malloc(10 * sizeof(int));
     printf("hello \n");
     //x[10] = 0;        // problem 1: heap block overrun
  }                    // problem 2: memory leak -- x not freed

  int main(void)
  {
     f();
     return 0;
  }



/aruba/bin # ./valgrind_ppc -v --leak-check=full --show-leak-kinds=all
--trace-redir=yes ./ll
==5922== Memcheck, a memory error detector
==5922== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==5922== Using Valgrind-3.12.0 and LibVEX; rerun with -h for copyright info
==5922== Command: ./ll
==5922==
--5922-- Valgrind options:
--5922--    -v
--5922--    --leak-check=full
--5922--    --show-leak-kinds=all
--5922--    --trace-redir=yes
--5922-- Contents of /proc/version:
--5922--
--5922-- Aruba Networks
--5922-- ArubaOS Version 8.3.0.0-8.3.0.0 (build 0000 / label
#mdantakale@md_mm-dev-ENG.0000)
--5922-- Built by mda...@bl... on
2018-01-18 at 12:32:13 IST (gcc version 4.8.1)
--5922-- (c) Copyright 2018 Hewlett Packard Enterprise Development LP.
--5922--
--5922-- Arch and hwcaps: PPC32, BigEndian, ppc32-int-flt-GX
--5922-- Page sizes: currently 4096, max supported 65536
--5922-- Valgrind library directory: /usr/lib/valgrind
--5922-- <<
--5922--    ------ REDIR STATE after VG_(redir_initialise) ------
--5922--    TOPSPECS of soname (hardwired)
--5922--      ld.so.1                   index
RL-> (0000.0) 0x3805cb00
--5922--      ld.so.1                   strcmp
RL-> (0000.0) 0x3805ca8c
--5922--      ld.so.1                   strlen
RL-> (0000.0) 0x3805ca64
--5922--    ------ ACTIVE ------
--5922-- >>
--5922-- Reading syms from /lib/ld-uClibc.so.0
--5922--    svma 0x0000001130, avma 0x0004001130
--5922--   Considering /lib/ld-uClibc-0.9.34-git.so ..
--5922--   .. CRC mismatch (computed 4890ee42 wanted 93eb0f3e)
--5922--    object doesn't have a symbol table
--5922-- <<
--5922--    ------ REDIR STATE after VG_(redir_notify_new_DebugInfo) ------
--5922--    TOPSPECS of soname ld-uClibc.so.0 filename /lib/ld-uClibc.so.0
--5922--    TOPSPECS of soname (hardwired)
--5922--      ld.so.1                   index
RL-> (0000.0) 0x3805cb00
--5922--      ld.so.1                   strcmp
RL-> (0000.0) 0x3805ca8c
--5922--      ld.so.1                   strlen
RL-> (0000.0) 0x3805ca64
--5922--    ------ ACTIVE ------
--5922-- >>
--5922-- Reading syms from /aruba/bin/ll
--5922--    svma 0x0010000328, avma 0x0010000328
--5922-- <<
--5922--    ------ REDIR STATE after VG_(redir_notify_new_DebugInfo) ------
--5922--    TOPSPECS of soname NONE filename /aruba/bin/ll
--5922--    TOPSPECS of soname ld-uClibc.so.0 filename /lib/ld-uClibc.so.0
--5922--    TOPSPECS of soname (hardwired)
--5922--      ld.so.1                   index
RL-> (0000.0) 0x3805cb00
--5922--      ld.so.1                   strcmp
RL-> (0000.0) 0x3805ca8c
--5922--      ld.so.1                   strlen
RL-> (0000.0) 0x3805ca64
--5922--    ------ ACTIVE ------
--5922-- >>
--5922-- Reading syms from /usr/lib/valgrind/memcheck-ppc32-linux
--5922--    svma 0x0038000094, avma 0x0038000094
--5922--    object doesn't have a dynamic symbol table
--5922-- <<
--5922--    ------ REDIR STATE after VG_(redir_notify_new_DebugInfo) ------
--5922--    TOPSPECS of soname NONE filename
/usr/lib/valgrind/memcheck-ppc32-linux
--5922--    TOPSPECS of soname NONE filename /aruba/bin/ll
--5922--    TOPSPECS of soname ld-uClibc.so.0 filename /lib/ld-uClibc.so.0
--5922--    TOPSPECS of soname (hardwired)
--5922--      ld.so.1                   index
RL-> (0000.0) 0x3805cb00
--5922--      ld.so.1                   strcmp
RL-> (0000.0) 0x3805ca8c
--5922--      ld.so.1                   strlen
RL-> (0000.0) 0x3805ca64
--5922--    ------ ACTIVE ------
--5922-- >>
--5922-- Scheduler: using generic scheduler lock implementation.
--5922-- Reading suppressions file: /usr/lib/valgrind/default.supp
==5922== embedded gdbserver: reading from
/tmp/vgdb-pipe-from-vgdb-to-5922-by-root-on-???
==5922== embedded gdbserver: writing to
/tmp/vgdb-pipe-to-vgdb-from-5922-by-root-on-???
==5922== embedded gdbserver: shared mem
/tmp/vgdb-pipe-shared-mem-vgdb-5922-by-root-on-???
==5922==
==5922== TO CONTROL THIS PROCESS USING vgdb (which you probably
==5922== don't want to do, unless you know exactly what you're doing,
==5922== or are doing some strange experiment):
==5922==   /usr/lib/valgrind/../../bin/vgdb --pid=5922 ...command...
==5922==
==5922== TO DEBUG THIS PROCESS USING GDB: start GDB like this
==5922==   /path/to/gdb ./ll
==5922== and then give GDB the following command
==5922==   target remote | /usr/lib/valgrind/../../bin/vgdb --pid=5922
==5922== --pid is optional if only one valgrind process is running
==5922==
--5922-- Reading syms from /usr/lib/valgrind/vgpreload_core-ppc32-linux.so
--5922--    svma 0x00000003cc, avma 0x000401a3cc
--5922-- <<
--5922--    ------ REDIR STATE after VG_(redir_notify_new_DebugInfo) ------
--5922--    TOPSPECS of soname NONE filename
/usr/lib/valgrind/vgpreload_core-ppc32-linux.so
--5922--    TOPSPECS of soname NONE filename
/usr/lib/valgrind/memcheck-ppc32-linux
--5922--    TOPSPECS of soname NONE filename /aruba/bin/ll
--5922--    TOPSPECS of soname ld-uClibc.so.0 filename /lib/ld-uClibc.so.0
--5922--    TOPSPECS of soname (hardwired)
--5922--      ld.so.1                   index
RL-> (0000.0) 0x3805cb00
--5922--      ld.so.1                   strcmp
RL-> (0000.0) 0x3805ca8c
--5922--      ld.so.1                   strlen
RL-> (0000.0) 0x3805ca64
--5922--    ------ ACTIVE ------
--5922-- >>
--5922-- Reading syms from /lib/libgcc_s.so.1
--5922--    svma 0x00000022b0, avma 0x000402d2b0
--5922--   Considering /lib/libgcc_s.so.1 ..
--5922--   .. CRC mismatch (computed a4a20c5f wanted b48b756d)
--5922--    object doesn't have a symbol table
--5922-- <<
--5922--    ------ REDIR STATE after VG_(redir_notify_new_DebugInfo) ------
--5922--    TOPSPECS of soname libgcc_s.so.1 filename /lib/libgcc_s.so.1
--5922--    TOPSPECS of soname NONE filename
/usr/lib/valgrind/vgpreload_core-ppc32-linux.so
--5922--    TOPSPECS of soname NONE filename
/usr/lib/valgrind/memcheck-ppc32-linux
--5922--    TOPSPECS of soname NONE filename /aruba/bin/ll
--5922--    TOPSPECS of soname ld-uClibc.so.0 filename /lib/ld-uClibc.so.0
--5922--    TOPSPECS of soname (hardwired)
--5922--      ld.so.1                   index
RL-> (0000.0) 0x3805cb00
--5922--      ld.so.1                   strcmp
RL-> (0000.0) 0x3805ca8c
--5922--      ld.so.1                   strlen
RL-> (0000.0) 0x3805ca64
--5922--    ------ ACTIVE ------
--5922-- >>
--5922-- Reading syms from /lib/libc.so.0
--5922--    svma 0x000000e1f0, avma 0x000405f1f0
--5922--   Considering /lib/libuClibc-0.9.34-git.so ..
--5922--   .. CRC mismatch (computed aca7e0ee wanted 30ca3855)
--5922--    object doesn't have a symbol table
--5922-- <<
--5922--    ------ REDIR STATE after VG_(redir_notify_new_DebugInfo) ------
--5922--    TOPSPECS of soname libc.so.0 filename /lib/libc.so.0
--5922--    TOPSPECS of soname libgcc_s.so.1 filename /lib/libgcc_s.so.1
--5922--    TOPSPECS of soname NONE filename
/usr/lib/valgrind/vgpreload_core-ppc32-linux.so
--5922--    TOPSPECS of soname NONE filename
/usr/lib/valgrind/memcheck-ppc32-linux
--5922--    TOPSPECS of soname NONE filename /aruba/bin/ll
--5922--    TOPSPECS of soname ld-uClibc.so.0 filename /lib/ld-uClibc.so.0
--5922--    TOPSPECS of soname (hardwired)
--5922--      ld.so.1                   index
RL-> (0000.0) 0x3805cb00
--5922--      ld.so.1                   strcmp
RL-> (0000.0) 0x3805ca8c
--5922--      ld.so.1                   strlen
RL-> (0000.0) 0x3805ca64
--5922--    ------ ACTIVE ------
--5922-- >>
hello
/aruba/bin/ll: can't resolve symbol '__libc_freeres' in lib
'/usr/lib/valgrind/vgpreload_core-ppc32-linux.so'.
==5922==
==5922== HEAP SUMMARY:
==5922==     in use at exit: 0 bytes in 0 blocks
==5922==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==5922==
==5922== All heap blocks were freed -- no leaks are possible
==5922==
==5922== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==5922== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
/aruba/bin #

On Fri, Jan 19, 2018 at 11:28 PM, Mahesh V
<mah...@gm...> wrote:
> Hello Folks,
>
> This is my first mail here.
>
> While cross compiling memcheck for ARM,  I get an unresolved symbol for
> vgSysWrap_generic_sys_mremap_before in coregrind/libcoregrind-arm-linux.a
>
> I can see that is is undefined in that library.
>
> Making all in .
> make[1]: Entering directory
> `/home/maheshvenkateshwaran/valgrind-3.12.0/memcheck'
> ../coregrind/link_tool_exe_linux 0x38000000 gcc     -o
> memcheck-arm-linux -O2 -g -std=gnu99 -Wall -Wmissing-prototypes
> -Wshadow -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations
> -Wcast-qual -Wwrite-strings -Wempty-body -Wformat -Wformat-security
> -Wignored-qualifiers -Wmissing-parameter-type -Wold-style-declaration
> -fno-stack-protector -fno-strict-aliasing -fno-builtin  -marm
> -mcpu=cortex-a8 -O2 -static -nodefaultlibs -nostartfiles -u _start
> memcheck_arm_linux-mc_leakcheck.o
> memcheck_arm_linux-mc_malloc_wrappers.o memcheck_arm_linux-mc_main.o
> memcheck_arm_linux-mc_translate.o memcheck_arm_linux-mc_machine.o
> memcheck_arm_linux-mc_errors.o ../coregrind/libcoregrind-arm-linux.a
> ../VEX/libvex-arm-linux.a -lgcc
> ../coregrind/libcoregrind-arm-linux.a(libcoregrind_arm_linux_a-syswrap-arm-linux.o):(.data+0x518):
> undefined reference to `vgSysWrap_generic_sys_mremap_before'
> collect2: ld returned 1 exit status
> make[1]: *** [memcheck-arm-linux] Error 1
>
> Any idea how to resolve this issue?
>
> Steps
> ./configure --host=armv7-none-linux-gnueabi --target=armv7-none-linux-gnueabi
> ./make
>
> Valgrind compiled fine and executable is built as well
> $ file ./valgrind
> ./valgrind: ELF 32-bit LSB executable, ARM, version 1 (SYSV),
> dynamically linked (uses shared libs), not stripped
>
>
> regards
> Mahesh

[Valgrind-users] memcheck linking error for armv7

[Mahesh V <mah...@gm...>]

Hello Folks,

This is my first mail here.

While cross compiling memcheck for ARM,  I get an unresolved symbol for
vgSysWrap_generic_sys_mremap_before in coregrind/libcoregrind-arm-linux.a

I can see that is is undefined in that library.

Making all in .
make[1]: Entering directory
`/home/maheshvenkateshwaran/valgrind-3.12.0/memcheck'
../coregrind/link_tool_exe_linux 0x38000000 gcc     -o
memcheck-arm-linux -O2 -g -std=gnu99 -Wall -Wmissing-prototypes
-Wshadow -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations
-Wcast-qual -Wwrite-strings -Wempty-body -Wformat -Wformat-security
-Wignored-qualifiers -Wmissing-parameter-type -Wold-style-declaration
-fno-stack-protector -fno-strict-aliasing -fno-builtin  -marm
-mcpu=cortex-a8 -O2 -static -nodefaultlibs -nostartfiles -u _start
memcheck_arm_linux-mc_leakcheck.o
memcheck_arm_linux-mc_malloc_wrappers.o memcheck_arm_linux-mc_main.o
memcheck_arm_linux-mc_translate.o memcheck_arm_linux-mc_machine.o
memcheck_arm_linux-mc_errors.o ../coregrind/libcoregrind-arm-linux.a
../VEX/libvex-arm-linux.a -lgcc
../coregrind/libcoregrind-arm-linux.a(libcoregrind_arm_linux_a-syswrap-arm-linux.o):(.data+0x518):
undefined reference to `vgSysWrap_generic_sys_mremap_before'
collect2: ld returned 1 exit status
make[1]: *** [memcheck-arm-linux] Error 1

Any idea how to resolve this issue?

Steps
./configure --host=armv7-none-linux-gnueabi --target=armv7-none-linux-gnueabi
./make

Valgrind compiled fine and executable is built as well
$ file ./valgrind
./valgrind: ELF 32-bit LSB executable, ARM, version 1 (SYSV),
dynamically linked (uses shared libs), not stripped


regards
Mahesh

Re: [Valgrind-users] Support bpf syscall in amd64 Linux

[Zexuan L. <spa...@gm...>]

Done.
https://bugs.kde.org/show_bug.cgi?id=388786

2018-01-10 23:24 GMT+08:00 Tom Hughes <to...@co...>:
> On 10/01/18 14:43, Zexuan Luo wrote:
>
>> I just wrote a patch to support bpf syscall in amd64 Linux, following
>> this guide: http://valgrind.org/docs/manual/dist.readme-missing.html
>> It is my first time to hack valgrind, please let me know if I made any
>> mistake.
>> I am glad to see this patch could be reviewed and accepted.
>
>
> Please open a bug and attach the patch.
>
> Tom
>
> --
> Tom Hughes (to...@co...)
> http://compton.nu/

Re: [Valgrind-users] Support bpf syscall in amd64 Linux

[Tom H. <to...@co...>]

On 10/01/18 14:43, Zexuan Luo wrote:

> I just wrote a patch to support bpf syscall in amd64 Linux, following
> this guide: http://valgrind.org/docs/manual/dist.readme-missing.html
> It is my first time to hack valgrind, please let me know if I made any mistake.
> I am glad to see this patch could be reviewed and accepted.

Please open a bug and attach the patch.

Tom

-- 
Tom Hughes (to...@co...)
http://compton.nu/

[Valgrind-users] Support bpf syscall in amd64 Linux

[Zexuan L. <spa...@gm...>]

Hi everyone.
I just wrote a patch to support bpf syscall in amd64 Linux, following
this guide: http://valgrind.org/docs/manual/dist.readme-missing.html
It is my first time to hack valgrind, please let me know if I made any mistake.
I am glad to see this patch could be reviewed and accepted.
Thanks!

diff --git a/coregrind/m_syswrap/syswrap-amd64-linux.c
b/coregrind/m_syswrap/syswrap-amd64-linux.c
index 14ad6499e..a75048397 100644
--- a/coregrind/m_syswrap/syswrap-amd64-linux.c
+++ b/coregrind/m_syswrap/syswrap-amd64-linux.c
@@ -201,6 +201,7 @@ DECL_TEMPLATE(amd64_linux, sys_arch_prctl);
 DECL_TEMPLATE(amd64_linux, sys_ptrace);
 DECL_TEMPLATE(amd64_linux, sys_fadvise64);
 DECL_TEMPLATE(amd64_linux, sys_mmap);
+DECL_TEMPLATE(amd64_linux, sys_bpf);
 DECL_TEMPLATE(amd64_linux, sys_syscall184);


@@ -401,6 +402,14 @@ PRE(sys_mmap)
    SET_STATUS_from_SysRes(r);
 }

+PRE(sys_bpf)
+{
+
+   PRINT("sys_bpf ( %ld, %#lx, %lu )" , SARG1, ARG2, ARG3);
+   PRE_REG_READ3(int, "bpf",
+                 int, cmd, union vki_bpf_attr *, attr, unsigned int, size);
+}
+

 /* ---------------------------------------------------------------
    PRE/POST wrappers for AMD64/Linux-variant specific syscalls
@@ -839,10 +848,10 @@ static SyscallTableEntry syscall_table[] = {
    LINX_(__NR_renameat2,         sys_renameat2),        // 316
 //   LIN__(__NR_seccomp,           sys_ni_syscall),       // 317
    LINXY(__NR_getrandom,         sys_getrandom),        // 318
-   LINXY(__NR_memfd_create,      sys_memfd_create)      // 319
+   LINXY(__NR_memfd_create,      sys_memfd_create),      // 319

 //   LIN__(__NR_kexec_file_load,   sys_ni_syscall),       // 320
-//   LIN__(__NR_bpf,               sys_ni_syscall)        // 321
+   PLAX_(__NR_bpf,               sys_bpf),              // 321
 };

 SyscallTableEntry* ML_(get_linux_syscall_entry) ( UInt sysno )
diff --git a/include/vki/vki-amd64-linux.h b/include/vki/vki-amd64-linux.h
index a506ade06..293c4edf0 100644
--- a/include/vki/vki-amd64-linux.h
+++ b/include/vki/vki-amd64-linux.h
@@ -48,6 +48,7 @@ typedef unsigned int __vki_u32;

 typedef __signed__ long long __vki_s64;
 typedef unsigned long long __vki_u64;
+typedef __vki_u64 __attribute__((aligned(8))) __vki_aligned_u64;

 typedef unsigned short vki_u16;

@@ -697,6 +698,86 @@ struct vki_shminfo64 {
 #define VKI_TIOCGSERIAL     0x541E
 #define VKI_TIOCSSERIAL     0x541F

+//----------------------------------------------------------------------
+// From linux-4.14.13/include/uapi/linux/bpf.h
+//----------------------------------------------------------------------
+
+union bpf_attr {
+    struct { /* anonymous struct used by BPF_MAP_CREATE command */
+        __vki_u32    map_type;    /* one of enum bpf_map_type */
+        __vki_u32    key_size;    /* size of key in bytes */
+        __vki_u32    value_size;    /* size of value in bytes */
+        __vki_u32    max_entries;    /* max number of entries in a map */
+        __vki_u32    map_flags;    /* BPF_MAP_CREATE related
+                     * flags defined above.
+                     */
+        __vki_u32    inner_map_fd;    /* fd pointing to the inner map */
+        __vki_u32    numa_node;    /* numa node (effective only if
+                                 * BPF_F_NUMA_NODE is set).
+                                 */
+    };
+
+    struct { /* anonymous struct used by BPF_MAP_*_ELEM commands */
+        __vki_u32            map_fd;
+        __vki_aligned_u64    key;
+        union {
+            __vki_aligned_u64 value;
+            __vki_aligned_u64 next_key;
+        };
+        __vki_u64        flags;
+    };
+
+    struct { /* anonymous struct used by BPF_PROG_LOAD command */
+        __vki_u32            prog_type;    /* one of enum bpf_prog_type */
+        __vki_u32            insn_cnt;
+        __vki_aligned_u64    insns;
+        __vki_aligned_u64    license;
+        __vki_u32            log_level;    /* verbosity level of verifier */
+        __vki_u32            log_size;    /* size of user buffer */
+        __vki_aligned_u64    log_buf;    /* user supplied buffer */
+        __vki_u32            kern_version;    /* checked when
prog_type=kprobe */
+        __vki_u32            prog_flags;
+    };
+
+    struct { /* anonymous struct used by BPF_OBJ_* commands */
+        __vki_aligned_u64    pathname;
+        __vki_u32            bpf_fd;
+    };
+
+    struct { /* anonymous struct used by BPF_PROG_ATTACH/DETACH commands */
+        __vki_u32        target_fd;    /* container object to attach to */
+        __vki_u32        attach_bpf_fd;    /* eBPF program to attach */
+        __vki_u32        attach_type;
+        __vki_u32        attach_flags;
+    };
+
+    struct { /* anonymous struct used by BPF_PROG_TEST_RUN command */
+        __vki_u32            prog_fd;
+        __vki_u32            retval;
+        __vki_u32            data_size_in;
+        __vki_u32            data_size_out;
+        __vki_aligned_u64    data_in;
+        __vki_aligned_u64    data_out;
+        __vki_u32            repeat;
+        __vki_u32            duration;
+    } test;
+
+    struct { /* anonymous struct used by BPF_*_GET_*_ID */
+        union {
+            __vki_u32        start_id;
+            __vki_u32        prog_id;
+            __vki_u32        map_id;
+        };
+        __vki_u32        next_id;
+    };
+
+    struct { /* anonymous struct used by BPF_OBJ_GET_INFO_BY_FD */
+        __vki_u32            bpf_fd;
+        __vki_u32            info_len;
+        __vki_aligned_u64    info;
+    } info;
+} __attribute__((aligned(8)));
+
 //----------------------------------------------------------------------
 // And that's it!
 //----------------------------------------------------------------------

Re: [Valgrind-users] valgrind --tool=exp-sgcheck on CentOS 7.4

[Jacek M. H. <jac...@gm...>]

Dear Sirs,
please find attached the output from:

valgrind --tool=exp-sgcheck --trace-flags=11000000 /bin/ls

Hope it helps,
Best regards,
Jacek.