valgrind-users — General discussion list for Valgrind users

[Valgrind-users] vgdb : vgdb-pipe-shared-mem unexpected size

[Frederique Silber-C. <fre...@gm...>]

Hello,

I am using callgrind on Linux. I get an error when using callgrind_control
and I cannot find out where it's coming from.

$ valgrind –version

valgrind-3.13.0

$ callgrind_control --version

callgrind_control-3.13.0



Callgrind is working fine but when using callgrind_control, I have the
following error:



$ callgrind_control –i off

error size shared memory file vgdb-pipe-shared-mem-vgdb-...

expecting size 40 (64bits) or 32 (32bits) got 48.

  OK.


Indeed the  vgdb-pipe-shared-mem file size is 48B. And indeed reading the
code, it's expecting 40B. Would you have any idea of what'g going wrong
here?

Thank you,
Frederique.

[Valgrind-users] 答复: [HELP] I run the valgrind in the unreleased android version(arm32), I am confused by function stack. Can you show me why?

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

Hi John：
	I follow your instruction that upgrade the valgrind  from 3.12 to 3.13.   It seem to be okay, Thank you. I did not find any change in the vg_preload.c vg_redir.c .  Can you tell me why the error  do not occur.

	But there is some mistake, I  still need to find out why.
	
	I run the aarch64 Application, with valgrind 3.13..
	It show me this error:
==23233== Mismatched free() / delete / delete []
==23233==    at 0x582144C: operator delete[](void*) (vg_replace_malloc.c:620)
==23233==    by 0x531351B: android::List<android::sp<android::IVPBuffer> >::~List() (List.h:174)
==23233==    by 0x5313233: RPCParcel::~RPCParcel() (RPCParcel.h:166)
==23233==    by 0x5313273: RPCParcel::~RPCParcel() (RPCParcel.h:162)
==23233==    by 0x9DCFA2F: android::RefBase::decStrong(void const*) const (RefBase.cpp:434)
==23233==    by 0x5312E8B: android::sp<IRPCParam>::~sp() (StrongPointer.h:157)
==23233==    by 0x53127E7: test_xvAlloc_proxy(char*, int) (test7.cpp:21)
==23233==    by 0x5313037: processAlgo (test7.cpp:45)
==23233==    by 0x55B1CAB: android::PPAlgorithmEngine::processAlgo(void*, int, android::imageBufInfos*) (PPAlgorithmEngine.cpp:237)
==23233==    by 0xA3561D7: Call(void*, unsigned int, double*) (ivptest.cpp:166)
==23233==    by 0x11D00B: CHECK_STUB_IVP_ALLOCDualTile_Test::TestBody() (testIT_xvAlloc.cpp:27)
==23233==    by 0x14BEDF: testing::Test::Run() (gtest.cc:0)
==23233==  Address 0x4ae91c0 is 0 bytes inside a block of size 24 alloc'd
==23233==    at 0x582082C: operator new(unsigned long) (vg_replace_malloc.c:333)----------------------------------------show me  I call new() function  not new[]
==23233==    by 0x531349F: android::List<android::sp<android::IVPBuffer> >::prep() (List.h:294)
==23233==    by 0x53130D3: android::List<android::sp<android::IVPBuffer> >::List() (List.h:166)
==23233==    by 0x531285F: RPCParcel::RPCParcel() (RPCParcel.h:146)
==23233==    by 0x53126EB: test_xvAlloc_proxy(char*, int) (test7.cpp:10)
==23233==    by 0x5313037: processAlgo (test7.cpp:45)
==23233==    by 0x55B1CAB: android::PPAlgorithmEngine::processAlgo(void*, int, android::imageBufInfos*) (PPAlgorithmEngine.cpp:237)
==23233==    by 0xA3561D7: Call(void*, unsigned int, double*) (ivptest.cpp:166)
==23233==    by 0x11D00B: CHECK_STUB_IVP_ALLOCDualTile_Test::TestBody() (testIT_xvAlloc.cpp:27)
==23233==    by 0x14BEDF: testing::Test::Run() (gtest.cc:0)
==23233==    by 0x14C9EB: testing::TestInfo::Run() (gtest.cc:2655)
==23233==    by 0x14CE57: testing::TestCase::Run() (gtest.cc:2773)

And then I objdump the so , the machine code show me as below:
 000000000000446c <android::List<android::sp<android::IVPBuffer> >::prep()>:
_ZN7android4ListINS_2spINS_9IVPBufferEEEE4prepEv():
system/core/libutils/include/utils/List.h:293
    446c:	d10083ff 	sub	sp, sp, #0x20
    4470:	a9017bfd 	stp	x29, x30, [sp,#16]
    4474:	910043fd 	add	x29, sp, #0x10
    4478:	b27d07e8 	orr	x8, xzr, #0x18
    447c:	f90007e0 	str	x0, [sp,#8]
    4480:	f94007e0 	ldr	x0, [sp,#8]
system/core/libutils/include/utils/List.h:294
    4484:	f90003e0 	str	x0, [sp]
    4488:	aa0803e0 	mov	x0, x8
    448c:	97fffb8b 	bl	32b8 <operator new[](unsigned long)@plt> -------------------It show me I used the new[] function not the new(),but valgrind show me I used the new()
    4490:	f94003e8 	ldr	x8, [sp]
    4494:	f9000500 	str	x0, [x8,#8]
system/core/libutils/include/utils/List.h:295
    4498:	f9400500 	ldr	x0, [x8,#8]
    449c:	f9400501 	ldr	x1, [x8,#8]
    44a0:	9400002a 	bl	4548 <android::List<android::sp<android::IVPBuffer> >::_Node::setPrev(android::List<android::sp<android::IVPBuffer> >::_Node*)>
system/core/libutils/include/utils/List.h:296
    44a4:	f94003e8 	ldr	x8, [sp]
    44a8:	f9400500 	ldr	x0, [x8,#8]
    44ac:	f9400501 	ldr	x1, [x8,#8]
    44b0:	9400002e 	bl	4568 <android::List<android::sp<android::IVPBuffer> >::_Node::setNext(android::List<android::sp<android::IVPBuffer> >::_Node*)>
system/core/libutils/include/utils/List.h:297
    44b4:	a9417bfd 	ldp	x29, x30, [sp,#16]
    44b8:	910083ff 	add	sp, sp, #0x20
    44bc:	d65f03c0 	ret
BR
Owen



-----邮件原件-----
发件人: John Reiser [mailto:jr...@bi...] 
发送时间: 2018年4月5日 12:17
收件人: val...@li...
主题: Re: [Valgrind-users] [HELP] I run the valgrind in the unreleased android version(arm32), I am confused by function stack. Can you show me why?

>              Why I call the strcmp, but function stack show that the 
> strcat is  called not the strcmp, but the file is belong to the 
> function strcmp
>              Can you show the how to replace the strcmp with “STRCMP(VG_Z_LIBC_SONAME,          strcmp)”, and then  I can follow the code to find out why.
> 
>              I can find the code you set the LD_PRELOAD ,  but symbol name  is not match,  I do not know how you replace the strcmp with STRCMP(VG_Z_LIBC_SONAME,          strcmp).
>              Can  you help to point out the function do the job 
> replace the strcmp with STRCMP(VG_Z_LIBC_SONAME,          strcmp)”,
> 
> Valgrind 3.12.
> CPU:arm

#include <errno.h>
#include <limits.h>
#include <stdatomic.h>
#include <string.h>
#include <sys/cdefs.h>
#include <sys/mman.h>
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>

_Atomic(unsigned int ) g_status;

#define __unused /*empty*/
#define __predict_true /*empty*/

int main(int argc __unused , char ** argv __unused ) {
         unsigned int init = 1;
         int flag = 1;
         unsigned int expect = random();
         unsigned int value = 2;
         atomic_init(&g_status, init);

         if (__predict_true(atomic_compare_exchange_strong_explicit(&g_status, &expect,
                              value, memory_order_acquire, memory_order_relaxed))) {
             flag = 0;
         }

         printf("Done  flag:%d cmp:%d \n", flag, strcmp("aaaa", "cccc") );
         return  1;
}


The compiler name and version were not specified.  I used:
	gcc (GCC) 8.0.1 20180324 (Red Hat 8.0.1-0.20) As shown, I had to #define the symbols __unused and __predict_true.


> Valgrind show me output :
> ==30141== Invalid write of size 4
> ==30141== at 0x4C27CAE: strcat(strcmp.c:3) ==30141==    by 0x108871: 
> main (testClang.c:27) ==30141==  Address 0xfeb445bc is on thread 1's 
> stack ==30141==  12 bytes below stack pointer

Using valgrind-3.13 on Fedora 28 beta for armv7l (armhfp; 32-bit ARM):
$ valgrind ./predict
==2012== Memcheck, a memory error detector ==2012== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==2012== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info ==2012== Command: ./predict ==2012== Done  flag:1 cmp:-1 ==2012== ==2012== HEAP SUMMARY:
==2012==     in use at exit: 0 bytes in 0 blocks
==2012==   total heap usage: 1 allocs, 1 frees, 1,024 bytes allocated
==2012==
==2012== All heap blocks were freed -- no leaks are possible ==2012== ==2012== For counts of detected and suppressed errors, rerun with: -v ==2012== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

------------------------------------------------------------------------------
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] I run the valgrind in the unreleased android version(arm32), I am confused by function stack. Can you show me why?

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

>          printf("Done  flag:%d cmp:%d \n", flag, strcmp("aaaa", "cccc") ); ---------this line is number 27

> ==30141== Invalid write of size 4
> ==30141== at 0x4C27CAE: strcat(strcmp.c:3)
> ==30141==    by 0x108871: main (testClang.c:27)
> ==30141==  Address 0xfeb445bc is on thread 1's stack
> ==30141==  12 bytes below stack pointer

Show us the generated code for the printf statement:
	(gdb) disassemble main
then copy+paste everything from the code for "flag = 0;"
to the code for "return 1;"

Re: [Valgrind-users] [HELP] I run the valgrind in the unreleased android version(arm32), I am confused by function stack. Can you show me why?

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

>              Why I call the strcmp, but function stack show that the strcat is  called not the strcmp, but the file is belong to the function strcmp
>              Can you show the how to replace the strcmp with “STRCMP(VG_Z_LIBC_SONAME,          strcmp)”, and then  I can follow the code to find out why.
> 
>              I can find the code you set the LD_PRELOAD ,  but symbol name  is not match,  I do not know how you replace the strcmp with STRCMP(VG_Z_LIBC_SONAME,          strcmp).
>              Can  you help to point out the function do the job replace the strcmp with STRCMP(VG_Z_LIBC_SONAME,          strcmp)”,
> 
> Valgrind 3.12.
> CPU:arm

#include <errno.h>
#include <limits.h>
#include <stdatomic.h>
#include <string.h>
#include <sys/cdefs.h>
#include <sys/mman.h>
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>

_Atomic(unsigned int ) g_status;

#define __unused /*empty*/
#define __predict_true /*empty*/

int main(int argc __unused , char ** argv __unused ) {
         unsigned int init = 1;
         int flag = 1;
         unsigned int expect = random();
         unsigned int value = 2;
         atomic_init(&g_status, init);

         if (__predict_true(atomic_compare_exchange_strong_explicit(&g_status, &expect,
                              value, memory_order_acquire, memory_order_relaxed))) {
             flag = 0;
         }

         printf("Done  flag:%d cmp:%d \n", flag, strcmp("aaaa", "cccc") );
         return  1;
}


The compiler name and version were not specified.  I used:
	gcc (GCC) 8.0.1 20180324 (Red Hat 8.0.1-0.20)
As shown, I had to #define the symbols __unused and __predict_true.


> Valgrind show me output :
> ==30141== Invalid write of size 4
> ==30141== at 0x4C27CAE: strcat(strcmp.c:3)
> ==30141==    by 0x108871: main (testClang.c:27)
> ==30141==  Address 0xfeb445bc is on thread 1's stack
> ==30141==  12 bytes below stack pointer

Using valgrind-3.13 on Fedora 28 beta for armv7l (armhfp; 32-bit ARM):
$ valgrind ./predict
==2012== Memcheck, a memory error detector
==2012== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==2012== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==2012== Command: ./predict
==2012==
Done  flag:1 cmp:-1
==2012==
==2012== HEAP SUMMARY:
==2012==     in use at exit: 0 bytes in 0 blocks
==2012==   total heap usage: 1 allocs, 1 frees, 1,024 bytes allocated
==2012==
==2012== All heap blocks were freed -- no leaks are possible
==2012==
==2012== For counts of detected and suppressed errors, rerun with: -v
==2012== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

Re: [Valgrind-users] [Bug] There is the bug about valgrind decode armv8 thumb instruction

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

>                  When the machine code is 0x4503,   the op is cmp,   but this is the T2 format , N bit(7-bit) is 0 ,  so   the thumb instrunction cmp-hi  is unhandled. And the decode action is failure .
> 
>                  The 0x4503 machine code is generate by clang4.0\5.0\6.0, the machine  cpu can run this machine.
    <<snip>>

No, the hardware documentation says that the result is UNPREDICATBLE.

> */T2 variant/*
> 
> CMP{<c>}{<q>} <Rn>, <Rm> // <Rn> and <Rm> not both from R0-R7
> 
> */Decode for this encoding/*
> 
> n = UInt(N:Rn); m = UInt(Rm);
> 
> (shift_t, shift_n) = (SRType_LSL, 0);
> 
> if n < 8 && m < 8 then UNPREDICTABLE;

When the instruction is 0x4503, then N:Rn (bits 7,2,1,0) is 3,
and Rm(bits 6,5,4,3) is 0.  Both effective register numbers
are less than 8, so this is an UNPREDICTABLE case.
The compiler/assembler made a mistake.

[Valgrind-users] [Bug] There is the bug about valgrind decode armv8 thumb instruction

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

Hi
                When the machine code is 0x4503,   the op is cmp,   but this is the T2 format , N bit(7-bit) is 0 ,  so   the thumb instrunction cmp-hi  is unhandled. And the decode action is failure .

                The 0x4503 machine code is generate by clang4.0\5.0\6.0, the machine  cpu can run this machine.


                The valgrind  source  is below ,  valgrind 3.12 , 3.13, 3.14 is the same:

                The guest_arm_toIR.c
                   case BITS8(0,1,0,0,0,1,0,1): {
      /* ---------------- CMP(HI) Rd, Rm ---------------- */
      UInt h1 = INSN0(7,7);
      UInt h2 = INSN0(6,6);
      UInt rM = (h2 << 3) | INSN0(5,3);
      UInt rN = (h1 << 3) | INSN0(2,0);
      if (h1 != 0 || h2 != 0) {   -------------------when h1 is zero, it mean cmp-hi instruction is not handle, and the decode is failured.,  and I comment this line ,the result is okay. Is it okay.
        IRTemp argL  = newTemp(Ity_I32);
         IRTemp argR  = newTemp(Ity_I32);
         assign( argL, getIRegT(rN) );
         assign( argR, getIRegT(rM) );
         /* Update flags regardless of whether in an IT block or not. */
         setFlags_D1_D2( ARMG_CC_OP_SUB, argL, argR, condT );
         DIP("cmphi r%u, r%u\n", rN, rM);
         goto decode_success;
      }
      break;
   }


                CMP T2 format:
T2
[cid:image001.png@01D3CC57.350C3590]

T2 variant
CMP{<c>}{<q>} <Rn>, <Rm> // <Rn> and <Rm> not both from R0-R7
Decode for this encoding
n = UInt(N:Rn); m = UInt(Rm);
(shift_t, shift_n) = (SRType_LSL, 0);
if n < 8 && m < 8 then UNPREDICTABLE;
if n == 15 || m == 15 then UNPREDICTABLE;

CONSTRAINED UNPREDICTABLE behavior
If n < 8 && m < 8, then one of the following behaviors must occur:
* The instruction is UNDEFINED.
* The instruction executes as NOP.
* The instruction executes as described, with no change to its behavior and no additional side effects.
* The condition flags become UNKNOWN.


BR
Owen

[Valgrind-users] [HELP] I run the valgrind in the unreleased android version(arm32), I am confused by function stack. Can you show me why?

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

HI
            Why I call the strcmp, but function stack show that the strcat is  called not the strcmp, but the file is belong to the function strcmp

            Can you show the how to replace the strcmp with "STRCMP(VG_Z_LIBC_SONAME,          strcmp)", and then  I can follow the code to find out why.

            I can find the code you set the LD_PRELOAD ,  but symbol name  is not match,  I do not know how you replace the strcmp with STRCMP(VG_Z_LIBC_SONAME,          strcmp).

            Can  you help to point out the function do the job replace the strcmp with STRCMP(VG_Z_LIBC_SONAME,          strcmp)",


Valgrind 3.12.
CPU:arm

The source as below:
#include <errno.h>
#include <limits.h>
#include <stdatomic.h>
#include <string.h>
#include <sys/cdefs.h>
#include <sys/mman.h>
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>


_Atomic(unsigned int ) g_status;


int main(int argc __unused , char ** argv __unused ) {
        unsigned int init = 1;
        int flag = 1;
        unsigned int expect = random();
        unsigned int value = 2;
        atomic_init(&g_status, init);

        if (__predict_true(atomic_compare_exchange_strong_explicit(&g_status, &expect,
                             value, memory_order_acquire, memory_order_relaxed))) {
            flag = 0;
        }

        printf("Done  flag:%d cmp:%d \n", flag, strcmp("aaaa", "cccc") ); ---------this line is number 27
        return  1;
}


Valgrind show me output :
==30141== Invalid write of size 4
==30141==    at 0x4C27CAE: strcat (strcmp.c:3)
==30141==    by 0x108871: main (testClang.c:27)
==30141==  Address 0xfeb445bc is on thread 1's stack
==30141==  12 bytes below stack pointer

BR
Owen

Re: [Valgrind-users] valgrind on Octeon III

[<pau...@ke...>]

# /lib/libc-2.16.so
GNU C Library stable release version 2.16, by Roland McGrath et al.
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 4.7.0.
Compiled on a Linux 3.10.59 system on 2017-01-24.
Available extensions:
        crypt add-on version 2.1 by Michael Glad and others
        GNU Libidn by Simon Josefsson
        Native POSIX Threads Library by Ulrich Drepper et al
        Support for some architectures added on, not maintained in glibc core.
        BIND-8.2.3-T5B
libc ABIs: MIPS_PLT UNIQUE
For bug reporting instructions, please see:
<http://www.gnu.org/software/libc/bugs.html>.

# mips64-octeon-linux-gnu-gcc --version
mips64-octeon-linux-gnu-gcc (Cavium Inc. Version: SDK_BUILD build 50) 4.7.0

# uname -a
Linux xxx 3.10 #1 SMP Fri Jun 9 01:09:35 PDT 2017 mips64 GNU/Linux

-----Original Message-----
From: John Reiser [mailto:jr...@bi...] 
Sent: Wednesday, March 21, 2018 12:08 PM
To: val...@li...
Subject: Re: [Valgrind-users] valgrind on Octeon III

> I'm trying to get valgrind to work on a Cavium Octeon III target. I've managed to run configure+make (MIPS64 target with soft-float ... couldn't get hard-float to build) and install the binaries on the target, but can't get past Bus Errors:

Please state the versions of /lib/libc-2.16.so, gcc ("gcc --version") and your Linux kernel ("uname -a").

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fsdm.link%2Fslashdot&data=02%7C01%7C%7C7735b69ccf6849b4802308d58f460bcc%7C63545f2732324d74a44dcdd457063402%7C1%7C1%7C636572453365685077&sdata=vfcLPOKQRs9r2aDDjM5F%2FuDTKZMh%2FZD47rFvcYeLZzE%3D&reserved=0
_______________________________________________
Valgrind-users mailing list
Val...@li...
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fvalgrind-users&data=02%7C01%7C%7C7735b69ccf6849b4802308d58f460bcc%7C63545f2732324d74a44dcdd457063402%7C1%7C1%7C636572453365685077&sdata=wSZuS7YmaEKTX43q0LewU6%2BQ9nJyl%2Bo4tF2yuCrrnOQ%3D&reserved=0

Re: [Valgrind-users] valgrind on Octeon III

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

> I’m trying to get valgrind to work on a Cavium Octeon III target. I’ve managed to run configure+make (MIPS64 target with soft-float … couldn’t get hard-float to build) and install the binaries on the target, but can’t get past Bus Errors:

Please state the versions of /lib/libc-2.16.so, gcc ("gcc --version")
and your Linux kernel ("uname -a").

[Valgrind-users] valgrind on Octeon III

[<pau...@ke...>]

I'm trying to get valgrind to work on a Cavium Octeon III target. I've managed to run configure+make (MIPS64 target with soft-float ... couldn't get hard-float to build) and install the binaries on the target, but can't get past Bus Errors:

# valgrind ls
==41605== Memcheck, a memory error detector
==41605== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==41605== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==41605== Command: ls
==41605==
==41605== Invalid read of size 8
==41605==    at 0x4206EE4: __ctype_init (in /lib/libc-2.16.so)
==41605==    by 0x41F7C8C: _init (in /lib/libc-2.16.so)
==41605==    by 0x40129D8: call_init (in /lib/ld-2.16.so)
==41605==    by 0x4012BC8: _dl_init (in /lib/ld-2.16.so)
==41605==    by 0x400328C: _dl_start_user (in /lib/ld-2.16.so)
==41605==  Address 0xffffffffffff9000 is not stack'd, malloc'd or (recently) free'd
==41605==
==41605==
==41605== Process terminating with default action of signal 10 (SIGBUS): dumping core
==41605==    at 0x4206EE4: __ctype_init (in /lib/libc-2.16.so)
==41605==    by 0x41F7C8C: _init (in /lib/libc-2.16.so)
==41605==    by 0x40129D8: call_init (in /lib/ld-2.16.so)
==41605==    by 0x4012BC8: _dl_init (in /lib/ld-2.16.so)
==41605==    by 0x400328C: _dl_start_user (in /lib/ld-2.16.so)
==41605== Invalid read of size 4
==41605==    at 0x4019508: __dl_runtime_resolve (in /lib/ld-2.16.so)
==41605==    by 0x40192D8: _dl_runtime_resolve (in /lib/ld-2.16.so)
==41605==  Address 0xffffffffffff8900 is not stack'd, malloc'd or (recently) free'd
==41605==
==41605==
==41605== Process terminating with default action of signal 10 (SIGBUS)
==41605==    at 0x4019508: __dl_runtime_resolve (in /lib/ld-2.16.so)
==41605==    by 0x40192D8: _dl_runtime_resolve (in /lib/ld-2.16.so)
==41605==
==41605== HEAP SUMMARY:
==41605==     in use at exit: 0 bytes in 0 blocks
==41605==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==41605==
==41605== All heap blocks were freed -- no leaks are possible
==41605==
==41605== For counts of detected and suppressed errors, rerun with: -v
==41605== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)
Bus error

I've tried with other executables as well and pretty much the same thing always happens: bus error very early in execution.

Any guidance would be appreciated.

Paul

Re: [Valgrind-users] Massif xtree

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

On Mon, 2018-03-19 at 22:31 +0100, Paul Floyd wrote:
> Hi
> 
> I’ve been using Massif recently and I gave the xtree output a go (using the callgrind format output).
> 
> Am I right in saying that, by default, the stats given are for the entire run?
Yes.

>  This means that the total allocs/frees give a good idea of the memory churn for the run.
Yes.

>  However, the ‘currently allocated’ will be that on program exit.
Yes.

> 
> Is there any easy way to get the ‘currently allocated’ snapshot at the moment of the peak memory use?
Not that I see.

>  I guess that it’s possible to do one run to find the peak and then another run and use the gdbserver and the xtmemory command.
Yes, that is currently the only way I see.

What could be done relatively easily is to add an option to massif to dump the
detailed snapshots in callgrind format.

Philippe

[Valgrind-users] Massif xtree

[Paul F. <pj...@wa...>]

Hi

I’ve been using Massif recently and I gave the xtree output a go (using the callgrind format output).

Am I right in saying that, by default, the stats given are for the entire run? This means that the total allocs/frees give a good idea of the memory churn for the run. However, the ‘currently allocated’ will be that on program exit.

Is there any easy way to get the ‘currently allocated’ snapshot at the moment of the peak memory use? I guess that it’s possible to do one run to find the peak and then another run and use the gdbserver and the xtmemory command.

A+
Paul

Re: [Valgrind-users] Unhandled instruction bytes (C++, x86 on amd64)

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

On 16/03/18 17:16, John Reiser wrote:
> On 03/16/2018 1439 UTC, Zack Weinberg wrote:
>> On Fri, Mar 16, 2018 at 1323 UTC, John Reiser wrote:
>>>
>>> The code 0x67 0xE8 0x7D 0xFF is "addr32 callq ...".  Valgrind is 
>>> complaining
>>> about the 'addr32' opcode prefix.  The compiler for locale_init.cc did a
>>> not-so-good job.  The addr32 prefix is a total waste; remove it.
>>
>> This _could_ be an alignment hack.  I don't see any of these prefixes
>> in my copy of libstdc++ but the compiler could plausibly be trying to
>> make the instruction right after the call be on a tidy address
>> boundary.
> 
> The 0x67 was at 0x48cc63d which is (-3 mod 16), so the following 
> instruction
> is at (+3 mod 16) [1 for the 0x67, 1 for the 0xE8, 4 for the 32-bit 
> displacement].
> Alignment was not close to any auspicious boundary.

We figured out the cause on IRC and it's all down to this:

https://sourceware.org/ml/binutils/2016-05/msg00322.html

Basically code compiled with -fno-plt causes the linker to do
it when it needs to patch an indirect call without changing the
length of the instruction.

Tom

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

Re: [Valgrind-users] Unhandled instruction bytes (C++, x86 on amd64)

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

On 03/16/2018 1439 UTC, Zack Weinberg wrote:
> On Fri, Mar 16, 2018 at 1323 UTC, John Reiser wrote:
>>
>> The code 0x67 0xE8 0x7D 0xFF is "addr32 callq ...".  Valgrind is complaining
>> about the 'addr32' opcode prefix.  The compiler for locale_init.cc did a
>> not-so-good job.  The addr32 prefix is a total waste; remove it.
> 
> This _could_ be an alignment hack.  I don't see any of these prefixes
> in my copy of libstdc++ but the compiler could plausibly be trying to
> make the instruction right after the call be on a tidy address
> boundary.

The 0x67 was at 0x48cc63d which is (-3 mod 16), so the following instruction
is at (+3 mod 16) [1 for the 0x67, 1 for the 0xE8, 4 for the 32-bit displacement].
Alignment was not close to any auspicious boundary.

Re: [Valgrind-users] Unhandled instruction bytes (C++, x86 on amd64)

[Zack W. <za...@pa...>]

On Fri, Mar 16, 2018 at 9:23 AM, John Reiser <jr...@bi...> wrote:
>
> The code 0x67 0xE8 0x7D 0xFF is "addr32 callq ...".  Valgrind is complaining
> about the 'addr32' opcode prefix.  The compiler for locale_init.cc did a
> not-so-good job.  The addr32 prefix is a total waste; remove it.

This _could_ be an alignment hack.  I don't see any of these prefixes
in my copy of libstdc++ but the compiler could plausibly be trying to
make the instruction right after the call be on a tidy address
boundary.

Re: [Valgrind-users] Unhandled instruction bytes (C++, x86 on amd64)

[Lars C. <la...@be...>]

On Fri, Mar 16, 2018 at 2:23 PM, John Reiser <jr...@bi...> wrote:

> When I compile this simple C++ program as a 32-bit executable on a 64-bit
>> linux:
>>
>> #include <iostream>
>> int main() {
>>          std::cout << "Hello, World!" << std::endl;
>>          return 0;
>> }
>>
>> Using the -m32 option:
>>
>> g++ -m32 out.cpp
>>
>> Valgrind chokes on an supposedly illegal instruction:
>>
>> vex x86->IR: unhandled instruction bytes: 0x67 0xE8 0x7D 0xFF
>> ==18453== valgrind: Unrecognised instruction at address 0x48cc63d.
>> ==18453==    at 0x48CC63D: std::locale::locale() (locale_init.cc:250)
>>
>
> Thank you for stating the versions valgrind-3.13.0 and Linux lnx
> 4.14.12-1-ARCH.
> However you omitted two important versions: "g++ --version"
> and the flavor and version of the runtime library containing locale_init.cc
> which is where the unhandled instruction bytes occur.
>

$ ldd ./a.out
        libstdc++.so.6 => /usr/lib32/libstdc++.so.6 (0xf7e20000)

$ strings /usr/lib32/libstdc++.so.6 | grep GCC:
GCC: (GNU) 7.2.1 20171224
GCC: (GNU) 7.2.1 20171215

$ g++ --version
g++ (GCC) 7.2.1 20171224

I have also upgraded to GCC 7.3.0, with the exact same result.

On Fri, Mar 16, 2018 at 3:11 PM, John Reiser <jr...@bi...> wrote:

> The code 0x67 0xE8 0x7D 0xFF is "addr32 callq ...".  Valgrind is
>> complaining
>> about the 'addr32' opcode prefix.  The compiler for locale_init.cc did a
>> not-so-good job.  The addr32 prefix is a total waste; remove it.
>>
>> Re-compile locale_init.cc with a better compiler.
>>
>
> Also fixed in https://bugs.kde.org/show_bug.cgi?id=384230


Appreciated. Thanks!

Re: [Valgrind-users] Unhandled instruction bytes (C++, x86 on amd64)

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

> The code 0x67 0xE8 0x7D 0xFF is "addr32 callq ...".  Valgrind is complaining
> about the 'addr32' opcode prefix.  The compiler for locale_init.cc did a
> not-so-good job.  The addr32 prefix is a total waste; remove it.
> 
> Re-compile locale_init.cc with a better compiler.

Also fixed in https://bugs.kde.org/show_bug.cgi?id=384230

Re: [Valgrind-users] Unhandled instruction bytes (C++, x86 on amd64)

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

> When I compile this simple C++ program as a 32-bit executable on a 64-bit linux:
> 
> #include <iostream>
> int main() {
>          std::cout << "Hello, World!" << std::endl;
>          return 0;
> }
> 
> Using the -m32 option:
> 
> g++ -m32 out.cpp
> 
> Valgrind chokes on an supposedly illegal instruction:
> 
> vex x86->IR: unhandled instruction bytes: 0x67 0xE8 0x7D 0xFF
> ==18453== valgrind: Unrecognised instruction at address 0x48cc63d.
> ==18453==    at 0x48CC63D: std::locale::locale() (locale_init.cc:250)

Thank you for stating the versions valgrind-3.13.0 and Linux lnx 4.14.12-1-ARCH.
However you omitted two important versions: "g++ --version"
and the flavor and version of the runtime library containing locale_init.cc
which is where the unhandled instruction bytes occur.

The code 0x67 0xE8 0x7D 0xFF is "addr32 callq ...".  Valgrind is complaining
about the 'addr32' opcode prefix.  The compiler for locale_init.cc did a
not-so-good job.  The addr32 prefix is a total waste; remove it.

Re-compile locale_init.cc with a better compiler.

[Valgrind-users] Unhandled instruction bytes (C++, x86 on amd64)

[Lars C. <la...@be...>]

When I compile this simple C++ program as a 32-bit executable on a 64-bit
linux:

#include <iostream>
int main() {
        std::cout << "Hello, World!" << std::endl;
        return 0;
}

Using the -m32 option:

g++ -m32 out.cpp

Valgrind chokes on an supposedly illegal instruction:

vex x86->IR: unhandled instruction bytes: 0x67 0xE8 0x7D 0xFF
==18453== valgrind: Unrecognised instruction at address 0x48cc63d.
==18453==    at 0x48CC63D: std::locale::locale() (locale_init.cc:250)
==18453==    by 0x48C90DD: basic_streambuf (streambuf:466)
==18453==    by 0x48C90DD: stdio_sync_filebuf (stdio_sync_filebuf.h:80)
==18453==    by 0x48C90DD: std::ios_base::Init::Init() (ios_init.cc:85)
==18453==    by 0x108793: __static_initialization_and_destruction_0(int,
int) (in /home/lac/a.out)
==18453==    by 0x1087DB: _GLOBAL__sub_I_main (in /home/lac/a.out)
==18453==    by 0x10883A: __libc_csu_init (in /home/lac/a.out)
==18453==    by 0x4ABC724: (below main) (in /usr/lib32/libc-2.26.so)

The program works fine on its own though. Same program compiled for amd64
runs fine with valgrind.

An equivalent program written in C (using printf) works just fine with
valgrind, even when compiled for x86.

Bug or user error?

$ valgrind --version
valgrind-3.13.0

$ uname -a
Linux lnx 4.14.12-1-ARCH #1 SMP PREEMPT Fri Jan 5 18:19:34 UTC 2018 x86_64
GNU/Linux

Re: [Valgrind-users] valgind with LD_PRELOAD

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

I don't think that "blocking stdout" is the problem.

More likely is just that malloc_stats doesn't work under
valgrind because malloc is diverted to be handled by valgrind
so nothing is ever allocated from the C library heap.

Maybe if there have been no allocations malloc_stats doesn't
bother to print anything?

Tom

On 08/03/18 06:58, Hari via Valgrind-users wrote:
> Hi Phillippe,
> 
> Thanks for your inputs. I got to the rootcause of the problem. The 
> signal handler written in the library which is LD_PRELOADED to my 
> process has a call to malloc_stats() which typically sends the output 
> memory statistics to stderr. I see when the process is run with 
> valgrind, the output is not written into the stdout and hence i was 
> assuming that the signal is not reaching my process.
> 
> To test this i have opened a file in the signal handler, write something 
> to it and close. When i send the signal to my process (and there by 
> valgrind), i see the file getting created. So this confirms the signal 
> is reaching the process.
> 
> However i am not sure if valgrind would block stdouts of the process it 
> is running on, since the same works properly without valgrind and all 
> the stdouts are visible.
> Thanks
> Hari
> 
> 
> ------------------------------------------------------------------------
> *From:* Philippe Waroquiers <phi...@sk...>
> *To:* Hari <har...@ya...>; val...@li...; 
> John Reiser <jr...@bi...>
> *Sent:* Wednesday, March 7, 2018 9:55 AM
> *Subject:* Re: [Valgrind-users] valgind with LD_PRELOAD
> 
> To further investigate, some more info might be useful, and some
> actions below might help.
> 
> General info:
> Which version of valgrind are you using ? On which platform ?
> 
> The function setup_client_env in initimg-linux.c is responsible
> to modify LD_PRELOAD (as valgrind needs to add some values there).
> To check this is working properly, you can do the below:
>    * change Bool   debug           = False; to True
> and/or
>    * do:
>      LD_PRELOAD=xxxxx valgrind <any shell that works under valgrind>
>          echo $LD_PRELOAD # this should show the modified by valgrind 
> LD_PRELOAD
>    (bash fails under valgrind, I tried with dash)
> 
> Please run with -v -v -v -d -d -d your program and examine the trace.
> At least at the end of execution, you should find a trace
> of the address space manager showing which files are mapped,
> and that should contain your preloaded library.
> 
> If LD_PRELOAD is correct, but the lib is not mapped, then
> you might trace ld.so using LD_DEBUG
> (see man ld.so)
> 
> If the lib is loaded, but no signals seems to arrive,
> you might try:
>      valgrind --trace-signals=yes sleep 100000
> and in another shell, send the signal to the valgrind pid
> and observe the trace (which should show the signal arriving)
> Then do the same but when valgrind runs your program.
> 
> Philippe
> 
> 
> 
> On Mon, 2018-03-05 at 11:12 +0000, Hari via Valgrind-users wrote:
>  > Hi John,
>  >
>  > Thanks for your inputs. I tried both --trace-signals=yes and strace 
> options indicated but i could not see any traces of signal sent reaching 
> my_process.
>  >
>  > I suspect if LD_PRELOAD itself did not happen with the following 
> command to my_process
>  >
>  > LD_PRELOAD=./libfake.so valgrind ./my_process
>  >
>  > Is there a different way to make sure that LD_PRELOAD done above is 
> indeed successful? I checked few online portals and i see 
> /proc/<pid>/maps (pid of my_process) and i see references to the 
> libfake.so. Does this confirm that LD_PRELOAD is indeed successful? Is 
> there any other way to trace where the signal is reaching?
>  >
>  > Thanks
>  > Hari
>  >
>  >
>  > On Wednesday, February 28, 2018, 9:43:29 AM GMT+5:30, John Reiser 
> <jr...@bi... <mailto:jr...@bi...>> wrote:
>  >
>  >
>  > > LD_PRELOAD=./libfake.so ./my_process --> runs fine and prints 
> memory stats
>  > >
>  > > But,
>  > >
>  > > LD_PRELOAD=./libfake.so valgrind ./my_process --> doesnt print the 
> memory stats
>  > >
>  > >  From few online blogs, i understand that valgrind does forward any 
> signals to the child process that it is running on but it doesnt seem to 
> work here.
>  >
>  > There is no parent-child relationship between valgrind and ./my_process.
>  > Both valgrind and ./my_process run in the same address space as just 
> one process.
>  > The inter-process communication would be extremely expensive if valgrind
>  > and ./my_process did not share the same address space, and memcheck 
> tracking
>  > of each memory access would be difficult if there were 2 threads of 
> control.
>  >
>  > The command-line parameter "--trace-signals=yes" causes valgrind to 
> report on signals.
>  > The Linux utility /usr/bin/strace also reports on signals.  (Probably use
>  > something like "strace -e trace=file" to reduce the syscalls that 
> strace reports;
>  > in particular 'read' and 'write' are usually heavily used and ignorable.)
>  >
>  >
>  > 
> ------------------------------------------------------------------------------
>  > 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... 
> <mailto: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... 
> <mailto: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
> 


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

Re: [Valgrind-users] valgind with LD_PRELOAD

[Hari <har...@ya...>]

Hi Phillippe,
Thanks for your inputs. I got to the rootcause of the problem. The signal handler written in the library which is LD_PRELOADED to my process has a call to malloc_stats() which typically sends the output memory statistics to stderr. I see when the process is run with valgrind, the output is not written into the stdout and hence i was assuming that the signal is not reaching my process.
To test this i have opened a file in the signal handler, write something to it and close. When i send the signal to my process (and there by valgrind), i see the file getting created. So this confirms the signal is reaching the process.
However i am not sure if valgrind would block stdouts of the process it is running on, since the same works properly without valgrind and all the stdouts are visible. ThanksHari

      From: Philippe Waroquiers <phi...@sk...>
 To: Hari <har...@ya...>; val...@li...; John Reiser <jr...@bi...> 
 Sent: Wednesday, March 7, 2018 9:55 AM
 Subject: Re: [Valgrind-users] valgind with LD_PRELOAD
   
To further investigate, some more info might be useful, and some
actions below might help.

General info:
Which version of valgrind are you using ? On which platform ?

The function setup_client_env in initimg-linux.c is responsible
to modify LD_PRELOAD (as valgrind needs to add some values there).
To check this is working properly, you can do the below:
  * change Bool   debug           = False; to True
and/or
  * do:
    LD_PRELOAD=xxxxx valgrind <any shell that works under valgrind>
        echo $LD_PRELOAD # this should show the modified by valgrind LD_PRELOAD
  (bash fails under valgrind, I tried with dash)

Please run with -v -v -v -d -d -d your program and examine the trace.
At least at the end of execution, you should find a trace
of the address space manager showing which files are mapped,
and that should contain your preloaded library.

If LD_PRELOAD is correct, but the lib is not mapped, then
you might trace ld.so using LD_DEBUG
(see man ld.so)

If the lib is loaded, but no signals seems to arrive,
you might try:
    valgrind --trace-signals=yes sleep 100000
and in another shell, send the signal to the valgrind pid
and observe the trace (which should show the signal arriving)
Then do the same but when valgrind runs your program.

Philippe



On Mon, 2018-03-05 at 11:12 +0000, Hari via Valgrind-users wrote:
> Hi John,
> 
> Thanks for your inputs. I tried both --trace-signals=yes and strace options indicated but i could not see any traces of signal sent reaching my_process. 
> 
> I suspect if LD_PRELOAD itself did not happen with the following command to my_process
> 
> LD_PRELOAD=./libfake.so valgrind ./my_process
> 
> Is there a different way to make sure that LD_PRELOAD done above is indeed successful? I checked few online portals and i see /proc/<pid>/maps (pid of my_process) and i see references to the libfake.so. Does this confirm that LD_PRELOAD is indeed successful? Is there any other way to trace where the signal is reaching?
> 
> Thanks
> Hari
> 
> 
> On Wednesday, February 28, 2018, 9:43:29 AM GMT+5:30, John Reiser <jr...@bi...> wrote:
> 
> 
> > LD_PRELOAD=./libfake.so ./my_process --> runs fine and prints memory stats
> > 
> > But,
> > 
> > LD_PRELOAD=./libfake.so valgrind ./my_process --> doesnt print the memory stats
> > 
> >  From few online blogs, i understand that valgrind does forward any signals to the child process that it is running on but it doesnt seem to work here.
> 
> There is no parent-child relationship between valgrind and ./my_process.
> Both valgrind and ./my_process run in the same address space as just one process.
> The inter-process communication would be extremely expensive if valgrind
> and ./my_process did not share the same address space, and memcheck tracking
> of each memory access would be difficult if there were 2 threads of control.
> 
> The command-line parameter "--trace-signals=yes" causes valgrind to report on signals.
> The Linux utility /usr/bin/strace also reports on signals.  (Probably use
> something like "strace -e trace=file" to reduce the syscalls that strace reports;
> in particular 'read' and 'write' are usually heavily used and ignorable.)
> 
> 
> ------------------------------------------------------------------------------
> 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


   

Re: [Valgrind-users] valgind with LD_PRELOAD

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

To further investigate, some more info might be useful, and some
actions below might help.

General info:
Which version of valgrind are you using ? On which platform ?

The function setup_client_env in initimg-linux.c is responsible
to modify LD_PRELOAD (as valgrind needs to add some values there).
To check this is working properly, you can do the below:
  * change Bool   debug           = False; to True
and/or
  * do:
    LD_PRELOAD=xxxxx valgrind <any shell that works under valgrind>
        echo $LD_PRELOAD # this should show the modified by valgrind LD_PRELOAD
   (bash fails under valgrind, I tried with dash)

Please run with -v -v -v -d -d -d your program and examine the trace.
At least at the end of execution, you should find a trace
of the address space manager showing which files are mapped,
and that should contain your preloaded library.

If LD_PRELOAD is correct, but the lib is not mapped, then
you might trace ld.so using LD_DEBUG
(see man ld.so)

If the lib is loaded, but no signals seems to arrive,
you might try:
    valgrind --trace-signals=yes sleep 100000
and in another shell, send the signal to the valgrind pid
and observe the trace (which should show the signal arriving)
Then do the same but when valgrind runs your program.

Philippe



On Mon, 2018-03-05 at 11:12 +0000, Hari via Valgrind-users wrote:
> Hi John,
> 
> Thanks for your inputs. I tried both --trace-signals=yes and strace options indicated but i could not see any traces of signal sent reaching my_process. 
> 
> I suspect if LD_PRELOAD itself did not happen with the following command to my_process
> 
> LD_PRELOAD=./libfake.so valgrind ./my_process
> 
> Is there a different way to make sure that LD_PRELOAD done above is indeed successful? I checked few online portals and i see /proc/<pid>/maps (pid of my_process) and i see references to the libfake.so. Does this confirm that LD_PRELOAD is indeed successful? Is there any other way to trace where the signal is reaching?
> 
> Thanks
> Hari
> 
> 
> On Wednesday, February 28, 2018, 9:43:29 AM GMT+5:30, John Reiser <jr...@bi...> wrote:
> 
> 
> > LD_PRELOAD=./libfake.so ./my_process --> runs fine and prints memory stats
> > 
> > But,
> > 
> > LD_PRELOAD=./libfake.so valgrind ./my_process --> doesnt print the memory stats
> > 
> >  From few online blogs, i understand that valgrind does forward any signals to the child process that it is running on but it doesnt seem to work here.
> 
> There is no parent-child relationship between valgrind and ./my_process.
> Both valgrind and ./my_process run in the same address space as just one process.
> The inter-process communication would be extremely expensive if valgrind
> and ./my_process did not share the same address space, and memcheck tracking
> of each memory access would be difficult if there were 2 threads of control.
> 
> The command-line parameter "--trace-signals=yes" causes valgrind to report on signals.
> The Linux utility /usr/bin/strace also reports on signals.  (Probably use
> something like "strace -e trace=file" to reduce the syscalls that strace reports;
> in particular 'read' and 'write' are usually heavily used and ignorable.)
> 
> 
> ------------------------------------------------------------------------------
> 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] VEX IR support for jumps

[Mike L. <mik...@gm...>]

Hi,

Is there support for jumping over inserted VEX IR, or would that just be
handled by a guarded dirty call?

E.g. would it make sense to insert Exit statements to instructions (IMarks)
in the same basic block?
An ITE expression doesn't seem to fit my use-case as I'm looking to jump
over a larger set of statements.

Thank you,
Mike

Re: [Valgrind-users] valgind with LD_PRELOAD

[Hari <har...@ya...>]

Hi John,
Thanks for your inputs. I tried both --trace-signals=yes and strace options indicated but i could not see any traces of signal sent reaching my_process. 
I suspect if LD_PRELOAD itself did not happen with the following command to my_process
LD_PRELOAD=./libfake.so valgrind ./my_process

Is there a different way to make sure that LD_PRELOAD done above is indeed successful? I checked few online portals and i see /proc/<pid>/maps (pid of my_process) and i see references to the libfake.so. Does this confirm that LD_PRELOAD is indeed successful? Is there any other way to trace where the signal is reaching?
ThanksHari 

    On Wednesday, February 28, 2018, 9:43:29 AM GMT+5:30, John Reiser <jr...@bi...> wrote:  
 
 > LD_PRELOAD=./libfake.so ./my_process --> runs fine and prints memory stats
> 
> But,
> 
> LD_PRELOAD=./libfake.so valgrind ./my_process --> doesnt print the memory stats
> 
>  From few online blogs, i understand that valgrind does forward any signals to the child process that it is running on but it doesnt seem to work here.

There is no parent-child relationship between valgrind and ./my_process.
Both valgrind and ./my_process run in the same address space as just one process.
The inter-process communication would be extremely expensive if valgrind
and ./my_process did not share the same address space, and memcheck tracking
of each memory access would be difficult if there were 2 threads of control.

The command-line parameter "--trace-signals=yes" causes valgrind to report on signals.
The Linux utility /usr/bin/strace also reports on signals.  (Probably use
something like "strace -e trace=file" to reduce the syscalls that strace reports;
in particular 'read' and 'write' are usually heavily used and ignorable.)

------------------------------------------------------------------------------
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 question about valgrind with clang 5.0

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

Hi
                Is there any guy focus on this issue?
BR
Owen

发件人: Wuweijia
发送时间: 2018年2月28日 15:16
收件人: val...@li...
抄送: Fanbohao <fan...@hu...>
主题: [help]There is question about valgrind with clang 5.0

Hi
                I write android  aarch32 demo , and run with valgrind, It show me invalidate write about the stack. Sorry I can not get it.

                The source as below:
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

typedef struct {
                                int d[16];
                                int v[32];
}C1;

int main(int argc, char ** argv) {
                C1 c, d, e;
                memset(&c, 0, sizeof(c));
                d = c;-----------------When compile this line , clang auto-generate the calling aebi_memcpy
                e = d;
                printf("e.d[1]=%d\n", e.d[1]);
                return 0;
}

                The error as below:
==2912== Invalid write of size 4
==2912==    at 0x4ACB8D0: memcpy (vg_replace_strmem.c:1019)
==2912==    by 0x48CD64B: __aeabi_memcpy (__aeabi.c:73)
==2912==    by 0x108719: main (test.cpp:13)
==2912==  Address 0xfe80035c is on thread 1's stack
==2912==  28 bytes below stack pointer--------------This line show me the memcpy over-write the stack memory
==2912==
==2912== Invalid write of size 4
==2912==    at 0x4ACB8D0: memcpy (vg_replace_strmem.c:1019)
==2912==    by 0x48CD64B: __aeabi_memcpy (__aeabi.c:73)
==2912==    by 0x108723: main (test.cpp:14)
==2912==  Address 0xfe80035c is on thread 1's stack
==2912==  28 bytes below stack pointer

                And then, I modify the source about libc,  I write the llt_memcpy function , replace the calling  memcpy of  __aeabi_memcpyX_impl ‘s implemention with calling llt_memcpy. And run it with valgrind , there is no error .

The modified source as below:
static void * llt_memcpy(void *dst, const void * src, size_t n) {
                char  * d = (char *)dst, *s = (char *)src;
                size_t i = 0;
                for( i = 0; i < n; i++) {
                                d[i] = s[i];
                }
                return dst;
}
void __attribute__((weak)) __aeabi_memcpy8_impl(void *dest, const void *src, size_t n) {
   memcpy(dest, src, n); ---->llt_memcpy(dest, src, n);
}

void __attribute__((weak)) __aeabi_memcpy4_impl(void *dest, const void *src, size_t n) {
   memcpy(dest, src, n); ---->llt_memcpy(dest, src, n);
}

void __attribute__((weak)) __aeabi_memcpy_impl(void *dest, const void *src, size_t n) {
    memcpy(dest, src, n); ---->llt_memcpy(dest, src, n);
}

void __attribute__((weak)) __aeabi_memcpy8_impl2(void *dest, const void *src, size_t n) {
    memcpy(dest, src, n); ----> llt_memcpy(dest, src, n);
}

void __attribute__((weak)) __aeabi_memcpy4_impl2(void *dest, const void *src, size_t n) {
   memcpy(dest, src, n); ----> llt_memcpy(dest, src, n);
}

void __attribute__((weak)) __aeabi_memcpy_impl2(void *dest, const void *src, size_t n) {
   memcpy(dest, src, n); ----> llt_memcpy(dest, src, n);
}


And I pack the runtime with(libc_memcpy.so and libc_llt_memcy.so)

Please note I call memcpy directly ( not via aeabi_memcpyX),  that is okay. No error occurs.

Is there some thing relate to place-holder about memcpy when valgrind pre-loading?

Env:
OS: android
CPU : AARCH64
Compile toolchain: NDK15C(clang 5.0)
ABI: armeabi-v7a(32-bit)
valgrind version: 3.12

BR
Owen