valgrind-users — General discussion list for Valgrind users

[Valgrind-users] printing the values of arguments for strcpy(3), memmove(3), ...

[Matthias A. <gu...@un...>]

Hello,

This is with valgrind 3.14.0 compiled and used on SuSE Linux 12 and 15 x86_64.

I have had a hart time to nail down the reason for a lot(!) of such vg
messages:

==1272== Invalid read of size 8
==1272==    at 0x4C355BF: memmove (vg_replace_strmem.c:1270)
==1272==    by 0x64A50D7: zzstrncpy (zzstdc.C:143)
==1272==    by 0x67366DE: SqlCharToChar (ec_general.ec:165)
==1272==    by 0x675ED84: Para2Host (acq_update.h:59)
==1272==    by 0x675FCE7: SQLExistUpdateEntry (ec_acq_update.ec:200)
...
==1272==  Address 0x17d80148 is 24 bytes after a block of size 16 in arena "client"

The reason was at the end of debugging that we replaced in some central
place of the server a function call (due to vg messages about
overlapping args)

	strncpy(dst, src, n);

by

	memset(dst, 0, n);
	memmove(dst, src, n);

which is not fully equivalent because strncpy(3) will stop at the first
\0 byte in src, while memmove(3) will copy n bytes, regardles if they
are valid bytes in src. As this was in some low level function, it
generated a mass of the above vg messages.

To debug it, I ended up printing in hex the pointer src, the value of n
and the first n bytes of src which finally gave me a clue what was wrong:
the number n was some kind of a fixed maximal length for dst and regardless of
the provided bytes in src. Fixed by:

	memset(dst, 0, n);
	n = strlen(src);
	memmove(dst, src, n);

So far so good. What would have helped me is that vg could print in its
replacement functions for memmove(3) ... (vg_replace_strmem.c:1270)
the provided pointers and other args, and as well part of the src
buffer. For sure vg knows exactly these values to watch the illegal
memory access.

Any thoughts about this?

	matthias

-- 
Matthias Apitz, ✉ gu...@un..., http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
¡Con Cuba no te metas!  «»  Don't mess with Cuba!  «»  Leg Dich nicht mit Kuba an!
http://www.cubadebate.cu/noticias/2020/12/25/en-video-con-cuba-no-te-metas/

Re: [Valgrind-users] [valgrind]: mem leaks

[Kunal C. <atk...@gm...>]

Thanks for clarifications
++ if the binary is crashed or may be not crashed when it runs with
valgrind, but in both case valgrind is able to give the report. ?

On Mon, Jan 25, 2021 at 1:28 PM Paul Floyd <pj...@wa...> wrote:

>
>
> > On 24 Jan 2021, at 18:29, Kunal Chauhan <atk...@gm...>
> wrote:
> >
> > Hi paul,
> >
> > thanks for info,
> > 1.Like  in trailing mail you said process under completion  what do you
> mean exactly,
> > 2. Also for running a process under valgrind my binary should be strip
> or unstrip.?
> >
> > 3. Memcheck tool where it fits in context of valgrind .
>
>
> (Replying to the list)
>
> 1. A command like ‘pwd’. You run the command, it prints the working
> directory and then it exits. In this example when the pwd process
> completes, Valgrind can detect leaks.
> 2. Unstripped binaries with debug information are the best.
> 3. Valgrind includes several tools, memcheck being the best known of them,
> for detecting memory errors. There are also tools for profiling and thread
> hazard detection.
>
> A+
> Paul
>
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>


-- 
*Thanks with Regards!*

*Kunal Chauhan*
*Mob:09813614826*
*Mob:08860397903*

*E-mail:atk...@gm... <E-mail%3Aa...@gm...>*

Re: [Valgrind-users] [valgrind]: mem leaks

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

> On 24 Jan 2021, at 18:29, Kunal Chauhan <atk...@gm...> wrote:
> 
> Hi paul,
> 
> thanks for info,
> 1.Like  in trailing mail you said process under completion  what do you mean exactly, 
> 2. Also for running a process under valgrind my binary should be strip or unstrip.?
> 
> 3. Memcheck tool where it fits in context of valgrind .


(Replying to the list)

1. A command like ‘pwd’. You run the command, it prints the working directory and then it exits. In this example when the pwd process completes, Valgrind can detect leaks.
2. Unstripped binaries with debug information are the best.
3. Valgrind includes several tools, memcheck being the best known of them, for detecting memory errors. There are also tools for profiling and thread hazard detection.

A+
Paul

Re: [Valgrind-users] [valgrind]: mem leaks

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

On 1/22/21 9:31 PM, Kunal Chauhan wrote:
> Hi Team,
>
> As on my linux  board ,one of process showing some run time memory 
> increase as seen by pmap command.
>
> So how valgrind can be useful to search such mem leaks in big code.
>
> Or is there is way to attached valgrind and see where and which 
> instruction actually causing issue


Hi

You can't 'attach' Valgrind to a running process.

What you need to do is to run the process under Valgrind. If the process 
normally runs to completion, you can just run it under Valgrind (by 
default, the memcheck tool will be used, add --leak-check=full and 
possibly --show-reachable=yes).

If the process is running aas a daemon, then your best bet is to run it 
under Valgrind and then attach gdb to it and use monitor commands to 
check for leaks. That is documented on the Valgrind web page, here 
https://valgrind.org/docs/manual/manual-core-adv.html#manual-core-adv.gdbserver-commandhandling 
.


A+

Paul

[Valgrind-users] [valgrind]: mem leaks

[Kunal C. <atk...@gm...>]

Hi Team,

As on my linux  board ,one of process showing some run time memory increase
as seen by pmap command.

So how valgrind can be useful to search such mem leaks in big code.

Or is there is way to attached valgrind and see where and which instruction
actually causing issue

[Valgrind-users] [valgrind]: mem leak find

[Kunal C. <atk...@gm...>]

Hi Team,


As I am facing some issue , like it seems one my process on linux board is
increasing its size as seen by pmap commands.

So how valgrind can be useful to see this type of memleaks , and what
approach to follow up.

Re: [Valgrind-users] Please give me advises: How to use the snapshot parameter used in VALGRIND's massif in external applications like Python or ROS/ROS2

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

On 19/01/2021 17:52, Koki Nagahama wrote:
> Hi VALGRIND developers and users,
> I'm planning to modify a part of your product, VALGRIND,to integrate 
> it with a middleware for robots called ROS.
>
> In order to do this, I'm considering two ways to implement the massif 
> component of VALGRIND: (1) to implement it in C and call it in another 
> program as a Python library, and (2) to convert it into a ROS/ROS2 
> component (nodes) in C++.
>
> The reason for these implementations plan is that I want to retrieve 
> the values of heap_szB and stack_szB defined in the Snapshot structure 
> in ms_main.c of massif via VALGRIND and use them in a timely manner in 
> an external Python-based program.
> As far as I read the raw source code, the way to get the data is to 
> specify the last struct element of Snapshot* snapshot and extract it 
> (if I'm wrong, please let me know).However, I'm struggling with the 
> implementation of the part that passes to the external application.
>
> Please advise me on the implementation, including which method is more 
> feasible.

Hi

This doesn't seem feasible to me.

Massif (and all of the Valgrind tools) does not link with any library. 
This makes life much simpler because generally the guest application 
links with at least libc. If both guest and host link with the same libs 
then that would cause conflicts.

I think that the best way to do something like this is to use a pipe to 
communicate with an external application, similar to the way that tools 
use pipes for communication between gdb and the embedded gdbserver.


A+

Paul

[Valgrind-users] Please give me advises: How to use the snapshot parameter used in VALGRIND's massif in external applications like Python or ROS/ROS2

[Koki N. <her...@gm...>]

Hi VALGRIND developers and users,
I'm planning to modify a part of your product, VALGRIND,to integrate it
with a middleware for robots called ROS.

In order to do this, I'm considering two ways to implement the massif
component of VALGRIND: (1) to implement it in C and call it in another
program as a Python library, and (2) to convert it into a ROS/ROS2
component (nodes) in C++.

The reason for these implementations plan is that I want to retrieve the
values of heap_szB and stack_szB defined in the Snapshot structure in
ms_main.c of massif via VALGRIND and use them in a timely manner in an
external Python-based program.
As far as I read the raw source code, the way to get the data is to specify
the last struct element of Snapshot* snapshot and extract it (if I'm wrong,
please let me know).However, I'm struggling with the implementation of the
part that passes to the external application.

Please advise me on the implementation, including which method is more
feasible.
As for (1), I tried to build the source code to see if I could include
Python.h correctly, and it failed, so I'll keep a log of this.

========
<< Environment >>
$ uname -a
Linux [HOSTNAME] 5.4.0-1026-raspi #29-Ubuntu SMP PREEMPT Mon Dec 14
17:01:16 UTC 2020 aarch64 aarch64 aarch64 GNU/Linux

$ cat /etc/lsb-release*
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=20.04
DISTRIB_CODENAME=focal
DISTRIB_DESCRIPTION="Ubuntu 20.04.1 LTS"

<< What I did during the build and the log >>
I made the following changes to the DEFAULTS_INCLEDES variable in the
massif/Makefile.

DEFAULT_INCLUDES = -I. -I$(top_builddir) -I/usr/include/python3.8


I also inserted the following two lines in the first line of
massif/ms_main.c. The following two lines are inserted in the first line of
massif/ms_main.c. No functions using PyObject* are implemented in the file.

#define PY_SSIZE_T_CLEAN
#include <Python.h>.

When I ran make and make install, I got the following error message.

Making all in massif
make[2]: Entering directory '/home/[username]/[work
directory]/valgrind-3.16.1/massif'
Making all in .
make[3]: Entering directory '/home/[username]/[work
directory]/valgrind-3.16.1/massif'
gcc -DHAVE_CONFIG_H -I. -I... -I/usr/include/python3.8 -I.. -I.. /include
-I.. /include -I. /VEX/pub -I. /VEX/pub -DVGA_arm64=1 -DVGO_linux=1
-DVGP_arm64_linux=1 -DVGPV_arm64_linux_vanilla=1 -O2 -g -Wall
-Wmissing-prototypes -Wshadow -Wpointer- arith -Wstrict-prototypes
-Wmissing-declarations -Wcast-align -Wcast-qual -Wwrite-strings
-Wempty-body -Wformat -Wformat-signedness Wformat-security
-Wignored-qualifiers -Wmissing-parameter-type -Wlogical-op
-Wimplicit-fallthrough=2 -Wold-style-declaration -finline- functions
-fno-stack-protector -fno-strict-aliasing -fno-builtin -MT
massif_arm64_linux-ms_main.o -MD -MP -MF .deps/massif_arm64_linux-ms_ Tpo
-c -o massif_arm64_linux-ms_main.o `test -f 'ms_main.c' || echo '.
/'`ms_main.c
In file included from /usr/include/aarch64-linux-gnu/sys/stat.h:101,
                 From /usr/include/python3.8/pyport.h:245,
                 from /usr/include/python3.8/Python.h:63,
                 from ms_main.c:6:
... /include/vki/vki-arm64-linux.h:316:25: error: expected ':', ',', '. ;',
'}' or '__attribute__' before '. token
  316 | long st_atime;
      | ^~~~~~~~
make[3]: *** [Makefile:1087: massif_arm64_linux-ms_main.o] Error 1
make[3]: Leaving directory '/home/[username]/[my work
directory]/valgrind-3.16.1/massif'
make[2]: *** [Makefile:1121: all-recursive] Error 1
make[2]: Leaving directory '/home/[username]/[my work
directory]/valgrind-3.16.1/massif'
make[1]: *** [Makefile:849: all-recursive] Error 1
make[1]: Leaving directory '/home/[username]/[my work
directory]/valgrind-3.16.1'
Make: *** [Makefile:718: all] Error 2

Best regards,
Koki

Re: [Valgrind-users] I need your help because Building VALGRIND is Failing on Ubuntu 20.xx

[Koki N. <her...@gm...>]

Dear Geoff Alexander and Eliot Moss,

Thank you for checking the mailing list and answering my questions.

I added the "--without-mpicc" option to the configure process, and the
build succeeded!
I was not aware that this had been reported in the past.
I didn't check the MPI downgrade, but I'll try it when I can and add it to
this mailing list.

Thanks,
Koki

Re: [Valgrind-users] I need your help because Building VALGRIND is Failing on Ubuntu 20.xx

[Eliot M. <mo...@cs...>]

On 1/14/2021 9:35 AM, Geoff Alexander wrote:
> I wonder if this is related to Valgrind bug 439542 Cannot compile valgrind on Ubuntu 20.04 docker 
> due to failed compilation libmpiwrap.c (https://bugs.kde.org/show_bug.cgi?id=420518).
> 
> Geoff Alexander, Ph.D.
> Software Engineer, Corporate Tools Development
> IBM Corporation
> Charlotte, NC

It seems to be exactly the same issue.

EM

> Koki Nagahama <her...@gm...> wrote on 01/14/2021 02:59:18 AM:
> 
>  > From: Koki Nagahama <her...@gm...>
>  > To: val...@li...
>  > Date: 01/14/2021 03:00 AM
>  > Subject: [EXTERNAL] [Valgrind-users] I need your help because
>  > Building VALGRIND is Failing on Ubuntu 20.xx
>  >
>  > Hi VALGRIND developers, I'm planning to modify a part of your...
>  >
>  > This Message Is From an External Sender
>  >
>  > This message came from outside your organization.
>  >
>  > Hi VALGRIND developers,
>  >
>  > I'm planning to modify a part of your product, VALGRIND,to integrate
>  > it with a middleware for robots called ROS.However, I'm having
>  > trouble building from the Valgrind source code on Ubuntu 20.xx.
>  >
>  > The hardware is a Raspberry Pi 4B+ (aarch64) and the OS is Ubuntu
>  > Mate 20.04 (focal) 64-bit version,so I think ARMv8 is supported, but
>  > I can't seem to get it to work.The source code is from 3.16.1, which
>  > came out this year.
>  >
>  > From reading the errors and warnings, maybe there is an obvious
>  > reason in the source code,but maybe there are other build stoppers
>  > after the one I failed to build,so can you please help me to
>  > investigate the cause and help me to build successfully?
>  >
>  > By the way, Ubuntu 18.04 LTS succeeded in building as usual. It may
>  > be that the package required for make is not included in Ubuntu
>  > 20.xx or is different, but I have no idea.
>  >
>  > I've uploaded the build log of my environment to Google Drive, and
>  > the URL is listed below.Some of the logs are omitted because I ran
>  > the command one more time after one failed build,but I hope it helps
>  > you understand the situation.
>  >
>  > Build log:https://drive.google.com/file/d/1-pxnXa-
>  > GgEYak8k_ITpj504LlBMYbR9H/view?usp=sharing
>  >
>  > Best Regards,
>  > Koki_______________________________________________
>  > Valgrind-users mailing list
>  > Val...@li...
>  > INVALID URI REMOVED
>  > u=https-3A__lists.sourceforge.net_lists_listinfo_valgrind-2Dusers&d=DwICAg&c=jf_iaSHvJObTbx-
>  > siA1ZOg&r=KJ6EIWC2rKHl4x6BfwQuSA&m=KVpnlHdoQ-
>  > kGIfGrpIAYViKHIKfID3QJSLNoDAds8T0&s=PozwhcjX-
>  > _fdLcjkvHCWdXX8fBvwKTYXFJDMpjuDjyQ&e=
> 
> 
> 
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
> 

Re: [Valgrind-users] I need your help because Building VALGRIND is Failing on Ubuntu 20.xx

[Geoff A. <gd...@us...>]

Oops, I meant related to Bug 420518 -- the link I gave is correct.

Geoff Alexander, Ph.D.
Software Engineer, Corporate Tools Development
IBM Corporation
Charlotte, NC


"Geoff Alexander" <gd...@us...> wrote on 01/14/2021 09:35:50 AM:

> From: "Geoff Alexander" <gd...@us...>
> To: Koki Nagahama <her...@gm...>
> Cc: val...@li...
> Date: 01/14/2021 09:36 AM
> Subject: [EXTERNAL] Re: [Valgrind-users] I need your help because
> Building VALGRIND is Failing on Ubuntu 20.xx
>
> I wonder if this is related to Valgrind bug 439542 Cannot compile
> valgrind on Ubuntu 20.04 docker due to failed compilation libmpiwrap.c (
> https://bugs.kde.org/show_bug.cgi?id=420518).
>
> Geoff Alexander, Ph.D.
> Software Engineer, Corporate Tools Development
> IBM Corporation
> Charlotte, NC
>
>

Re: [Valgrind-users] I need your help because Building VALGRIND is Failing on Ubuntu 20.xx

[Geoff A. <gd...@us...>]

I wonder if this is related to Valgrind bug 439542 Cannot compile valgrind
on Ubuntu 20.04 docker due to failed compilation libmpiwrap.c (
https://bugs.kde.org/show_bug.cgi?id=420518).

Geoff Alexander, Ph.D.
Software Engineer, Corporate Tools Development
IBM Corporation
Charlotte, NC


Koki Nagahama <her...@gm...> wrote on 01/14/2021 02:59:18 AM:

> From: Koki Nagahama <her...@gm...>
> To: val...@li...
> Date: 01/14/2021 03:00 AM
> Subject: [EXTERNAL] [Valgrind-users] I need your help because
> Building VALGRIND is Failing on Ubuntu 20.xx
>
> Hi VALGRIND developers, I'm planning to modify a part of your...
>
> This Message Is From an External Sender
>
> This message came from outside your organization.
>
> Hi VALGRIND developers,
>
> I'm planning to modify a part of your product, VALGRIND,to integrate
> it with a middleware for robots called ROS.However, I'm having
> trouble building from the Valgrind source code on Ubuntu 20.xx.
>
> The hardware is a Raspberry Pi 4B+ (aarch64) and the OS is Ubuntu
> Mate 20.04 (focal) 64-bit version,so I think ARMv8 is supported, but
> I can't seem to get it to work.The source code is from 3.16.1, which
> came out this year.
>
> From reading the errors and warnings, maybe there is an obvious
> reason in the source code,but maybe there are other build stoppers
> after the one I failed to build,so can you please help me to
> investigate the cause and help me to build successfully?
>
> By the way, Ubuntu 18.04 LTS succeeded in building as usual. It may
> be that the package required for make is not included in Ubuntu
> 20.xx or is different, but I have no idea.
>
> I've uploaded the build log of my environment to Google Drive, and
> the URL is listed below.Some of the logs are omitted because I ran
> the command one more time after one failed build,but I hope it helps
> you understand the situation.
>
> Build log:https://drive.google.com/file/d/1-pxnXa-
> GgEYak8k_ITpj504LlBMYbR9H/view?usp=sharing
>
> Best Regards,
> Koki_______________________________________________
> Valgrind-users mailing list
> Val...@li...
> INVALID URI REMOVED
>
u=https-3A__lists.sourceforge.net_lists_listinfo_valgrind-2Dusers&d=DwICAg&c=jf_iaSHvJObTbx-

> siA1ZOg&r=KJ6EIWC2rKHl4x6BfwQuSA&m=KVpnlHdoQ-
> kGIfGrpIAYViKHIKfID3QJSLNoDAds8T0&s=PozwhcjX-
> _fdLcjkvHCWdXX8fBvwKTYXFJDMpjuDjyQ&e=

Re: [Valgrind-users] I need your help because Building VALGRIND is Failing on Ubuntu 20.xx

[Eliot M. <mo...@cs...>]

On 1/14/2021 2:59 AM, Koki Nagahama wrote:
> Hi VALGRIND developers,
> 
> I'm planning to modify a part of your product, VALGRIND,to integrate it with a middleware for robots 
> called ROS.However, I'm having trouble building from the Valgrind source code on Ubuntu 20.xx.
> 
> The hardware is a Raspberry Pi 4B+ (aarch64) and the OS is Ubuntu Mate 20.04 (focal) 64-bit 
> version,so I think ARMv8 is supported, but I can't seem to get it to work.The source code is from 
> 3.16.1, which came out this year.
> 
>  From reading the errors and warnings, maybe there is an obvious reason in the source code,but maybe 
> there are other build stoppers after the one I failed to build,so can you please help me to 
> investigate the cause and help me to build successfully?
> 
> By the way, Ubuntu 18.04 LTS succeeded in building as usual. It may be that the package required for 
> make is not included in Ubuntu 20.xx or is different, but I have no idea.
> 
> I've uploaded the build log of my environment to Google Drive, and the URL is listed below.Some of 
> the logs are omitted because I ran the command one more time after one failed build,but I hope it 
> helps you understand the situation.
> 
> Build log:https://drive.google.com/file/d/1-pxnXa-GgEYak8k_ITpj504LlBMYbR9H/view?usp=sharing

It is failing in the stage where it is building MPI support.  Your setup seems to have mpi installed 
(mpicc and mpi.h are found), but apparently not a version of mpi.h that works with valgrind.  You 
might try configuring --without-mpicc or else revert the MPI version to 2.something instead of 
3.something.  (The latter is a little bit of a guess, but because configure --help mentions MPI2.)

HTH - Eliot Moss

[Valgrind-users] I need your help because Building VALGRIND is Failing on Ubuntu 20.xx

[Koki N. <her...@gm...>]

Hi VALGRIND developers,

I'm planning to modify a part of your product, VALGRIND,to integrate it
with a middleware for robots called ROS.However, I'm having trouble
building from the Valgrind source code on Ubuntu 20.xx.

The hardware is a Raspberry Pi 4B+ (aarch64) and the OS is Ubuntu Mate
20.04 (focal) 64-bit version,so I think ARMv8 is supported, but I can't
seem to get it to work.The source code is from 3.16.1, which came out this
year.

>From reading the errors and warnings, maybe there is an obvious reason in
the source code,but maybe there are other build stoppers after the one I
failed to build,so can you please help me to investigate the cause and help
me to build successfully?

By the way, Ubuntu 18.04 LTS succeeded in building as usual. It may be that
the package required for make is not included in Ubuntu 20.xx or is
different, but I have no idea.

I've uploaded the build log of my environment to Google Drive, and the URL
is listed below.Some of the logs are omitted because I ran the command one
more time after one failed build,but I hope it helps you understand the
situation.

Build log:
https://drive.google.com/file/d/1-pxnXa-GgEYak8k_ITpj504LlBMYbR9H/view?usp=sharing

Best Regards,
Koki

Re: [Valgrind-users] [Need Help] Valgrind on Cavium-Octeon-3

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

mihir amrelia wrote:
>> file /var/tmp/cavium/bin/valgrind
>> /var/tmp/cavium/bin/valgrind: ELF 64-bit MSB executable, MIPS, MIPS64 rel2 version 1 (SYSV), dynamically linked, interpreter /lib64-f, for GNU/Linux 2.6.32, not stripped
>>
>> How to fix this?

Tom Hughes via Valgrind-users wrote:
> No idea - that will be down to your cross build toolchain.


Diagnose by something like:
     strace -f -o strace.out -e trace=execve -v -s 400 gcc hello.c
then search for "lib64-f" in strace.out.

For a native compile tool chain the relevant piece in strace.out is something like:
     execve("/usr/bin/ld", ["/usr/bin/ld", ...  "-dynamic-linker", "/lib64/ld-linux-x86-64.so.2", ...
which would be changed by something like
     gcc -Wl,-dynamic-linker,path_to_eventual_dynamic_linker ...

Re: [Valgrind-users] [Need Help] Valgrind on Cavium-Octeon-3

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

No idea - that will be down to your cross build toolchain.

Tom

On 10/01/2021 18:21, mihir amrelia wrote:
> Tom,
> 
> Thanks a lot for your response.
> Yes, it doesn't look like the one I should be expecting..
> 
> file /var/tmp/cavium/bin/valgrind
> /var/tmp/cavium/bin/valgrind: ELF 64-bit MSB executable, MIPS, MIPS64 
> rel2 version 1 (SYSV), dynamically linked, interpreter /lib64-f, for 
> GNU/Linux 2.6.32, not stripped
> 
> How to fix this?
> 
> -Mihir
> On Thursday, 7 January, 2021, 04:36:45 pm IST, Tom Hughes 
> <to...@co...> wrote:
> 
> 
> On 07/01/2021 10:54, mihir amrelia via Valgrind-users wrote:
> 
> 
>  > I am trying to get valgrind running on cavium octeon 3 processor.
>  >
>  >
>  > Couldn't find any specific build configs for this other than some hints
>  > on the valgrind wiki.
>  > *
>  > *
>  > *
>  > The steps executed to build valgrind for cavium were (on x86_64 host):
>  > *export CC=/opt/cavium-64bit/tools-3535/bin/mips64-octeon-linux-gnu-gcc
>  > export CXX=/opt/cavium-64bit/tools-3535/bin/mips64-octeon-linux-gnu-g++
>  > export PATH=$PATH:/opt/cavium-64bit/tools-3535/bin/
>  > ./configure --host=mips64-linux-gnu --target=mips64-octeon-linux
>  > --prefix=/home/mihira/workspace/mylab/valgrind/cavium
>  > --exec-prefix=/var/tmp/cavium --disable-tls
>  > make && make install
>  >
>  > *While trying to run it on target (copied the elfs to /var/tmp/cavium/
>  > dir on the target):*
>  > export VALGRIND_LIB=/var/tmp/cavium/lib/valgrind/
>  > export PATH=$PATH:/var/tmp/cavium/bin/
>  > valgrind -h
>  > -bash: /var/tmp/cavium/bin/valgrind: No such file or directory
>  >
>  >
>  > What's that blunder I am doing?
> 
> 
> At a guess the ELF interpreter specified in the compiled
> valgrind launcher doesn't exist - that can lead to that
> confusing error when running a executable that exists.
> 
> Try "file /var/tmp/cavium/bin/valgrind" and see what it says
> about it - part of the result should be something like this:
> 
>    interpreter /lib64/ld-linux-x86-64.so.2
> 
> which will tell what interpreter it is using.
> 
> Tom
> 
> -- 
> Tom Hughes (to...@co... <mailto:to...@co...>)
> http://compton.nu/ <http://compton.nu/>
> 


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

Re: [Valgrind-users] [Need Help] Valgrind on Cavium-Octeon-3

[mihir a. <mih...@ya...>]

 Tom,
Thanks a lot for your response.Yes, it doesn't look like the one I should be expecting..
file /var/tmp/cavium/bin/valgrind/var/tmp/cavium/bin/valgrind: ELF 64-bit MSB executable, MIPS, MIPS64 rel2 version 1 (SYSV), dynamically linked, interpreter /lib64-f, for GNU/Linux 2.6.32, not stripped
How to fix this?
-Mihir    On Thursday, 7 January, 2021, 04:36:45 pm IST, Tom Hughes <to...@co...> wrote:  
 
 On 07/01/2021 10:54, mihir amrelia via Valgrind-users wrote:

> I am trying to get valgrind running on cavium octeon 3 processor.
> 
> 
> Couldn't find any specific build configs for this other than some hints 
> on the valgrind wiki.
> *
> *
> *
> The steps executed to build valgrind for cavium were (on x86_64 host):
> *export CC=/opt/cavium-64bit/tools-3535/bin/mips64-octeon-linux-gnu-gcc
> export CXX=/opt/cavium-64bit/tools-3535/bin/mips64-octeon-linux-gnu-g++
> export PATH=$PATH:/opt/cavium-64bit/tools-3535/bin/
> ./configure --host=mips64-linux-gnu --target=mips64-octeon-linux 
> --prefix=/home/mihira/workspace/mylab/valgrind/cavium 
> --exec-prefix=/var/tmp/cavium --disable-tls
> make && make install
> 
> *While trying to run it on target (copied the elfs to /var/tmp/cavium/ 
> dir on the target):*
> export VALGRIND_LIB=/var/tmp/cavium/lib/valgrind/
> export PATH=$PATH:/var/tmp/cavium/bin/
> valgrind -h
> -bash: /var/tmp/cavium/bin/valgrind: No such file or directory
> 
> 
> What's that blunder I am doing?

At a guess the ELF interpreter specified in the compiled
valgrind launcher doesn't exist - that can lead to that
confusing error when running a executable that exists.

Try "file /var/tmp/cavium/bin/valgrind" and see what it says
about it - part of the result should be something like this:

  interpreter /lib64/ld-linux-x86-64.so.2

which will tell what interpreter it is using.

Tom

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

Re: [Valgrind-users] Integrating Valgrind into code

[Aaron B. <bo...@gm...>]

On Thu, Jan 7, 2021 at 2:29 PM Tom Hughes <to...@co...> wrote:

> On 07/01/2021 19:15, Aaron Boxer wrote:
>
> > I am hunting for an uninitialized memory issue. I have integrated
> > valgrind into my code, using cmake find_package, but when I call
> > |VALGRIND_CHECK_MEM_IS_DEFINED| it always returns 0 no matter what I
> > pass in. For example |VALGRIND_CHECK_MEM_IS_DEFINED(0x00,0xFFFFFF)|
> > returns zero.
> >
> > Am I missing something ?
>
> Well address zero is likely uninitialised so you would expect it to
> return zero as that is the address of the first uninitialised byte in
> the block - obviously that is unhelpful because it's the same response
> as if the whole block was defined but real systems will never use
> address zero for anything.
>


Thanks, Tom! Problem turned out to be me not RTFM ing.
I was not running under valgrind.

Cheers,
Aaron

Re: [Valgrind-users] Integrating Valgrind into code

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

On 07/01/2021 19:15, Aaron Boxer wrote:

> I am hunting for an uninitialized memory issue. I have integrated 
> valgrind into my code, using cmake find_package, but when I call 
> |VALGRIND_CHECK_MEM_IS_DEFINED| it always returns 0 no matter what I 
> pass in. For example |VALGRIND_CHECK_MEM_IS_DEFINED(0x00,0xFFFFFF)| 
> returns zero.
> 
> Am I missing something ?

Well address zero is likely uninitialised so you would expect it to
return zero as that is the address of the first uninitialised byte in
the block - obviously that is unhelpful because it's the same response
as if the whole block was defined but real systems will never use
address zero for anything.

Tom

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

[Valgrind-users] Integrating Valgrind into code

[Aaron B. <bo...@gm...>]

Hello,

I am hunting for an uninitialized memory issue. I have integrated valgrind
into my code, using cmake find_package, but when I call
VALGRIND_CHECK_MEM_IS_DEFINED it always returns 0 no matter what I pass in.
For example VALGRIND_CHECK_MEM_IS_DEFINED(0x00,0xFFFFFF) returns zero.

Am I missing something ?


Thank you,

Aaron

Re: [Valgrind-users] [Need Help] Valgrind on Cavium-Octeon-3

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

On 07/01/2021 10:54, mihir amrelia via Valgrind-users wrote:

> I am trying to get valgrind running on cavium octeon 3 processor.
> 
> 
> Couldn't find any specific build configs for this other than some hints 
> on the valgrind wiki.
> *
> *
> *
> The steps executed to build valgrind for cavium were (on x86_64 host):
> *export CC=/opt/cavium-64bit/tools-3535/bin/mips64-octeon-linux-gnu-gcc
> export CXX=/opt/cavium-64bit/tools-3535/bin/mips64-octeon-linux-gnu-g++
> export PATH=$PATH:/opt/cavium-64bit/tools-3535/bin/
> ./configure --host=mips64-linux-gnu --target=mips64-octeon-linux 
> --prefix=/home/mihira/workspace/mylab/valgrind/cavium 
> --exec-prefix=/var/tmp/cavium --disable-tls
> make && make install
> 
> *While trying to run it on target (copied the elfs to /var/tmp/cavium/ 
> dir on the target):*
> export VALGRIND_LIB=/var/tmp/cavium/lib/valgrind/
> export PATH=$PATH:/var/tmp/cavium/bin/
> valgrind -h
> -bash: /var/tmp/cavium/bin/valgrind: No such file or directory
> 
> 
> What's that blunder I am doing?

At a guess the ELF interpreter specified in the compiled
valgrind launcher doesn't exist - that can lead to that
confusing error when running a executable that exists.

Try "file /var/tmp/cavium/bin/valgrind" and see what it says
about it - part of the result should be something like this:

   interpreter /lib64/ld-linux-x86-64.so.2

which will tell what interpreter it is using.

Tom

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

[Valgrind-users] [Need Help] Valgrind on Cavium-Octeon-3

[mihir a. <mih...@ya...>]

Hi,

I am trying to get valgrind running on cavium octeon 3 processor.



Couldn't find any specific build configs for this other than some hints on the valgrind wiki.
The steps executed to build valgrind for cavium were (on x86_64 host):
export CC=/opt/cavium-64bit/tools-3535/bin/mips64-octeon-linux-gnu-gcc
export CXX=/opt/cavium-64bit/tools-3535/bin/mips64-octeon-linux-gnu-g++
export PATH=$PATH:/opt/cavium-64bit/tools-3535/bin/
./configure --host=mips64-linux-gnu --target=mips64-octeon-linux --prefix=/home/mihira/workspace/mylab/valgrind/cavium --exec-prefix=/var/tmp/cavium --disable-tls
make && make install



While trying to run it on target (copied the elfs to /var/tmp/cavium/ dir on the target):
export VALGRIND_LIB=/var/tmp/cavium/lib/valgrind/
export PATH=$PATH:/var/tmp/cavium/bin/
valgrind -h
-bash: /var/tmp/cavium/bin/valgrind: No such file or directory


What's that blunder I am doing?
Thanks,Mihir

Re: [Valgrind-users] Why valgrind tool massif does not print xtree callstack? (arm)

[Łukasz B. <Luk...@ra...>]

>> What does memcheck give if you use --xtree-memory=full ?

It found some errors for example:

1 errors in context 1 of 12:
Invalid read of size 4
    At 0x48F2064: CORBA::Stream::~Stream() (in /usr/lib/libOErb.so)
 Address 0x4fc0748 is 0 bytes inside a block of size 12 free'd
    At 0x4848314: operator delete(void*) (in /home/root/lbolda/vg16/usr/lib/arm-linux-gnueabihf/valgrind/vgpreload_memcheck-arm-linux.so)
 Block was alloc'd at
    At 0x4847154: operator new(unsigned in, std::nothrow_t const&) (in /home/root/lbolda/vg16/usr/lib/arm-linux-gnueabihf/valgrind/vgpreload_memcheck-arm-linux.so)

Rest of errors are verry similar.

>> Can you try the same gdb+vgdb+ break malloc experiment using --tool=none ?

(gdb) monitor v.info scheduler

Host stacktrace:
==2445== at 0x58031810: ??? (in /home/root/lbolda/vg16/usr/lib/arm-linux-gnueabihf/valgrind/none-arm-linux)

sched status:
	running_tid=1

Thread 1: status = VgTs_Runnable (lwpid 2445)
==2445==	at 0x41D46: service_main(int, char const**, bool) (serviceMain.cpp:22)
==2445==	by 0x41D1F: main (serviceMain.cpp:17)
client stack range: [0x7DE5C000 0xDE5DFFF] client SP: 0x7DE5D708
valgrind stack range: [0x41EBD00 0x41FBCFF] top usage: 25472 of 1048576

(gdb)


Best regards,
Łukasz Bolda

-----Original Message-----
From: Philippe Waroquiers <phi...@sk...> 
Sent: Monday, December 14, 2020 9:23 PM
To: Łukasz Bolda <Luk...@ra...>; val...@li...
Subject: Re: [Valgrind-users] Why valgrind tool massif does not print xtree callstack? (arm)

Strange ... 'v.info scheduler' shows that valgrind can compute a correct guest stack trace, but the output file is not correct.

It looks like with gdb+vgdb, you cannot put a breakpoint on a redirected function:
 valgrind/massif redirects malloc function to its own implementation, and so  the breakpoint is not reached (at least for me, on amd64 platform).

Also, the host stack trace is empty in the below 'v.info scheduler' output.


Does memcheck give the same unexpected behaviour for its (leak) reports ?

What does memcheck give if you use --xtree-memory=full ?

Can you try the same gdb+vgdb+ break malloc experiment using --tool=none ?

Thanks

Philippe



On Mon, 2020-12-14 at 10:26 +0100, Łukasz Bolda wrote:
> I'm using valgrind 3.14.0 from 
> http://ftp.debian.org/debian/pool/main/v/valgrind/
> Cause it's stable version.
> 
> I did not compile this application.
> 
> Right now i'm trying latest valgrind 3.16.1 and it changed from this:
> 99.87% (20,675,133B) (heap allocation functions) malloc/new/new[], --alloc-fns, etc.
> ->99.87% (20,675,133B) 0xFFFFFFFF: ???
> 
> to this (different app, but the only change is from 0xFFFFFFFF to 0x0):
> 99.82% (46,610B) (heap allocation functions) malloc/new/new[], --alloc-fns, etc.
> ->99.82% (46,610B) 0x0: ???
> 
> 
> Using "(gdb) break malloc" and then "(gdb) bt"produces regular 
> callstack
> 
> 
> Also using  gdb+vgdb is producing correct backtrace:
> (gdb) monitor v.info scheduler
> 
> Host stacktrace:
> ==1543== at 0x5800B148: ??? (in 
> /home/root/lbolda/vg16/usr/lib/arm-linux-gnueabihf/valgrind/massif-arm
> -linux)
> 
> sched status:
> 	running_tid=1
> 
> Thread 1: status = VgTs_Runnable (lwpid 1543)
> ==1543==	at 0x42826: service_main(int, char const**, bool) (serviceMain.cpp:155)
> ==1543==	by 0x41D1F: main (serviceMain.cpp:17)
> client stack range: [0x7DDE5000 0xDDE8FFF] client SP: 0x7DDE86A8 
> valgrind stack range: [0x41E82000 0x41F81FFF] top usage: 25600 of 
> 1048576
> 
> Thread 2: status = VgTs_WaitSys syscall 285 (lwpid 1560)
> (...)
> Thread 3: status = VgTs_WaitSys syscall 285 (lwpid 1561)
> (...)
> 
> 
> Thank you for helping me!
> 
> Best regards,
> Łukasz Bolda
> 
> 
> -----Original Message-----
> From: Philippe Waroquiers <phi...@sk...>
> Sent: Friday, December 11, 2020 4:31 PM
> To: Łukasz Bolda <Luk...@ra...>; 
> val...@li...
> Subject: Re: [Valgrind-users] Why valgrind tool massif does not print 
> xtree callstack? (arm)
> 
> Which version of valgrind are you using ?
> You much better should use the last released version (or a more recent GIT version).
> 
> Have you compiled your application with -g ?
> 
> In case you debug your native executable with gdb and put a break on malloc, is gdb backtrace command giving a good stack trace ?
> 
> If you then debug using  gdb+vgdb your executable running under valgrind, is then the gdb backtrace correct ?
> And when positioned on the break point, what is the output of
>    (gdb) monitor v.info scheduler
> 
> Thanks
> Philippe
> 
> On Fri, 2020-12-11 at 15:02 +0100, Łukasz Bolda wrote:
> > Hello!
> > This is my first message on this list, so I'd like to say hi to everyone!
> > 
> > I'm profiling my software using valgrind tool massif  on arm 
> > hardware with parameters like this:
> > valgrind --tool=massif --massif-out-file=massif.out.%p 
> > --xtree-memory=full --verbose MY_BIN
> > 
> > Unfortuatelly i do not receive any callstack in the results:
> > ms_print massif.out.1234
> > (...)
> > 99.87% (20,675,133B) (heap allocation functions) malloc/new/new[], 
> > --alloc-fns, etc.
> > ->99.87% (20,675,133B) 0xFFFFFFFF: ???
> > 
> > 
> > What sould i do to receive full callstacks from massif?
> > 
> > Same thing happens when i'm using this tool on system binary for eg. ls.
> > Only 0xFFFFFFFF is present.
> > 
> > On my x86 machine everything runs fine.
> > 
> > Greetings,
> > Łukasz Bolda
> > 
> > 
> > 
> > 
> > _______________________________________________
> > Valgrind-users mailing list
> > Val...@li...
> > https://lists.sourceforge.net/lists/listinfo/valgrind-users
> 
> 
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Malloc/free in different threads

[Saurabh T <sa...@ho...>]

Thank you! Found the bug in my code!


From: Philippe Waroquiers <phi...@sk...>
Sent: Friday, December 18, 2020 10:04 AM
To: Saurabh T <sa...@ho...>; Valgrind <val...@li...>
Subject: Re: [Valgrind-users] Malloc/free in different threads 
 
Hello,

No, valgrind/memcheck leak search is not impacted by the fact that one thread allocates
some memory and that the release/free is done by another thread.
That should not lead to a definite leak.

So, if Valgrind tells that there are definite leaks, that is likely real leaks
to be investigated.

Philippe


On Fri, 2020-12-18 at 14:53 +0000, Saurabh T wrote:
> Sorry I forgot to say the false positives are for memory leaks ("definitely lost").
> 
> 
> From: Saurabh T <sa...@ho...>
> Sent: Friday, December 18, 2020 9:44 AM
> To: Valgrind <val...@li...>
> Subject: [Valgrind-users] Malloc/free in different threads 
>  
> Hi, I believe I am seeing lots of false positives in valgrind if I call free() on a different thread from the one that called malloc() - 
> the pointers are exchanged between threads safely in between. Is this a known issue, or am I doing something wrong? Thank you.
> 
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Malloc/free in different threads

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

Hello,

No, valgrind/memcheck leak search is not impacted by the fact that one thread allocates
some memory and that the release/free is done by another thread.
That should not lead to a definite leak.

So, if Valgrind tells that there are definite leaks, that is likely real leaks
to be investigated.

Philippe


On Fri, 2020-12-18 at 14:53 +0000, Saurabh T wrote:
> Sorry I forgot to say the false positives are for memory leaks ("definitely lost").
> 
> 
> From: Saurabh T <sa...@ho...>
> Sent: Friday, December 18, 2020 9:44 AM
> To: Valgrind <val...@li...>
> Subject: [Valgrind-users] Malloc/free in different threads 
>  
> Hi, I believe I am seeing lots of false positives in valgrind if I call free() on a different thread from the one that called malloc() - 
> the pointers are exchanged between threads safely in between. Is this a known issue, or am I doing something wrong? Thank you.
> 
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users