valgrind-users — General discussion list for Valgrind users

[Valgrind-users] Calling arbitrary guest functions

[Derrick M. <der...@gm...>]

Hi,

I am trying to make a tool that intercepts the call to main, and then
call an arbitrary function within the guest with arbitrary function
arguments.  Is this possible?  Thanks.

-- 
Derrick McKee
Phone: (703) 957-9362
Email: der...@gm...

Re: [Valgrind-users] detecting uninitialized values in debug builds

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

> However, I've also been told that the g++ compiler will initialize all stack objects to zero when compiling for debug (the -g option).  Yet, valgrind still detects the un-init condition.

I think whoever told you that was confusing it with Microsoft Visual Studio. The default debug-build configuration for that IDE does initialise all variables.

--
John Dallman

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

Re: [Valgrind-users] detecting uninitialized values in debug builds

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

On 3/2/20 22:02 UTC, Ben White wrote:
> I’ve also been told that the g++ compiler will initialize all stack 
> objects to zero when compiling for debug (the -g option).

Obviously you didn't try it.  g++ 9.2.1 does not do that.

$ cat foo.cpp
int g(int x, int y);

int f(int x)
{
	int y;
         return	g(x, y);  // uninit use of y
}

$ g++ -g -S foo.cpp
$ cat foo.s
	.file	"foo.cpp"
	.text
.Ltext0:
	.globl	_Z1fi
	.type	_Z1fi, @function
_Z1fi:
.LFB0:
	.file 1 "foo.cpp"
	.loc 1 4 1
	.cfi_startproc
	pushq	%rbp
	.cfi_def_cfa_offset 16
	.cfi_offset 6, -16
	movq	%rsp, %rbp
	.cfi_def_cfa_register 6
	subq	$32, %rsp
	movl	%edi, -20(%rbp)
	.loc 1 6 17
	movl	-4(%rbp), %edx   // -4(%rbp) is never initialized
	movl	-20(%rbp), %eax
	movl	%edx, %esi   // 2nd parameter to g
	movl	%eax, %edi
	call	_Z1gii
	.loc 1 7 1
	leave
	.cfi_def_cfa 7, 8
	ret
	.cfi_endproc
.LFE0:
	.size	_Z1fi, .-_Z1fi
   [[snip]]
	.section	.debug_str,"MS",@progbits,1
.LASF1:
	.string	"foo.cpp"
.LASF0:
	.string	"GNU C++14 9.2.1 20190827 (Red Hat 9.2.1-1) -mtune=generic -march=x86-64 -g"
.LASF3:
	.string	"_Z1fi"
.LASF2:
	.string	"/home/user"
	.ident	"GCC: (GNU) 9.2.1 20190827 (Red Hat 9.2.1-1)"
	.section	.note.GNU-stack,"",@progbits
$

[Valgrind-users] detecting uninitialized values in debug builds

[Ben W. <ben...@co...>]

Hello,

I have seen cases where valgrind (memcheck) will report conditional jump or move based on uninitialized value, and when examining the relevant source code, I can see that the value or variable is indeed uninitialized.  However, I've also been told that the g++ compiler will initialize all stack objects to zero when compiling for debug (the -g option).  Yet, valgrind still detects the un-init condition.

Does anybody know how this works behind the scenes?  This is mainly a curiosity question, no need to research it.

Ben White
Diagnostics, Calibration, and Verification (DCV)
Cohu Inc.

Re: [Valgrind-users] Valgrind master fails to compile

[Jeff H. <jef...@gm...>]

The attached patches address these issues, which are caused by the correct
implementation of deprecated function deletion in Open-MPI 4.
https://www.open-mpi.org/faq/?category=mpi-removed has details.

This is my first attempted contribution to Valgrind so please let me know
if the patches need modifications to be accepted.  Do I need to state that
I license them as "GPLv2, or (at your option) any later version," in the
patches?

I would not object at all if someone wants the MPI_UB/MPI_LB workaround to
be different, since there are a bunch of valid ways to implement it.  I
suppose "#ifdef MPI_UB" etc. is simpler, but I can't remember off the top
of my head if the MPI standard requires that identifier to be a
preprocessor symbol or if that is merely common practice, so I did not want
to use a direct preprocessor test on it.

Best,

Jeff

On Sun, Mar 1, 2020 at 1:35 PM Derrick McKee <der...@gm...>
wrote:

> I am having a problem compiling Valgrind using OpenMPI 4.0.2.  The
> error is listed below.  It seems it is the same bug logged in [1].
> Has there been any patch made that resolves the issue?  Thanks.
>
> - Derrick
>
> [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=946329
>
> Error
> -----------------------------------------------------------------------
> mkdir -p ../.in_place; \
> for f in ; do \
>   rm -f ../.in_place/$f.dSYM; \
>   ln -f -s ../mpi/$f.dSYM ../.in_place; \
> done
> In file included from ../../mpi/libmpiwrap.c:116:
> ../../mpi/libmpiwrap.c: In function ‘showTy’:
> ../../mpi/libmpiwrap.c:281:19: error: expected expression before
> ‘_Static_assert’
>   281 |    else if (ty == MPI_UB)             fprintf(f,"UB");
>       |                   ^~~~~~
> ../../mpi/libmpiwrap.c:282:19: error: expected expression before
> ‘_Static_assert’
>   282 |    else if (ty == MPI_LB)             fprintf(f,"LB");
>       |                   ^~~~~~
> ../../mpi/libmpiwrap.c: In function ‘showCombiner’:
> ../../mpi/libmpiwrap.c:354:12: error: expected expression before
> ‘_Static_assert’
>   354 |       case MPI_COMBINER_HVECTOR_INTEGER: fprintf(f,
> "HVECTOR_INTEGER"); break;
>       |            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ../../mpi/libmpiwrap.c:354:12: error: expected expression before
> ‘_Static_assert’
> ../../mpi/libmpiwrap.c:354:40: error: expected expression before ‘:’ token
>   354 |       case MPI_COMBINER_HVECTOR_INTEGER: fprintf(f,
> "HVECTOR_INTEGER"); break;
>       |                                        ^
> In file included from ../../mpi/libmpiwrap.c:116:
> ../../mpi/libmpiwrap.c:359:12: error: expected expression before
> ‘_Static_assert’
>   359 |       case MPI_COMBINER_HINDEXED_INTEGER: fprintf(f,
> "HINDEXED_INTEGER"); break;
>       |            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ../../mpi/libmpiwrap.c:359:12: error: expected expression before
> ‘_Static_assert’
> ../../mpi/libmpiwrap.c:359:41: error: expected expression before ‘:’ token
>   359 |       case MPI_COMBINER_HINDEXED_INTEGER: fprintf(f,
> "HINDEXED_INTEGER"); break;
>       |                                         ^
> In file included from ../../mpi/libmpiwrap.c:116:
> ../../mpi/libmpiwrap.c:366:12: error: expected expression before
> ‘_Static_assert’
>   366 |       case MPI_COMBINER_STRUCT_INTEGER: fprintf(f,
> "STRUCT_INTEGER"); break;
>       |            ^~~~~~~~~~~~~~~~~~~~~~~~~~~
> ../../mpi/libmpiwrap.c:366:12: error: expected expression before
> ‘_Static_assert’
> ../../mpi/libmpiwrap.c:366:39: error: expected expression before ‘:’ token
>   366 |       case MPI_COMBINER_STRUCT_INTEGER: fprintf(f,
> "STRUCT_INTEGER"); break;
>       |                                       ^
> ../../mpi/libmpiwrap.c: In function ‘extentOfTy’:
> ../../mpi/libmpiwrap.c:462:8: warning: implicit declaration of
> function ‘PMPI_Type_extent’; did you mean ‘MPI_Type_extent’?
> [-Wimplicit-function-declaration]
>   462 |    r = PMPI_Type_extent(ty, &n);
>       |        ^~~~~~~~~~~~~~~~
>       |        MPI_Type_extent
> In file included from ../../mpi/libmpiwrap.c:116:
> ../../mpi/libmpiwrap.c: In function ‘walk_type’:
> ../../mpi/libmpiwrap.c:736:17: error: expected expression before
> ‘_Static_assert’
>   736 |       if (ty == MPI_LB || ty == MPI_UB)
>
> --
> Derrick McKee
> Phone: (703) 957-9362
> Email: der...@gm...
>
>
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>


-- 
Jeff Hammond
jef...@gm...
http://jeffhammond.github.io/

Re: [Valgrind-users] Valgrind master fails to compile

[Jeff H. <jef...@gm...>]

_Static_assert is C11. Are you using a compiler that supports C11 and are
you using the correct flags to activate that support?

Jeff

On Sun, Mar 1, 2020 at 1:35 PM Derrick McKee <der...@gm...>
wrote:

> I am having a problem compiling Valgrind using OpenMPI 4.0.2.  The
> error is listed below.  It seems it is the same bug logged in [1].
> Has there been any patch made that resolves the issue?  Thanks.
>
> - Derrick
>
> [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=946329
>
> Error
> -----------------------------------------------------------------------
> mkdir -p ../.in_place; \
> for f in ; do \
>   rm -f ../.in_place/$f.dSYM; \
>   ln -f -s ../mpi/$f.dSYM ../.in_place; \
> done
> In file included from ../../mpi/libmpiwrap.c:116:
> ../../mpi/libmpiwrap.c: In function ‘showTy’:
> ../../mpi/libmpiwrap.c:281:19: error: expected expression before
> ‘_Static_assert’
>   281 |    else if (ty == MPI_UB)             fprintf(f,"UB");
>       |                   ^~~~~~
> ../../mpi/libmpiwrap.c:282:19: error: expected expression before
> ‘_Static_assert’
>   282 |    else if (ty == MPI_LB)             fprintf(f,"LB");
>       |                   ^~~~~~
> ../../mpi/libmpiwrap.c: In function ‘showCombiner’:
> ../../mpi/libmpiwrap.c:354:12: error: expected expression before
> ‘_Static_assert’
>   354 |       case MPI_COMBINER_HVECTOR_INTEGER: fprintf(f,
> "HVECTOR_INTEGER"); break;
>       |            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ../../mpi/libmpiwrap.c:354:12: error: expected expression before
> ‘_Static_assert’
> ../../mpi/libmpiwrap.c:354:40: error: expected expression before ‘:’ token
>   354 |       case MPI_COMBINER_HVECTOR_INTEGER: fprintf(f,
> "HVECTOR_INTEGER"); break;
>       |                                        ^
> In file included from ../../mpi/libmpiwrap.c:116:
> ../../mpi/libmpiwrap.c:359:12: error: expected expression before
> ‘_Static_assert’
>   359 |       case MPI_COMBINER_HINDEXED_INTEGER: fprintf(f,
> "HINDEXED_INTEGER"); break;
>       |            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ../../mpi/libmpiwrap.c:359:12: error: expected expression before
> ‘_Static_assert’
> ../../mpi/libmpiwrap.c:359:41: error: expected expression before ‘:’ token
>   359 |       case MPI_COMBINER_HINDEXED_INTEGER: fprintf(f,
> "HINDEXED_INTEGER"); break;
>       |                                         ^
> In file included from ../../mpi/libmpiwrap.c:116:
> ../../mpi/libmpiwrap.c:366:12: error: expected expression before
> ‘_Static_assert’
>   366 |       case MPI_COMBINER_STRUCT_INTEGER: fprintf(f,
> "STRUCT_INTEGER"); break;
>       |            ^~~~~~~~~~~~~~~~~~~~~~~~~~~
> ../../mpi/libmpiwrap.c:366:12: error: expected expression before
> ‘_Static_assert’
> ../../mpi/libmpiwrap.c:366:39: error: expected expression before ‘:’ token
>   366 |       case MPI_COMBINER_STRUCT_INTEGER: fprintf(f,
> "STRUCT_INTEGER"); break;
>       |                                       ^
> ../../mpi/libmpiwrap.c: In function ‘extentOfTy’:
> ../../mpi/libmpiwrap.c:462:8: warning: implicit declaration of
> function ‘PMPI_Type_extent’; did you mean ‘MPI_Type_extent’?
> [-Wimplicit-function-declaration]
>   462 |    r = PMPI_Type_extent(ty, &n);
>       |        ^~~~~~~~~~~~~~~~
>       |        MPI_Type_extent
> In file included from ../../mpi/libmpiwrap.c:116:
> ../../mpi/libmpiwrap.c: In function ‘walk_type’:
> ../../mpi/libmpiwrap.c:736:17: error: expected expression before
> ‘_Static_assert’
>   736 |       if (ty == MPI_LB || ty == MPI_UB)
>
> --
> Derrick McKee
> Phone: (703) 957-9362
> Email: der...@gm...
>
>
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>
-- 
Jeff Hammond
jef...@gm...
http://jeffhammond.github.io/

[Valgrind-users] Valgrind master fails to compile

[Derrick M. <der...@gm...>]

I am having a problem compiling Valgrind using OpenMPI 4.0.2.  The
error is listed below.  It seems it is the same bug logged in [1].
Has there been any patch made that resolves the issue?  Thanks.

- Derrick

[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=946329

Error
-----------------------------------------------------------------------
mkdir -p ../.in_place; \
for f in ; do \
  rm -f ../.in_place/$f.dSYM; \
  ln -f -s ../mpi/$f.dSYM ../.in_place; \
done
In file included from ../../mpi/libmpiwrap.c:116:
../../mpi/libmpiwrap.c: In function ‘showTy’:
../../mpi/libmpiwrap.c:281:19: error: expected expression before
‘_Static_assert’
  281 |    else if (ty == MPI_UB)             fprintf(f,"UB");
      |                   ^~~~~~
../../mpi/libmpiwrap.c:282:19: error: expected expression before
‘_Static_assert’
  282 |    else if (ty == MPI_LB)             fprintf(f,"LB");
      |                   ^~~~~~
../../mpi/libmpiwrap.c: In function ‘showCombiner’:
../../mpi/libmpiwrap.c:354:12: error: expected expression before
‘_Static_assert’
  354 |       case MPI_COMBINER_HVECTOR_INTEGER: fprintf(f,
"HVECTOR_INTEGER"); break;
      |            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../mpi/libmpiwrap.c:354:12: error: expected expression before
‘_Static_assert’
../../mpi/libmpiwrap.c:354:40: error: expected expression before ‘:’ token
  354 |       case MPI_COMBINER_HVECTOR_INTEGER: fprintf(f,
"HVECTOR_INTEGER"); break;
      |                                        ^
In file included from ../../mpi/libmpiwrap.c:116:
../../mpi/libmpiwrap.c:359:12: error: expected expression before
‘_Static_assert’
  359 |       case MPI_COMBINER_HINDEXED_INTEGER: fprintf(f,
"HINDEXED_INTEGER"); break;
      |            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../mpi/libmpiwrap.c:359:12: error: expected expression before
‘_Static_assert’
../../mpi/libmpiwrap.c:359:41: error: expected expression before ‘:’ token
  359 |       case MPI_COMBINER_HINDEXED_INTEGER: fprintf(f,
"HINDEXED_INTEGER"); break;
      |                                         ^
In file included from ../../mpi/libmpiwrap.c:116:
../../mpi/libmpiwrap.c:366:12: error: expected expression before
‘_Static_assert’
  366 |       case MPI_COMBINER_STRUCT_INTEGER: fprintf(f,
"STRUCT_INTEGER"); break;
      |            ^~~~~~~~~~~~~~~~~~~~~~~~~~~
../../mpi/libmpiwrap.c:366:12: error: expected expression before
‘_Static_assert’
../../mpi/libmpiwrap.c:366:39: error: expected expression before ‘:’ token
  366 |       case MPI_COMBINER_STRUCT_INTEGER: fprintf(f,
"STRUCT_INTEGER"); break;
      |                                       ^
../../mpi/libmpiwrap.c: In function ‘extentOfTy’:
../../mpi/libmpiwrap.c:462:8: warning: implicit declaration of
function ‘PMPI_Type_extent’; did you mean ‘MPI_Type_extent’?
[-Wimplicit-function-declaration]
  462 |    r = PMPI_Type_extent(ty, &n);
      |        ^~~~~~~~~~~~~~~~
      |        MPI_Type_extent
In file included from ../../mpi/libmpiwrap.c:116:
../../mpi/libmpiwrap.c: In function ‘walk_type’:
../../mpi/libmpiwrap.c:736:17: error: expected expression before
‘_Static_assert’
  736 |       if (ty == MPI_LB || ty == MPI_UB)

-- 
Derrick McKee
Phone: (703) 957-9362
Email: der...@gm...

[Valgrind-users] Invalid read optimized build false positive

[Volker W. <vol...@gm...>]

Hello,

Valgrind reports "invalid read" in my program, but only if I compile it
with -O3 and not if I compile it with -O2, -O1 or -O0. The -g option
doesn't change this. Is it possible that valgrind reports false
positives if the -O3 option is used? If yes, how can I confirm this
message is indeed a false positive?

I couldn't find anything in the documentation except for this quote from
https://valgrind.org/docs/manual/quick-start.html:

Compile your program with |-g| to include debugging information so that
Memcheck's error messages include exact line numbers. Using |-O0| is
also a good idea, if you can tolerate the slowdown. With |-O1| line
numbers in error messages can be inaccurate, although generally speaking
running Memcheck on code compiled at |-O1| works fairly well, and the
speed improvement compared to running |-O0| is quite significant. Use of
|-O2| and above is not recommended as Memcheck occasionally reports
uninitialised-value errors which don't really exist.

But here, they only talk about uninitialised-value's and not about
invalid-reed's.


Greetings

Volker Weißmann

Re: [Valgrind-users] valgrind: Unrecognised instruction

[Ben W. <ben...@co...>]

I have never used cachegrind, but I’ve seen a similar message before when using memcheck.
In my case, the problem was that I was using the wrong version of memcheck for my CPU type.
For example, I think I was trying to run a 32-bit version of memcheck with a 64-bit executable.

Ben

From: Alexandre Azevedo <ale...@gm...>
Sent: Wednesday, February 5, 2020 10:50 AM
To: val...@li...
Subject: [Valgrind-users] valgrind: Unrecognised instruction

Hello guys,

I'm currently trying to profile my program's cache behaviour using cachegrind. I can confirm the program seems to be working as I first tested cachegrind compiling my code with GCC. The problem is that I'm now using Intel C compiler and for some reason I keep getting the same error as I try to run it with cachegrind. Following is the error message.


vex amd64->IR: unhandled instruction bytes: 0xF3 0xF 0x1E 0xFA 0x41 0x56 0x41 0x89
vex amd64->IR:   REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0
vex amd64->IR:   VEX=0 VEX.L=0 VEX.nVVVV=0x0 ESC=0F
vex amd64->IR:   PFX.66=0 PFX.F2=0 PFX.F3=1
==23029== valgrind: Unrecognised instruction at address 0x4032e0.
==23029==    at 0x4032E0: __intel_new_feature_proc_init (in /home/arthur/Documentos/Prog.Paralela/intelseqkron)
==23029==    by 0x565282F: (below main) (libc-start.c:291)
==23029== Your program just tried to execute an instruction that Valgrind
==23029== did not recognise.  There are two possible reasons for this.
==23029== 1. Your program has a bug and erroneously jumped to a non-code
==23029==    location.  If you are running Memcheck and you just saw a
==23029==    warning about a bad jump, it's probably your program's fault.
==23029== 2. The instruction is legitimate but Valgrind doesn't handle it,
==23029==    i.e. it's Valgrind's fault.  If you think this is the case or
==23029==    you are not sure, please let us know and we'll try to fix it.
==23029== Either way, Valgrind will now raise a SIGILL signal which will
==23029== probably kill your program.
==23029==
==23029== Process terminating with default action of signal 4 (SIGILL)
==23029==  Illegal opcode at address 0x4032E0
==23029==    at 0x4032E0: __intel_new_feature_proc_init (in /home/arthur/Documentos/Prog.Paralela/intelseqkron)
==23029==    by 0x565282F: (below main) (libc-start.c:291)
==23029==


My best regards,

Alexandre

Re: [Valgrind-users] valgrind: Unrecognised instruction

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

> vex amd64->IR: unhandled instruction bytes: 0xF3 0xF 0x1E 0xFA 0x41 0x56 0x41 0x89

Follow the Bug Reports link at http://valgrind.org to file a bug report
at  http://bugs.kde.org/query.cgi?format=specific .

Please be sure to state the version of valgrind.  Run "valgrind --version".

The instruction 0xF3 0xF 0x1E 0xFA is 'endbr64'.

> vex amd64->IR:   REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0
> vex amd64->IR:   VEX=0 VEX.L=0 VEX.nVVVV=0x0 ESC=0F
> vex amd64->IR:   PFX.66=0 PFX.F2=0 PFX.F3=1
> ==23029== valgrind: Unrecognised instruction at address 0x4032e0.
> ==23029==    at 0x4032E0: __intel_new_feature_proc_init (in /home/arthur/Documentos/Prog.Paralela/intelseqkron)
> ==23029==    by 0x565282F: (below main) (libc-start.c:291)

[Valgrind-users] valgrind: Unrecognised instruction

[Alexandre A. <ale...@gm...>]

Hello guys,

I'm currently trying to profile my program's cache behaviour using
cachegrind. I can confirm the program seems to be working as I first tested
cachegrind compiling my code with GCC. The problem is that I'm now using
Intel C compiler and for some reason I keep getting the same error as I try
to run it with cachegrind. Following is the error message.


vex amd64->IR: unhandled instruction bytes: 0xF3 0xF 0x1E 0xFA 0x41 0x56
0x41 0x89
vex amd64->IR:   REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0
vex amd64->IR:   VEX=0 VEX.L=0 VEX.nVVVV=0x0 ESC=0F
vex amd64->IR:   PFX.66=0 PFX.F2=0 PFX.F3=1
==23029== valgrind: Unrecognised instruction at address 0x4032e0.
==23029==    at 0x4032E0: __intel_new_feature_proc_init (in
/home/arthur/Documentos/Prog.Paralela/intelseqkron)
==23029==    by 0x565282F: (below main) (libc-start.c:291)
==23029== Your program just tried to execute an instruction that Valgrind
==23029== did not recognise.  There are two possible reasons for this.
==23029== 1. Your program has a bug and erroneously jumped to a non-code
==23029==    location.  If you are running Memcheck and you just saw a
==23029==    warning about a bad jump, it's probably your program's fault.
==23029== 2. The instruction is legitimate but Valgrind doesn't handle it,
==23029==    i.e. it's Valgrind's fault.  If you think this is the case or
==23029==    you are not sure, please let us know and we'll try to fix it.
==23029== Either way, Valgrind will now raise a SIGILL signal which will
==23029== probably kill your program.
==23029==
==23029== Process terminating with default action of signal 4 (SIGILL)
==23029==  Illegal opcode at address 0x4032E0
==23029==    at 0x4032E0: __intel_new_feature_proc_init (in
/home/arthur/Documentos/Prog.Paralela/intelseqkron)
==23029==    by 0x565282F: (below main) (libc-start.c:291)
==23029==


My best regards,

Alexandre

Re: [Valgrind-users] Valgrind Internal Error: Valgrind received a signal 11 (SIGSEGV) - exiting

[John K. <Joh...@be...>]

Hi John,

Thanks for the thoughtful analysis and suggestions on this issue.

Unfortunately, I cannot run one CCSP app by itself all of the CCSP apps are necessary and work together.  I was running valgrind on only one ccsp app, but when asking valgrind to track-origins, I guess it needed a lot more memory.  I am hoping to get a different router which has more memory now that I know what the issue is.

Thanks for your help!
John

From: John Reiser <jr...@bi...>
Sent: Thursday, January 30, 2020 9:56 PM
To: val...@li...
Subject: Re: [Valgrind-users] Valgrind Internal Error: Valgrind received a signal 11 (SIGSEGV) - exiting

> 3. How much physical RAM? How much swap space? (The string "out_of_memory" appears in the output.)
>
> JK - [    0.000000] Memory: 495376K/507904K available (5078K kernel code, 420K rwdata, 1704K rodata, 208K init, 328K bss, 12528K reserved, 0K highmem)
>
> Not sure how to get swap space.

Run /usr/bin/top, which gives other useful statistics about resources, too.
On a 32-bit ARM RaspberryPi model 2 with 1GB RAM the output might begin like this
for an "idle" machine:
=====
Tasks: 84 total, 1 running, 83 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0.1 us, 0.1 sy, 0.0 ni, 99.8 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
MiB Mem : 924.1 total, 582.1 free, 66.0 used, 276.0 buff/cache
MiB Swap: 0.0 total, 0.0 free, 0.0 used. 830.5 avail Mem
=====

>
>
> 4. Was valgrind essentially the only process running?
>
> JK - Definitely not.  The TR069 consists of a whole family of CCSP processes that communicate to each other via DBUS.  The TR069PA was however the only process running via valgrind
>
> 5. How many threads?
>
> JK - 4 threads per CCSP process, including the one running valgrind.

So there are many CCSP processes, plus other processes, running on a box with
512 megaBytes of RAM and no swap space. Remember that a process running valgrind
(memcheck) requires about 2 to 3 times the memory of a non-checked process.

You have exhausted the available RAM. The "out of memory" string was a clue.

Reduce the number and size of simultaneous CCSP processes. Reduce the number
and size non-CCSP processes. Run valgrind (memcheck) only on the one CCSP
process that really interests you. Do not use --trace-children=yes. Instead,
make CcspTr069PaSsp into an executable "wrapper" shell script which identifies
the correct instance (perhaps by count of invocations), then runs valgrind
on a saved copy of the original CcspTr069PaSsp; else just runs the
saved copy without valgrind.


_______________________________________________
Valgrind-users mailing list
Val...@li...<mailto:Val...@li...>
https://lists.sourceforge.net/lists/listinfo/valgrind-users<https://lists.sourceforge.net/lists/listinfo/valgrind-users>
__________________________________________________________________ Confidential This e-mail and any files transmitted with it are the property of Belkin International, Inc. and/or its affiliates, are confidential, and are intended solely for the use of the individual or entity to whom this e-mail is addressed. If you are not one of the named recipients or otherwise have reason to believe that you have received this e-mail in error, please notify the sender and delete this message immediately from your computer. Any other use, retention, dissemination, forwarding, printing or copying of this e-mail is strictly prohibited. Pour la version fran?aise: http://www.belkin.com/email-notice/French.html F?r die deutsche ?bersetzung: http://www.belkin.com/email-notice/German.html __________________________________________________________________

Re: [Valgrind-users] Valgrind Internal Error: Valgrind received a signal 11 (SIGSEGV) - exiting

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

> 3. How much physical RAM? How much swap space? (The string "out_of_memory" appears in the output.)
> 
> JK - [    0.000000] Memory: 495376K/507904K available (5078K kernel code, 420K rwdata, 1704K rodata, 208K init, 328K bss, 12528K reserved, 0K highmem)
> 
> Not sure how to get swap space.

Run /usr/bin/top, which gives other useful statistics about resources, too.
On a 32-bit ARM RaspberryPi model 2 with 1GB RAM the output might begin like this
for an "idle" machine:
=====
Tasks:  84 total,   1 running,  83 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0.1 us,  0.1 sy,  0.0 ni, 99.8 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
MiB Mem :    924.1 total,    582.1 free,     66.0 used,    276.0 buff/cache
MiB Swap:      0.0 total,      0.0 free,      0.0 used.    830.5 avail Mem
=====

> 
> 
> 4. Was valgrind essentially the only process running?
> 
> JK – Definitely not.  The TR069 consists of a whole family of CCSP processes that communicate to each other via DBUS.  The TR069PA was however the only process running via valgrind
> 
> 5. How many threads?
> 
> JK – 4 threads per CCSP process, including the one running valgrind.

So there are many CCSP processes, plus other processes, running on a box with
512 megaBytes of RAM and no swap space.  Remember that a process running valgrind
(memcheck) requires about 2 to 3 times the memory of a non-checked process.

You have exhausted the available RAM.  The "out of memory" string was a clue.

Reduce the number and size of simultaneous CCSP processes.  Reduce the number
and size non-CCSP processes.  Run valgrind (memcheck) only on the one CCSP
process that really interests you.  Do not use --trace-children=yes.  Instead,
make CcspTr069PaSsp into an executable "wrapper" shell script which identifies
the correct instance (perhaps by count of invocations), then runs valgrind
on a saved copy of the original CcspTr069PaSsp; else just runs the
saved copy without valgrind.

Re: [Valgrind-users] Valgrind Internal Error: Valgrind received a signal 11 (SIGSEGV) - exiting

[John K. <Joh...@be...>]

Hi John,

My comments inline.  See lines with JK.

John

From: John Reiser <jr...@bi...>
Sent: Thursday, January 30, 2020 4:29 PM
To: val...@li...
Subject: Re: [Valgrind-users] Valgrind Internal Error: Valgrind received a signal 11 (SIGSEGV) - exiting

> I am receiving a valgrind Internal error upon startup of a multi-threaded application.  It appears to be related to the option track_origins as I was not seeing the issue without the track_origins option.  I am using the following valgrind options:  --trace-children=yesand --track-origins=yes.

Please tell us the following essential information:
0. You claim "a multi-threaded application" yet valgrind says "Command: /bin/touch ...". Explain. [Is it implemented via busybox?]
JK - The application is a TR-69PA... which runs 4 threads interfacing to Dbus.  During startup, it does a "system" call that runs /bin/touch.  The vast bulk of the program is written in C.  It does run in an embedded Linux environment on a router... and busybox is used for a number of the normal linux commands such as ps, ls, etc.

1. Confirm that the machine architecture is 32-bit ARM. (The string "memcheck-arm-linux" appears in the output.)
JK - This is a Linux architecture 32-bit ARM.
We use the toolchain-arm_cortex-a7_gcc-4.8-linaro_uClibc-1.0.14_eabi.tar.xz.

2. What is the make and model of the machine? Is it a virtual machine, or real hardware?
JK - Real hardware.

3. How much physical RAM? How much swap space? (The string "out_of_memory" appears in the output.)
JK - [    0.000000] Memory: 495376K/507904K available (5078K kernel code, 420K rwdata, 1704K rodata, 208K init, 328K bss, 12528K reserved, 0K highmem)
Not sure how to get swap space.

4. Was valgrind essentially the only process running?
JK - Definitely not.  The TR069 consists of a whole family of CCSP processes that communicate to each other via DBUS.  The TR069PA was however the only process running via valgrind.

5. How many threads?
JK - 4 threads per CCSP process, including the one running valgrind.

6. Run without --trace-children=yes, then copy+paste here the HEAP SUMMARY and LEAK SUMMARY paragraphs.
JK - I will have to get back to you on this one.  Won't be until Monday.

7. What is the approximate allocation profile? A zillion little blocks, or a few very large blocks, etc?
JK - All sizes... some very small, and some very large.  Control structures are small ones, while some objects transferred across the DBUS are quite large, containing arrays of objects/parameters.  Note that the overall application is a router... it has a lot of other processes running.  I would be hard pressed to characterize overall usage of memory.

8. Which linux distribution and version?
JK - This is embedded Linux version 3.14.77.  Here is info displayed at boot time:
[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 3.14.77 (jknight@gotrocks) (gcc version 4.8.3 (OpenWrt/Linaro GCC 4.8-2014.04 r35193) ) #1 SMP PREEMPT Mon Dec 23 12:54:41 PST 2019
[    0.000000] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[    0.000000] Machine model: Qualcomm Technologies, Inc. IPQ40xx/AP-DK07.1-C1
[    0.000000] Memory policy: Data cache writealloc
[    0.000000] PERCPU: Embedded 8 pages/cpu @dfbc7000 s8448 r8192 d16128 u32768
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 125952
[    0.000000] Kernel command line: init=/sbin/init rootfstype=ubifs ubi.mtd=alt_rootfs root=ubi0:ubifs rootwait rw clk_ignore_unused
[    0.000000] PID hash table entries: 2048 (order: 1, 8192 bytes)
[    0.000000] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
[    0.000000] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
[    0.000000] Memory: 495376K/507904K available (5078K kernel code, 420K rwdata, 1704K rodata, 208K init, 328K bss, 12528K reserved, 0K highmem)

9. Run "readelf --segments the_executable" and copy+paste here the output.
JK -
jknight@gotrocks:~/projects/nodes_dev_tb_tr69/skyfall_v2_tr181/nfsroot/rootfs/usr/sbin/tr069$ readelf --segments CcspTr069PaSsp

Elf file type is EXEC (Executable file)
Entry point 0x19780
There are 7 program headers, starting at offset 52

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  EXIDX          0x0e0c38 0x000f0c38 0x000f0c38 0x012f8 0x012f8 R   0x4
  PHDR           0x000034 0x00010034 0x00010034 0x000e0 0x000e0 R E 0x4
  INTERP         0x000114 0x00010114 0x00010114 0x00014 0x00014 R   0x1
      [Requesting program interpreter: /lib/ld-uClibc.so.0]
  LOAD           0x000000 0x00010000 0x00010000 0xe1f34 0xe1f34 R E 0x10000
  LOAD           0x0e2000 0x00102000 0x00102000 0x01368 0x03ef0 RW  0x10000
  DYNAMIC        0x0e2008 0x00102008 0x00102008 0x00188 0x00188 RW  0x4
  GNU_STACK      0x000000 0x00000000 0x00000000 0x00000 0x00000 RW  0x10

Section to Segment mapping:
  Segment Sections...
   00     .ARM.exidx
   01
   02     .interp
   03     .interp .hash .dynsym .dynstr .gnu.version .gnu.version_r .rel.dyn .rel.plt .init .plt .text .fini .rodata .ARM.extab .ARM.exidx .eh_frame
   04     .init_array .fini_array .dynamic .got .data .bss
   05     .dynamic
   06

10. When the internal error happens (or shortly before), what does "ps -l" say about the process?
JK - This is somewhat difficult to get as the error occurs as the system auto-boots and I am generally not even logged into the console yet.  I will try to get this probably on Monday and get back to you.

I hope this helps.  I will get back to you on Monday for the two items I could not answer today.

John

_______________________________________________
Valgrind-users mailing list
Val...@li...<mailto:Val...@li...>
https://lists.sourceforge.net/lists/listinfo/valgrind-users<https://lists.sourceforge.net/lists/listinfo/valgrind-users>
__________________________________________________________________ Confidential This e-mail and any files transmitted with it are the property of Belkin International, Inc. and/or its affiliates, are confidential, and are intended solely for the use of the individual or entity to whom this e-mail is addressed. If you are not one of the named recipients or otherwise have reason to believe that you have received this e-mail in error, please notify the sender and delete this message immediately from your computer. Any other use, retention, dissemination, forwarding, printing or copying of this e-mail is strictly prohibited. Pour la version fran?aise: http://www.belkin.com/email-notice/French.html F?r die deutsche ?bersetzung: http://www.belkin.com/email-notice/German.html __________________________________________________________________

Re: [Valgrind-users] Valgrind Internal Error: Valgrind received a signal 11 (SIGSEGV) - exiting

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

> I am receiving a valgrind Internal error upon startup of a multi-threaded application.  It appears to be related to the option track_origins as I was not seeing the issue without the track_origins option.  I am using the following valgrind options:  --trace-children=yesand --track-origins=yes.

Please tell us the following essential information:
0. You claim "a multi-threaded application" yet valgrind says "Command: /bin/touch ...".  Explain.  [Is it implemented via busybox?]
1. Confirm that the machine architecture is 32-bit ARM.  (The string "memcheck-arm-linux" appears in the output.)
2. What is the make and model of the machine?  Is it a virtual machine, or real hardware?
3. How much physical RAM?  How much swap space?  (The string "out_of_memory" appears in the output.)
4. Was valgrind essentially the only process running?
5. How many threads?
6. Run without --trace-children=yes, then copy+paste here the HEAP SUMMARY and LEAK SUMMARY paragraphs.
7. What is the approximate allocation profile?  A zillion little blocks, or a few very large blocks, etc?
8. Which linux distribution and version?
9. Run "readelf --segments the_executable" and copy+paste here the output.
10. When the internal error happens (or shortly before), what does "ps -l" say about the process?

[Valgrind-users] Valgrind Internal Error: Valgrind received a signal 11 (SIGSEGV) - exiting

[John K. <Joh...@be...>]

Hi,

I am receiving a valgrind Internal error upon startup of a multi-threaded application.  It appears to be related to the option track_origins as I was not seeing the issue without the track_origins option.  I am using the following valgrind options:  --trace-children=yes and --track-origins=yes.  If you have any ideas on how I can workaround this issue or fix it, I would appreciate it.  According to valgrind, the 'impossible' happened.

See below for the valgrind output associated with this error.

Thanks,

John Knight
Joh...@be...


Here is the valgrind output showing the internal error:
==24393== Memcheck, a memory error detector
==24393== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==24393== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==24393== Command: /bin/touch /var/tmp/tr069paready
==24393==
--24393:0: aspacem <<< SHOW_SEGMENTS: out_of_memory (36 segments)
--24393:0: aspacem 4 segment names in 4 slots
--24393:0: aspacem freelist is empty
--24393:0: aspacem (0,4,5) /lib/valgrind/memcheck-arm-linux
--24393:0: aspacem (1,41,3) /bin/busybox
--24393:0: aspacem (2,58,3) /lib/ld-uClibc-1.0.14.so
--24393:0: aspacem (3,87,1) /tmp/vgdb-pipe-shared-mem-vgdb-24393-by-root-on-???
--24393:0: aspacem   0: RSVN 0000000000-000000ffff   65536 ----- SmFixed
--24393:0: aspacem   1: file 0000010000-00000a5fff  614400 r-x-- d=0x00b i=2042    o=0       (1,41)
--24393:0: aspacem   2: RSVN 00000a6000-00000b5fff   65536 ----- SmFixed
--24393:0: aspacem   3: file 00000b6000-00000b6fff    4096 rw--- d=0x00b i=2042    o=614400  (1,41)
--24393:0: aspacem   4: anon 00000b7000-00000b7fff    4096 rw---
--24393:0: aspacem   5: RSVN 00000b8000-0003ffffff     63m ----- SmFixed
--24393:0: aspacem   6: file 0004000000-0004005fff   24576 r-xT- d=0x00b i=942     o=0       (2,58)
--24393:0: aspacem   7:      0004006000-0004015fff   65536
--24393:0: aspacem   8: file 0004016000-0004017fff    8192 rw--- d=0x00b i=942     o=24576   (2,58)
--24393:0: aspacem   9: anon 0004018000-0004018fff    4096 rwx--
--24393:0: aspacem  10: RSVN 0004019000-0004817fff 8384512 ----- SmLower
--24393:0: aspacem  11:      0004818000-0057ffffff   1335m
--24393:0: aspacem  12: FILE 0058000000-005809afff  634880 r-x-- d=0x00b i=1150    o=0       (0,4)
--24393:0: aspacem  13: file 005809b000-005809cfff    8192 r-x-- d=0x00b i=1150    o=634880  (0,4)
--24393:0: aspacem  14: FILE 005809d000-00581bbfff 1175552 r-x-- d=0x00b i=1150    o=643072  (0,4)
--24393:0: aspacem  15:      00581bc000-00581cafff   61440
--24393:0: aspacem  16: FILE 00581cb000-00581ccfff    8192 rw--- d=0x00b i=1150    o=1814528 (0,4)
--24393:0: aspacem  17: ANON 00581cd000-0058b38fff 9879552 rw---
--24393:0: aspacem  18:      0058b39000-00617a8fff    140m
--24393:0: aspacem  19: RSVN 00617a9000-00617a9fff    4096 ----- SmFixed
--24393:0: aspacem  20: ANON 00617aa000-0067950fff     97m rwx--
--24393:0: aspacem  21: ANON 0067951000-0067952fff    8192 -----
--24393:0: aspacem  22: ANON 0067953000-0067a52fff 1048576 rwx--
--24393:0: aspacem  23: ANON 0067a53000-0067a54fff    8192 -----
--24393:0: aspacem  24:      0067a55000-0067a57fff   12288
--24393:0: aspacem  25: FILE 0067a58000-0067a58fff    4096 rw--- d=0x00e i=69865   o=0       (3,87)
--24393:0: aspacem  26:      0067a59000-00b6f0efff   1268m
--24393:0: aspacem  27: ANON 00b6f0f000-00b6f0ffff    4096 r-x--
--24393:0: aspacem  28:      00b6f10000-00bd752fff    104m
--24393:0: aspacem  29: RSVN 00bd753000-00bdf51fff 8384512 ----- SmUpper
--24393:0: aspacem  30: anon 00bdf52000-00bdf52fff    4096 rw---
--24393:0: aspacem  31:      00bdf53000-00bef31fff     15m
--24393:0: aspacem  32: ANON 00bef32000-00bef52fff  135168 rw---
--24393:0: aspacem  33: RSVN 00bef53000-00fffeffff   1040m ----- SmFixed
--24393:0: aspacem  34: anon 00ffff0000-00ffff0fff    4096 r-x--
--24393:0: aspacem  35: RSVN 00ffff1000-00ffffffff   61440 ----- SmFixed
--24393:0: aspacem >>>
--24393-- core    :     8,388,608/    8,388,608 max/curr mmap'd, 0/0 unsplit/split sb unmmap'd,      2,915,072/    2,909,656 max/curr,         913/   2957424 totalloc-blocks/bytes,         908 searches 4 rzB
--24393-- dinfo   :     1,048,576/    1,048,576 max/curr mmap'd, 0/0 unsplit/split sb unmmap'd,        378,840/      104,992 max/curr,        1020/    592440 totalloc-blocks/bytes,        1026 searches 4 rzB
--24393-- client  :             0/            0 max/curr mmap'd, 0/0 unsplit/split sb unmmap'd,              0/            0 max/curr,           0/         0 totalloc-blocks/bytes,           0 searches 20 rzB
--24393-- demangle:        65,536/       65,536 max/curr mmap'd, 0/0 unsplit/split sb unmmap'd,            120/           88 max/curr,           8/       200 totalloc-blocks/bytes,           7 searches 4 rzB
--24393-- ttaux   :             0/            0 max/curr mmap'd, 0/0 unsplit/split sb unmmap'd,              0/            0 max/curr,           0/         0 totalloc-blocks/bytes,           0 searches 4 rzB
--24393-- translate:            fast new/die SP updates identified: 0 (0.0%)/0 (0.0%)
--24393-- translate:   generic_known new/die SP updates identified: 2 (100.0%)/0 (0.0%)
--24393-- translate: generic_unknown SP updates identified: 0 (0.0%)
--24393-- translate: PX: SPonly 0,  UnwRegs 1,  AllRegs 0,  AllRegsAllInsns 0
--24393--     tt/tc: 2 tt lookups requiring 0 probes
--24393--     tt/tc: 0 fast-cache updates, 1 flushes
--24393--  transtab: new        1 (68 -> 1,204; ratio 17.7) [0 scs] avg tce size 1204
--24393--  transtab: dumped     0 (0 -> ??) (sectors recycled 0)
--24393--  transtab: discarded  0 (0 -> ??)
--24393-- scheduler: 0 event checks.
--24393-- scheduler: 0 indir transfers, 0 misses (1 in 0) ..
--24393-- scheduler: .. of which: 0 hit0, 0 hit1, 0 hit2, 0 hit3, 0 missed
--24393-- scheduler: 0/1 major/minor sched events.
--24393--    sanity: 0 cheap, 0 expensive checks.
--24393--    exectx: 769 lists, 4 contexts (avg 0.01 per list) (avg 1.00 IP per context)
--24393--    exectx: 5 searches, 1 full compares (200 per 1000)
--24393--    exectx: 0 cmp2, 0 cmp4, 0 cmpAll
--24393--  errormgr: 0 supplist searches, 0 comparisons during search
--24393--  errormgr: 0 errlist searches, 0 comparisons during search
--24393--  memcheck: freelist: vol 0 length 0
--24393--  memcheck: sanity checks: 0 cheap, 1 expensive
--24393--  memcheck: auxmaps: 0 auxmap entries (0k, 0M) in use
--24393--  memcheck: auxmaps_L1: 0 searches, 0 cmps, ratio 0:10
--24393--  memcheck: auxmaps_L2: 0 searches, 0 nodes
--24393--  memcheck: SMs: n_issued      = 7 (112k, 0M)
--24393--  memcheck: SMs: n_deissued    = 0 (0k, 0M)
--24393--  memcheck: SMs: max_noaccess  = 65535 (1048560k, 1023M)
--24393--  memcheck: SMs: max_undefined = 0 (0k, 0M)
--24393--  memcheck: SMs: max_defined   = 9 (144k, 0M)
--24393--  memcheck: SMs: max_non_DSM   = 7 (112k, 0M)
--24393--  memcheck: max sec V bit nodes:    0 (0k, 0M)
--24393--  memcheck: set_sec_vbits8 calls: 0 (new: 0, updates: 0)
--24393--  memcheck: max shadow mem size:   416k, 0M
--24393--  ocacheL1:      171,981 refs         21,120 misses (0 lossage)
--24393--  ocacheL1:      150,861 at 0              0 at 1
--24393--  ocacheL1:            0 at 2+        21,120 move-fwds
--24393--  ocacheL1:   92,274,688 sizeB    67,108,864 useful
--24393--  ocacheL2:       21,120 refs         21,120 misses
--24393--  ocacheL2:            0 max nodes         0 curr nodes
--24393--  niacache:            0 refs              0 misses

host stacktrace:
==24393==    at 0x5803684C: ??? (in /lib/valgrind/memcheck-arm-linux)

sched status:
  running_tid=1
--24393-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - exiting
--24393-- si_code=1;  Faulting address: 0xA0;  sp: 0x67a529a0

valgrind: the 'impossible' happened:
   Killed by fatal signal

host stacktrace:
==24393==    at 0x58080344: ??? (in /lib/valgrind/memcheck-arm-linux)

sched status:
  running_tid=1
Segmentation fault
/bin/busybox: can't resolve symbol '__libc_freeres'

Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10

__________________________________________________________________ Confidential This e-mail and any files transmitted with it are the property of Belkin International, Inc. and/or its affiliates, are confidential, and are intended solely for the use of the individual or entity to whom this e-mail is addressed. If you are not one of the named recipients or otherwise have reason to believe that you have received this e-mail in error, please notify the sender and delete this message immediately from your computer. Any other use, retention, dissemination, forwarding, printing or copying of this e-mail is strictly prohibited. Pour la version fran?aise: http://www.belkin.com/email-notice/French.html F?r die deutsche ?bersetzung: http://www.belkin.com/email-notice/German.html __________________________________________________________________

Re: [Valgrind-users] Don't Instrument Wrapped Functions

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

On 1/25/20 5:28 PM, Ausitn Gadient wrote:
> Hello!
> 
> Is there a clean way to prevent Valgrind from adding instrumentation to wrapped functions? For example, if I have a wrapper for the libc function “read()”, I do not want to instrument “read()’s” code.

Which tool(s) do you mean?

valgrind is an "umbrella" program which runs several tools
including memcheck (the default tool), helgrind, cachegrind,
drd, lackey, massif, and a few experimental tools such as
exp-bbv and others.  What you are asking depends on the tool.
In general, the answer is "No", but there may be exceptions
depending on the tool.

By its very nature, memcheck requires instrumenting
EVERY SINGLE INSTRUCTION, and this is IMPOSSIBLE to change.

[Valgrind-users] Don't Instrument Wrapped Functions

[Ausitn G. <aga...@aa...>]

Hello!

Is there a clean way to prevent Valgrind from adding instrumentation to wrapped functions? For example, if I have a wrapper for the libc function “read()”, I do not want to instrument “read()’s” code.

Best Regards,
Austin Gadient

Re: [Valgrind-users] Invalid read well inside a block alloc'd

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

On 14/01/2020 19:15, Paul-Antoine Arras wrote:
> Le 14/01/2020 à 20:01, Tom Hughes a écrit :
>
>> Using it as a thread stack could also do it, though it looks a
>> bit small for that, or some sort or whacky stack pointer stunts
>> that lead to valgrind thinking it's part of the stack.
> 
> That's interesting. The block in question is not a thread stack but a 
> regular struct. However, at other places the code does play with 
> manually-allocated thread stacks, hence stack pointer switches that 
> might confuse Valgrind.
> 
> Can you see a way to confirm this conjecture? In other words, how can I 
> ensure this is a legitimate false positive?

I wouldn't expect it to go wrong with straightforward use where
malloced blocks are passed to clone as a thread stack, at least
if the correct size is passed, but if you start doing some sort of
coroutines or green thread type stuff and doing context switching
in user space then that's another story.

Basically when valgrind thinks the stack pointer is moving upwards
on return from a function it will mark the memory between the old
and new pointers as invalid, but the problem is that there's no way
to be sure from a write to the stack pointer if that is it being
increased/decreased or if it's a switch to a new stack so valgrind
has to employ heuristics and assume that big changes (for some value
of big) are switches and small changes are moving up/down the stack.

Tom

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

Re: [Valgrind-users] Invalid read well inside a block alloc'd

[Paul-Antoine A. <li...@de...>]

Le 14/01/2020 à 20:01, Tom Hughes a écrit :
> On 14/01/2020 18:55, Paul-Antoine Arras wrote:
>> Le 14/01/2020 à 19:51, Tom Hughes a écrit :
>>> On 14/01/2020 16:53, Paul-Antoine Arras wrote:
>>>
>> [...]
>>>> I struggle to understand how a read into a block of properly alloc'd 
>>>> memory can be invalid, given that the application doesn't use client 
>>>> requests.
>> [...]
>>>> How can a block of dynamically-allocated memory be marked 
>>>> unaddressable without having been freed?
>>>
>>> By using the VALGRIND_MAKE_MEM_NOACCESS macro.
>>>
>>
>> Sure, but as I mentioned in my message, the application code does not 
>> use client requests.
> 
> Using it as a thread stack could also do it, though it looks a
> bit small for that, or some sort or whacky stack pointer stunts
> that lead to valgrind thinking it's part of the stack.
> 

That's interesting. The block in question is not a thread stack but a 
regular struct. However, at other places the code does play with 
manually-allocated thread stacks, hence stack pointer switches that 
might confuse Valgrind.

Can you see a way to confirm this conjecture? In other words, how can I 
ensure this is a legitimate false positive?

Many thanks,
-- 
Paul-Antoine Arras

Re: [Valgrind-users] Invalid read well inside a block alloc'd

[Paul-Antoine A. <li...@de...>]

Le 14/01/2020 à 19:51, Tom Hughes a écrit :
> On 14/01/2020 16:53, Paul-Antoine Arras wrote:
> 
[...]
>> I struggle to understand how a read into a block of properly alloc'd 
>> memory can be invalid, given that the application doesn't use client 
>> requests.
[...]
>> How can a block of dynamically-allocated memory be marked 
>> unaddressable without having been freed?
> 
> By using the VALGRIND_MAKE_MEM_NOACCESS macro.
> 

Sure, but as I mentioned in my message, the application code does not 
use client requests.

Re: [Valgrind-users] Invalid read well inside a block alloc'd

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

On 14/01/2020 18:55, Paul-Antoine Arras wrote:
> Le 14/01/2020 à 19:51, Tom Hughes a écrit :
>> On 14/01/2020 16:53, Paul-Antoine Arras wrote:
>>
> [...]
>>> I struggle to understand how a read into a block of properly alloc'd 
>>> memory can be invalid, given that the application doesn't use client 
>>> requests.
> [...]
>>> How can a block of dynamically-allocated memory be marked 
>>> unaddressable without having been freed?
>>
>> By using the VALGRIND_MAKE_MEM_NOACCESS macro.
>>
> 
> Sure, but as I mentioned in my message, the application code does not 
> use client requests.

Using it as a thread stack could also do it, though it looks a
bit small for that, or some sort or whacky stack pointer stunts
that lead to valgrind thinking it's part of the stack.

Tom

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

Re: [Valgrind-users] Invalid read well inside a block alloc'd

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

On 14/01/2020 16:53, Paul-Antoine Arras wrote:

> I'm stumbling upon a weird message from Valgrind when run on my 
> application as follows:
> 
> $ valgrind --vgdb=yes --vgdb-error=0 --undef-value-errors=no $my_app
> 
> So Valgrind reports:
> 
> ==1644== Thread 9:
> ==1644== Invalid read of size 8
> ==1644==    at 0x4A39B40: PR_int__give_lang_env_for_slave (PR__int.c:348)
> ==1644==  Address 0x12d152c8 is 24 bytes inside a block of size 104 alloc'd
> ==1644==    at 0x483577F: malloc (vg_replace_malloc.c:309)
> ==1644==    by 0x4A3C4B4: [...]
> 
> I struggle to understand how a read into a block of properly alloc'd 
> memory can be invalid, given that the application doesn't use client 
> requests.
> To be sure, I double-checked the status of the entire buffer under vgdb:
> 
> (gdb) mo xb 0x12d152b0 104
> [...]
> Address 0x12D152B0 len 104 has 104 bytes unaddressable
> 
> How can a block of dynamically-allocated memory be marked unaddressable 
> without having been freed?

By using the VALGRIND_MAKE_MEM_NOACCESS macro.

Tom

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

[Valgrind-users] Invalid read well inside a block alloc'd

[Paul-Antoine A. <li...@de...>]

Hi all,

I'm stumbling upon a weird message from Valgrind when run on my 
application as follows:

$ valgrind --vgdb=yes --vgdb-error=0 --undef-value-errors=no $my_app

So Valgrind reports:

==1644== Thread 9:
==1644== Invalid read of size 8
==1644==    at 0x4A39B40: PR_int__give_lang_env_for_slave (PR__int.c:348)
==1644==  Address 0x12d152c8 is 24 bytes inside a block of size 104 alloc'd
==1644==    at 0x483577F: malloc (vg_replace_malloc.c:309)
==1644==    by 0x4A3C4B4: [...]

I struggle to understand how a read into a block of properly alloc'd 
memory can be invalid, given that the application doesn't use client 
requests.
To be sure, I double-checked the status of the entire buffer under vgdb:

(gdb) mo xb 0x12d152b0 104
[...]
Address 0x12D152B0 len 104 has 104 bytes unaddressable

How can a block of dynamically-allocated memory be marked unaddressable 
without having been freed?

Thanks in advance for your help!
-- 
Paul-Antoine Arras

Re: [Valgrind-users] seemingly bogus error reports

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

On 14/09/2019 21:11, Fred Smith wrote:
> Hi all!
> 
> I'm new to this list, but have used Valgrind many times in the past.
> 
> Today I'm making a serious effort to clean up a non-trivial body of code, and have run into a number of error reports like this one:

Try again with the trunk now
(git clone git://sourceware.org/git/valgrind.git).  I just pushed a
bunch of changes in, aimed at reducing the false positive level on
optimised code, relating to transformations to do with C-level &&/||
expressions.

J