valgrind-users — General discussion list for Valgrind users

[Valgrind-users] Calling var_args functions from with Wrapper

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

Hello!

I am trying to call the function vsnprintf from within a wrapper for vnsprintf using the I_WRAP and CALL_FN macros provided by Valgrind.

However, all of the CALL_FN macros only take longs as parameters. vsnprintf takes a va_list struct as one of its parameters.

Is there a way to use call functions that take va_lists (or any sort of struct) as parameters from inside a wrapper?

Best Regards,
Austin Gadient

Re: [Valgrind-users] Calling arbitrary guest functions

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

My intent is to write a tool that waits for another process to write
client addresses to a pipe, and then execute the specified function
with a fixed number of arguments.  I'm unconcerned about whether the
specified function actually has the assumed arity or not, though.  I
tried the following, but it seems that the function is not called.
However, this is what I am wanting to do.
---------------------------------------------
static void SE_(start_client_code)(ThreadId tid, ULong blocks_dispatched) {
  if (!client_running && tid == client_thread_id) {
    VG_(umsg)
    ("Thread %u is starting executing at instruction 0x%lx with "
     "blocks_dispatched=%llu\n",
     tid, VG_(get_IP)(tid), blocks_dispatched);
    client_running = True;
    VG_(umsg)("Thread %u is about to call target function\n", tid);
    OrigFn fn;
    fn.nraddr = (Addr)0x401145; // Function address in client
    CALL_FN_v_v(fn);  // Assume no arguments are passed in
    VG_(umsg)("Thread %u returned\n", tid);
    client_running = False;
  }
}

static void SE_(pre_clo_init)(void) {
    ....
    VG_(track_start_client_code)(SE_(start_client_code));
}

VG_DETERMINE_INTERFACE_VERSION(SE_(pre_clo_init))
--------------------------------------
Reading the documentation, it seems that CALL_FN_v_v should be called
from the client code, but I want to use my tool with any binary.  I
also tried using the VG_(set_IP) function (admittedly against the
valgrind tool contract), but that seemingly didn't work either.  Any
other thoughts, or is this just something I cannot do with valgrind?

On Tue, Mar 3, 2020 at 11:01 AM Derrick McKee <der...@gm...> wrote:
>
> I am also interested in instrumenting the guest binary, as well as
> change which guest function I execute at run time.  So LD_PRELOAD
> won't help me here.
>
> On Tue, Mar 3, 2020 at 10:41 AM John Reiser <jr...@bi...> wrote:
> >
> > > 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.
> >
> > This can be done without valgrind by using LD_PRELOAD environment variable
> > and RTLD_NEXT (see "man dlsym"):
> >
> >      LD_PRELOAD=main_interceptor.so  ./my_app args...
> >
> > where main_interceptor.so is a shared library that has a function main()
> > and that can call the original main() by using dlsym(RTLD_NEXT, "main").
> >
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > Valgrind-users mailing list
> > Val...@li...
> > https://lists.sourceforge.net/lists/listinfo/valgrind-users
>
>
>
> --
> Derrick McKee
> Phone: (703) 957-9362
> Email: der...@gm...



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

Re: [Valgrind-users] Write new tool in C++?

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

Thanks for the response.  That's what I am seeing in my initial test,
as I am getting undefined reference errors to std::cout during
linking.

On Wed, Mar 4, 2020 at 10:16 AM Tom Hughes <to...@co...> wrote:
>
> On 04/03/2020 14:46, Derrick McKee wrote:
>
> > Is it possible to write a tool using C++ instead of just C?
>
> In theory, maybe, but the problem you're going to have is that
> you have no run time library support - no libstdc+++ and not even
> any libc. So there are probably various things that need run time
> support that just aren't going to work and you're not going to have
> any of the normal library data structures and things.
>
> Tom
>
> --
> Tom Hughes (to...@co...)
> http://compton.nu/



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

Re: [Valgrind-users] Write new tool in C++?

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

On 04/03/2020 14:46, Derrick McKee wrote:

> Is it possible to write a tool using C++ instead of just C?

In theory, maybe, but the problem you're going to have is that
you have no run time library support - no libstdc+++ and not even
any libc. So there are probably various things that need run time
support that just aren't going to work and you're not going to have
any of the normal library data structures and things.

Tom

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

[Valgrind-users] Write new tool in C++?

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

Hi,

Is it possible to write a tool using C++ instead of just C?

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

[Valgrind-users] obj:*/fun:* matching in suppression

[Deene D. <dd...@ma...>]

Hi,

I'm running some Valgrind test programs (using 3.15.0) that trigger all of the Memcheck errors and have noticed that a suppression file (I was accidently loading) was suppressing a bunch of the issues, but on the surface the match was 'obj:*' for 'fun:*' which is not what I expected.
e.g. without adding the suppression file I get the nice simple Definite Leak

==241898== 8 bytes in 1 blocks are definitely lost in loss record 1 of 2
==241898==    at 0x4C2BF0D: malloc (/valgrind/valgrind-3.15.0/src/valgrind-3.15.0/coregrind/m_replacemalloc/vg_replace_malloc.c:309)
==241898==    by 0x400884: LDL_2() (/src/test_valgrind/test_ldl.cpp:72)
==241898==    by 0x4008AE: main (/src/test_valgrind/test_ldl.cpp:80)
==241898==
{
   <insert_a_suppression_name_here>
   Memcheck:Leak
   match-leak-kinds: definite
   fun:malloc
   fun:_Z5LDL_2v
   fun:main
}

Adding in the suppression file the issue is suppressed:

--243931-- used_suppression:      1 <insert_a_suppression_name_here> /devel/valgrind_glnxa64.supp:17391 suppressed: 8 bytes in 1 blocks

e.g.
<insert_a_suppression_name_here>
    Memcheck:Leak
    match-leak-kinds:definite
    fun:malloc
    obj:*
    obj:*
    obj:*
}

After reading  '2.5. Suppressing errors' from the user manual I would assume using an 'obj:' or a 'fun:' implied there had to be a match of that type, and that any wildcard kicked in after the type (i.e. shared lib or function) was matched.
Is that not the case?

i.e. is the above suppression really the same as
{
<insert_a_suppression_name_here>
    Memcheck:Leak
    match-leak-kinds:definite
    fun:malloc
}

Thanks

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

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

Thanks.  Obviously, I should have tried that before posting my question, although I would not have known how to obtain the answer without seeing your answer below.

Not being familiar with the x86 asm language, I modified the foo.cpp program (explicitly assign y=0) and then g++ again, so I could compare the two asm lang outputs.  After that, it was fairly clear that the compiler is not initializing y.

Ben

-----Original Message-----
From: John Reiser <jr...@bi...> 
Sent: Monday, March 2, 2020 7:20 PM
To: val...@li...
Subject: Re: [Valgrind-users] detecting uninitialized values in debug builds

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 mailing list
Val...@li...
https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fvalgrind-users&amp;data=02%7C01%7Cben.white%40cohu.com%7C4af3d19203134610feef08d7bf220529%7Ceacc2a35149847488d1f03fb953672f8%7C0%7C0%7C637188025165390441&amp;sdata=CkROtsN2ADGpGORSPKlYSEqmibqd3VLSA0LfO8U2giU%3D&amp;reserved=0

Re: [Valgrind-users] Calling arbitrary guest functions

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

I am also interested in instrumenting the guest binary, as well as
change which guest function I execute at run time.  So LD_PRELOAD
won't help me here.

On Tue, Mar 3, 2020 at 10:41 AM John Reiser <jr...@bi...> wrote:
>
> > 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.
>
> This can be done without valgrind by using LD_PRELOAD environment variable
> and RTLD_NEXT (see "man dlsym"):
>
>      LD_PRELOAD=main_interceptor.so  ./my_app args...
>
> where main_interceptor.so is a shared library that has a function main()
> and that can call the original main() by using dlsym(RTLD_NEXT, "main").
>
>
>
>
>
>
>
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users



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

Re: [Valgrind-users] Calling arbitrary guest functions

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

> 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.

This can be done without valgrind by using LD_PRELOAD environment variable
and RTLD_NEXT (see "man dlsym"):

     LD_PRELOAD=main_interceptor.so  ./my_app args...

where main_interceptor.so is a shared library that has a function main()
and that can call the original main() by using dlsym(RTLD_NEXT, "main").

[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 __________________________________________________________________