valgrind-users — General discussion list for Valgrind users

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

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

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

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] Malloc/free in different threads

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

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.

Re: [Valgrind-users] Valgrind installation on AIX environment

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

Hello

Support for AIX was removed I believe in 2011.

Philippe


On Thu, 2020-12-17 at 12:31 +0000, SHAIKH Mohammadshaeeque wrote:
> Hello Valgrind Team,
>  
> I am interested to use Valgrind tool to detect memory leak issue on AIX for C++ programs,
> I want to know whether Valgrind tools supports for below type of specs environment?
>  
> AIX 7.1
> System Model: IBM,8284-22A
> Processor Type: PowerPC_POWER8
> Processor Implementation Mode: POWER 7
> CPU Type: 64-bit
> Kernel Type: 64-bit
> Xlc compiler
> dbx debugger
>  
> If yes then, please suggest to install on AIX which modification is needed on configure.sh file or other modifications.
>  
> Please provide your input.
>  
> Thanks,
> Mohammadshaeeque SHAIKH.
>  
>  
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users

[Valgrind-users] Valgrind installation on AIX environment

[SHAIKH M. <m.s...@so...>]

Hello Valgrind Team,

I am interested to use Valgrind tool to detect memory leak issue on AIX for C++ programs,
I want to know whether Valgrind tools supports for below type of specs environment?

AIX 7.1
System Model: IBM,8284-22A
Processor Type: PowerPC_POWER8
Processor Implementation Mode: POWER 7
CPU Type: 64-bit
Kernel Type: 64-bit
Xlc compiler
dbx debugger

If yes then, please suggest to install on AIX which modification is needed on configure.sh file or other modifications.

Please provide your input.

Thanks,
Mohammadshaeeque SHAIKH.

[Valgrind-users] Getting "Serious error when reading debug info" when using mmap

[Oren E. (A. Rahien) <ay...@ay...>]

Hi,
I'm getting a strange error when running Valgrind.

--23266-- WARNING: Serious error when reading debug info
--23266-- When reading debug info from /tmp/db/test.txt:
--23266-- can't read file to inspect ELF header

Note that the file in question is a data file, which I'm mmaping

I can reproduce this using the following code:
https://gist.github.com/ayende/d65a7a3c06556d62c8fa0f88b04ea449

valgrind-3.16.1 & clang version 10.0.0-4ubuntu1

This seems to be related to mmaping a file, but I can't figure out exactly
why

Running Valgrind under `strace` gives:

    mmap(0x4e4d000, 65536, PROT_READ, MAP_SHARED|MAP_FIXED, 3, 0) =
0x4e4d000
    statx(3, "", AT_STATX_SYNC_AS_STAT|AT_EMPTY_PATH, STATX_ALL,
{stx_mask=STATX_ALL, stx_attributes=0, stx_mode=S_IFREG|0600,
stx_size=262144, ...}) = 0
    readlink("/proc/self/fd/3", "/tmp/db/test.txt", 4096) = 16
    statx(AT_FDCWD, "/tmp/db/test.txt", AT_STATX_SYNC_AS_STAT, STATX_ALL,
{stx_mask=STATX_ALL, stx_attributes=0, stx_mode=S_IFREG|0600,
stx_size=262144, ...}) = 0
    pread64(3, 0x10032c68a0, 1024, 0)       = -1 EINVAL (Invalid argument)
    getpid()                                = 23260
    write(1027, "--23260-- WARNING: Serious error"..., 57--23260-- WARNING:
Serious error when reading debug info
    ) = 57
    getpid()                                = 23260
    write(1027, "--23260-- When reading debug inf"..., 57--23260-- When
reading debug info from /tmp/db/test.txt:

So it looks like the `pread64()` code is failing, but I can't figure out
why that is the case, or why it would cause Valgrind to give this error.
Any ideas?

Re: [Valgrind-users] Getting "Serious error when reading debug info" when using mmap

[Oren E. (A. Rahien) <ay...@ay...>]

FWIW, I'm pretty sure that the issue is around the use of O_DIRECT and
alignment of memory.
Note that in the call to pread64() , the buffer isn't 4KB aligned, which is
usually required for O_DIRECT.
I assume that this generates the error and the rest of the issue.

On Wed, Dec 16, 2020 at 11:17 PM Oren Eini (Ayende Rahien) <
ay...@ay...> wrote:

> Hi,
> I'm getting a strange error when running Valgrind.
>
> --23266-- WARNING: Serious error when reading debug info
> --23266-- When reading debug info from /tmp/db/test.txt:
> --23266-- can't read file to inspect ELF header
>
> Note that the file in question is a data file, which I'm mmaping
>
> I can reproduce this using the following code:
> https://gist.github.com/ayende/d65a7a3c06556d62c8fa0f88b04ea449
>
> valgrind-3.16.1 & clang version 10.0.0-4ubuntu1
>
> This seems to be related to mmaping a file, but I can't figure out exactly
> why
>
> Running Valgrind under `strace` gives:
>
>     mmap(0x4e4d000, 65536, PROT_READ, MAP_SHARED|MAP_FIXED, 3, 0) =
> 0x4e4d000
>     statx(3, "", AT_STATX_SYNC_AS_STAT|AT_EMPTY_PATH, STATX_ALL,
> {stx_mask=STATX_ALL, stx_attributes=0, stx_mode=S_IFREG|0600,
> stx_size=262144, ...}) = 0
>     readlink("/proc/self/fd/3", "/tmp/db/test.txt", 4096) = 16
>     statx(AT_FDCWD, "/tmp/db/test.txt", AT_STATX_SYNC_AS_STAT, STATX_ALL,
> {stx_mask=STATX_ALL, stx_attributes=0, stx_mode=S_IFREG|0600,
> stx_size=262144, ...}) = 0
>     pread64(3, 0x10032c68a0, 1024, 0)       = -1 EINVAL (Invalid argument)
>     getpid()                                = 23260
>     write(1027, "--23260-- WARNING: Serious error"..., 57--23260--
> WARNING: Serious error when reading debug info
>     ) = 57
>     getpid()                                = 23260
>     write(1027, "--23260-- When reading debug inf"..., 57--23260-- When
> reading debug info from /tmp/db/test.txt:
>
> So it looks like the `pread64()` code is failing, but I can't figure out
> why that is the case, or why it would cause Valgrind to give this error.
> Any ideas?
>


-- 
<https://ravendb.net/> *Oren Eini*
*CEO   /   Hibernating Rhinos LTD <https://hibernatingrhinos.com/>*
Mobile:  972-52-548-6969
Sales:  sa...@ra...
Skype:  ayenderahien
Support:  su...@ra...
<https://www.facebook.com/pages/RavenDB/265907650186374>
<https://twitter.com/ravendb>
<https://www.linkedin.com/company/hibernating-rhinos-ltd-/>
<https://ravendb.net/emailsignature/displayeventpage>

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

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

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] Why valgrind tool massif does not print xtree callstack? (arm)

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

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

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

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

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] Why valgrind tool massif does not print xtree callstack? (arm)

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

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

Re: [Valgrind-users] 3.16.1 RPi 3b+

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

On 2020-12-07 20:22 UTC, John A wrote:
  [[attachment smime.p7m]]

Send the body of the message in plain text,
perhaps crypto-signed with the signature in an attachment.
Nobody pays any attention to a .p7m body.

[Valgrind-users] 3.16.1 RPi 3b+

[John A <jo...@ar...>]

0€	*†H†÷

 €0€

10	+

[Valgrind-users] Obtaining Use-Def information of temporaries in VEX-IR

[Yashas A. <es1...@ii...>]

Hello

I'm trying to write a Valgrind tool that will obtain Use-Def information of
temporary values in VEX-IR, i.e, the definition of a temporary value and
its uses in the IR. Does an implementation of this already exist in
Valgrind which I can use, or should I start from scratch?

Thanks
Yashas

-- 


Disclaimer:- The information contained in this electronic message and any 
attachments to this message are intended for the exclusive use of the 
addressee(s) and may contain proprietary, confidential or privileged 
information. If you are not the intended recipient, you should not 
disseminate, distribute or copy this email. Please notify the sender 
immediately and destroy all copies of this message and any attachments. The 
views expressed in this E-mail message (including the enclosure/(s) or 
attachment/(s) if any) are those of the individual sender, except where the 
sender expressly, and with authority, states them to be the views of IIT 
Hyderabad. Before opening any mail and attachments please check them for 
viruses, malware, and the sender email address is indeed from IITH domain. 
IITH does not accept any liability for malware infected mails.

Re: [Valgrind-users] Automated report for valgrind

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

> I would like to ask if there is any automated reporting tool which processes the output of the valgrind tool and also scans the code in order to do a "blame" or "annotate" per developer.

The real error (the place that needs fixing) can be several levels up the call chain,
and in C++ is not always the most-recent non-STL code.  Identifying the root cause
can require an experienced human in many cases.

[Valgrind-users] Automated report for valgrind

[Dimitris K. <kat...@gm...>]

Hi everyone,

I would like to ask if there is any automated reporting tool which
processes the output of the valgrind tool and also scans the code in order
to do a "blame" or "annotate" per developer.

Thanks

Re: [Valgrind-users] License Question

[Mark W. <ma...@kl...>]

Hi,

On Sun, Nov 08, 2020 at 01:06:39PM -0500, Rayce West wrote:
> After researching GGPL some, I'm wondering how it's possible that angr (and
> pyvex) are allowed to use BSD licenses when they integrate VEX as their
> lifter and IR, especially since it's the General and not the Lesser?

It is fine to combine code under a lax-permissive license like the BSD
and code under the GPL, like valgrind. As long as the licenses don't
conflict and the program as a whole is distributed under the GPL. See
GPLv2, section 2 (b).

Cheers,

Mark