valgrind-users — General discussion list for Valgrind users

Re: [Valgrind-users] valgrind-3.18.0.RC1 is available for testing

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

On 10/12/21 10:13 PM, Mark Wielaard wrote:
> An RC1 tarball for 3.18.0 is now available at
> https://sourceware.org/pub/valgrind/valgrind-3.18.0.RC1.tar.bz2
> (md5sum = 6babaf9e145055a2c9b50cbd2ddfefc0)
> (sha1sum = ccc73895097cba83cf7664b02edc66866e98a31b)
>
> Please give it a try in configurations that are important for you and
> report any problems you have, either on this mailing list, or
> (preferably) via our bug tracker at
> https://bugs.kde.org/enter_bug.cgi?product=valgrind
>
> If nothing critical emerges, a final release will happen on Friday
> 15 October.


Hi Mark

I've tested on FreeBSD 12.2 and 13.0. Both as expected.

Additionally I've tried Solaris 11.3 (OK and no change) and macOS 10.7.5 
(not very good but no change either).

It's a green light for me.


Cheers

Paul

[Valgrind-users] valgrind-3.18.0.RC1 is available for testing

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

An RC1 tarball for 3.18.0 is now available at
https://sourceware.org/pub/valgrind/valgrind-3.18.0.RC1.tar.bz2
(md5sum = 6babaf9e145055a2c9b50cbd2ddfefc0)
(sha1sum = ccc73895097cba83cf7664b02edc66866e98a31b)

Please give it a try in configurations that are important for you and
report any problems you have, either on this mailing list, or
(preferably) via our bug tracker at
https://bugs.kde.org/enter_bug.cgi?product=valgrind

If nothing critical emerges, a final release will happen on Friday
15 October.

Note that the NEWS file hasn't been fully updated yet.

[Valgrind-users] trying to understand behavior with call indirect through plt

[Mark R. <ma...@cs...>]

If I run the exact same version of my Valgrind based tool on the exact same
target binary but on different disk drives I get a different result.  I
understand that different block sizes on the two drives might cause
different paths through the C runtime, but I would expect the user program
to have the exact same results.

The difference appears to be the processing of the instruction (on AMD64):
 callq  400c50 <fputs@plt>

I understand how the plt/got code works in general, but I am curious as to
how Valgrind treats it.

I am using the trace-flags option to observe the program flow of control.
So the two program executions are basically matching until we get to the
second time the program calls fputs.  In one case, the next SB processed
starts with the instruction after the call.  In the other case, it appears
the indirect call sends us out into the middle of the clib routine
_IO_default_xsputn as that is the next SB processed.  Then the next SB after
that one is the instruction after the call as in the first case.

As my program is using Valgrind to do code instrumentation, the addition of
the extra  xsputn SB has a knock on effect that changes the program output.

I am assuming that previously translated SBs are 'skipped' in the
trace-flags output.  Is there an option to show  that SB <number> is being
executed again?  That is, show the complete flow of control for the program?
Assuming my program has not trashed Valgrind in some way, could it be
possible that _IO_default_xsputn is a portion of the code for fputs that was
not needed in one case do to the difference in disk block sizes?


Thank you,
Mark Roberts
UW PLSE group

Re: [Valgrind-users] Why valgrind can't see this error?

[Eric C. <Eri...@gi...>]

Hi John,

On 2021-09-03 6:53 p.m., John Reiser wrote:
> On 9/3/21 12:31 PM, Eric Chamberland wrote:
>> Hi,
>>
>> I have a simple test and valgrind seems to not see the error:
>>
>> cat fread.cc && clang++ -o fread fread.cc && valgrind ./fread
>> #include <iostream>
>> #include <stdio.h>
>> #include <stdlib.h>
>>
>> int main(int argc, char ** argv){
>>      int lA {1};
>>      FILE * f = fopen ( argv[0] , "rb" );
>>      fread(&lA,2*sizeof(int),1,f);
>>      std::cout << "Hello: "<< lA << std::endl;
>>      return 0;
>> }
>
> This report is interesting only because it is a bad example:
> it does not specify what is the supposed error.
> If you don't say what you believe it is, then how are valgrind 
> developers to know?

Yes, indeed, sorry for not giving a good example!

>
> Besides, the "memcheck error" is covered in the valgrind FAQ.
> Look it up in paragraph "4.6.  Why doesn't Memcheck find ..."

Ok, thanks, the answer was there : 
https://valgrind.org/docs/manual/faq.html#faq.overruns

> The second and third errors are the logic errors of not checking
> the return value of fopen and fread.
> The fourth error is not documenting the expected invocation command line.
> The fifth error is not checking argc.
> The sixth error is not documenting the expected format of the input file.
> Are you sure that you really are a programmer?

I am happy with your answer, no need to dive into this: you helped 
someone! :)

Thanks again John!

Eric

>
>
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users

-- 
Eric Chamberland, ing., M. Ing
Professionnel de recherche
GIREF/Université Laval
(418) 656-2131 poste 41 22 42

Re: [Valgrind-users] Very slow execution under Fedora 34

[Alvaro K. <ku...@gm...>]

Yes, I installed debuginfo to try gdb reverse-step.

The packages installed where: debuginfo-install glibc-2.33-20.fc34.x86_64
libgcc-11.2.1-1.fc34.x86_64 libstdc++-11.2.1-1.fc34.x86_64

On Mon, Sep 6, 2021 at 8:37 AM Mark Wielaard <ma...@kl...> wrote:

> Hi,
>
> On Sun, 2021-09-05 at 20:29 -0300, Alvaro Kuolas wrote:
> > I am running valgrind on my PC with dual boot Windows 10 and Fedora
> > 34.
> >
> > Running the same test on Ubuntu 20.04 (under Windows 10 WSL2)
> > valgrind runs
> > in less than a second, but on Fedora 34 is very slow, several minutes
> > slow.
> >
> > On Fedora 34 it looks like the time spent is reading symbols.
>
> Do you have lots of debuginfo packages installed or is the
> DEBUGINFOD_URLS set? See https://fedoraproject.org/wiki/Debuginfod
>
> valgrind is fairly slow parsing all the DWARF information. But will
> happily use debuginfod to fetch more or use all debuginfo packages
> installed for any library you have installed.
>
> In your case it might be help unsetting DEBUGINFOD_URLS and looking
> trough the list of installed debuginfo packages and uninstall some (if
> I read your log it is probably libstdc++-debuginfo that takes a lot of
> time to parse.
>
> Cheers,
>
> Mark
>

Re: [Valgrind-users] Very slow execution under Fedora 34

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

Hi,

On Sun, 2021-09-05 at 20:29 -0300, Alvaro Kuolas wrote:
> I am running valgrind on my PC with dual boot Windows 10 and Fedora
> 34.
> 
> Running the same test on Ubuntu 20.04 (under Windows 10 WSL2)
> valgrind runs
> in less than a second, but on Fedora 34 is very slow, several minutes
> slow.
> 
> On Fedora 34 it looks like the time spent is reading symbols.

Do you have lots of debuginfo packages installed or is the
DEBUGINFOD_URLS set? See https://fedoraproject.org/wiki/Debuginfod

valgrind is fairly slow parsing all the DWARF information. But will
happily use debuginfod to fetch more or use all debuginfo packages
installed for any library you have installed.

In your case it might be help unsetting DEBUGINFOD_URLS and looking
trough the list of installed debuginfo packages and uninstall some (if
I read your log it is probably libstdc++-debuginfo that takes a lot of
time to parse.

Cheers,

Mark

Re: [Valgrind-users] Very slow execution under Fedora 34

[Alvaro K. <ku...@gm...>]

My program is very simple: they are exercises from a course about ADT
(Abstract Data Types).

On Sun, Sep 5, 2021 at 11:24 PM John Borland <
all...@gm...> wrote:

> if you have a lot of threads you can try the fair scheduler flag.
>
> On Sun, Sep 5, 2021, 8:59 PM John Reiser <jr...@bi...> wrote:
>
>> > I am running valgrind on my PC with dual boot Windows 10 and Fedora 34.
>> >
>> > Running the same test on Ubuntu 20.04 (under Windows 10 WSL2) valgrind
>> runs in less than a second, but on Fedora 34 is very slow, several minutes
>> slow.
>> >
>> > On Fedora 34 it looks like the time spent is reading symbols.
>> >
>> > This is the part that takes most of the time:
>> >
>> > --23524-- Reading syms from /usr/lib64/libstdc++.so.6.0.29
>> > --23524--   Considering
>> /usr/lib/debug/.build-id/bd/d633ff5da0bba64d19ecf277a9eed7001da127.debug ..
>> > --23524--   .. build-id is valid
>> > --23524--   Considering
>> /usr/lib/debug/.build-id/bd/../../../../../usr/lib/debug/usr/lib64/../../.dwz/gcc-11.2.1-1.fc34.x86_64
>> ..
>> > --23524--   .. build-id is valid
>> [[snip]]
>> >
>> > What could be the problem? GGC 11 perhaps?
>>
>> There have been some hints of trouble with the DWARF-5 symbol reader.
>> Thus a work-around might be to avoid DWARF-5 by using an older gcc.
>>
>> If you can, please run "perf record" and then "perf report",
>> and copy+paste (or attach) info into a Bug Report (see
>> https://valgrind.org).
>> Then post the bug link here with a teaser.
>>
>>
>>
>> _______________________________________________
>> 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] Very slow execution under Fedora 34

[Alvaro K. <ku...@gm...>]

I opened a bug report

https://bugs.kde.org/show_bug.cgi?id=442061

I have attached perf-record data

Thanks for your help!

On Sun, Sep 5, 2021 at 10:59 PM John Reiser <jr...@bi...> wrote:

> > I am running valgrind on my PC with dual boot Windows 10 and Fedora 34.
> >
> > Running the same test on Ubuntu 20.04 (under Windows 10 WSL2) valgrind
> runs in less than a second, but on Fedora 34 is very slow, several minutes
> slow.
> >
> > On Fedora 34 it looks like the time spent is reading symbols.
> >
> > This is the part that takes most of the time:
> >
> > --23524-- Reading syms from /usr/lib64/libstdc++.so.6.0.29
> > --23524--   Considering
> /usr/lib/debug/.build-id/bd/d633ff5da0bba64d19ecf277a9eed7001da127.debug ..
> > --23524--   .. build-id is valid
> > --23524--   Considering
> /usr/lib/debug/.build-id/bd/../../../../../usr/lib/debug/usr/lib64/../../.dwz/gcc-11.2.1-1.fc34.x86_64
> ..
> > --23524--   .. build-id is valid
> [[snip]]
> >
> > What could be the problem? GGC 11 perhaps?
>
> There have been some hints of trouble with the DWARF-5 symbol reader.
> Thus a work-around might be to avoid DWARF-5 by using an older gcc.
>
> If you can, please run "perf record" and then "perf report",
> and copy+paste (or attach) info into a Bug Report (see
> https://valgrind.org).
> Then post the bug link here with a teaser.
>
>
>
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>

Re: [Valgrind-users] Very slow execution under Fedora 34

[John B. <all...@gm...>]

if you have a lot of threads you can try the fair scheduler flag.

On Sun, Sep 5, 2021, 8:59 PM John Reiser <jr...@bi...> wrote:

> > I am running valgrind on my PC with dual boot Windows 10 and Fedora 34.
> >
> > Running the same test on Ubuntu 20.04 (under Windows 10 WSL2) valgrind
> runs in less than a second, but on Fedora 34 is very slow, several minutes
> slow.
> >
> > On Fedora 34 it looks like the time spent is reading symbols.
> >
> > This is the part that takes most of the time:
> >
> > --23524-- Reading syms from /usr/lib64/libstdc++.so.6.0.29
> > --23524--   Considering
> /usr/lib/debug/.build-id/bd/d633ff5da0bba64d19ecf277a9eed7001da127.debug ..
> > --23524--   .. build-id is valid
> > --23524--   Considering
> /usr/lib/debug/.build-id/bd/../../../../../usr/lib/debug/usr/lib64/../../.dwz/gcc-11.2.1-1.fc34.x86_64
> ..
> > --23524--   .. build-id is valid
> [[snip]]
> >
> > What could be the problem? GGC 11 perhaps?
>
> There have been some hints of trouble with the DWARF-5 symbol reader.
> Thus a work-around might be to avoid DWARF-5 by using an older gcc.
>
> If you can, please run "perf record" and then "perf report",
> and copy+paste (or attach) info into a Bug Report (see
> https://valgrind.org).
> Then post the bug link here with a teaser.
>
>
>
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>

Re: [Valgrind-users] Very slow execution under Fedora 34

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

> I am running valgrind on my PC with dual boot Windows 10 and Fedora 34.
> 
> Running the same test on Ubuntu 20.04 (under Windows 10 WSL2) valgrind runs in less than a second, but on Fedora 34 is very slow, several minutes slow.
> 
> On Fedora 34 it looks like the time spent is reading symbols.
> 
> This is the part that takes most of the time:
> 
> --23524-- Reading syms from /usr/lib64/libstdc++.so.6.0.29
> --23524--   Considering /usr/lib/debug/.build-id/bd/d633ff5da0bba64d19ecf277a9eed7001da127.debug ..
> --23524--   .. build-id is valid
> --23524--   Considering /usr/lib/debug/.build-id/bd/../../../../../usr/lib/debug/usr/lib64/../../.dwz/gcc-11.2.1-1.fc34.x86_64 ..
> --23524--   .. build-id is valid
[[snip]]
> 
> What could be the problem? GGC 11 perhaps?

There have been some hints of trouble with the DWARF-5 symbol reader.
Thus a work-around might be to avoid DWARF-5 by using an older gcc.

If you can, please run "perf record" and then "perf report",
and copy+paste (or attach) info into a Bug Report (see https://valgrind.org).
Then post the bug link here with a teaser.

Re: [Valgrind-users] Very slow execution under Fedora 34

[Alvaro K. <ku...@gm...>]

This is using valgrind compiled from GIT sources using my test program:

[alvarok@YELLOWJACKET tarea5]$ valgrind -v ./principal
==45395== Memcheck, a memory error detector
==45395== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==45395== Using Valgrind-3.18.0.GIT-1bee3ab757-20210901 and LibVEX; rerun
with -h for copyright info
==45395== Command: ./principal
==45395==
--45395-- Valgrind options:
--45395--    -v
--45395-- Contents of /proc/version:
--45395--   Linux version 5.13.13-200.fc34.x86_64 (
moc...@bk...) (gcc (GCC) 11.2.1 20210728 (Red
Hat 11.2.1-1), GNU ld version 2.35.2-5.fc34) #1 SMP Thu Aug 26 17:06:39 UTC
2021
--45395--
--45395-- Arch and hwcaps: AMD64, LittleEndian,
amd64-cx16-lzcnt-rdtscp-sse3-ssse3-avx-avx2-bmi-f16c-rdrand-rdseed
--45395-- Page sizes: currently 4096, max supported 4096
--45395-- Valgrind library directory: /usr/local/libexec/valgrind
--45395-- Reading syms from
/home/alvarok/Development/Skills/Prog2/Laboratorio/Tarea5/tarea5/principal
--45395-- Reading syms from /usr/lib64/ld-2.33.so
--45395-- Warning: cross-CU LIMITATION: some inlined fn names
--45395-- might be shown as UnknownInlinedFun
--45395-- Reading syms from /usr/local/libexec/valgrind/memcheck-amd64-linux
--45395--    object doesn't have a dynamic symbol table
--45395-- Scheduler: using generic scheduler lock implementation.
--45395-- Reading suppressions file:
/usr/local/libexec/valgrind/default.supp
==45395== embedded gdbserver: reading from
/tmp/vgdb-pipe-from-vgdb-to-45395-by-alvarok-on-YELLOWJACKET
==45395== embedded gdbserver: writing to
/tmp/vgdb-pipe-to-vgdb-from-45395-by-alvarok-on-YELLOWJACKET
==45395== embedded gdbserver: shared mem
/tmp/vgdb-pipe-shared-mem-vgdb-45395-by-alvarok-on-YELLOWJACKET
==45395==
==45395== TO CONTROL THIS PROCESS USING vgdb (which you probably
==45395== don't want to do, unless you know exactly what you're doing,
==45395== or are doing some strange experiment):
==45395==   /usr/local/libexec/valgrind/../../bin/vgdb --pid=45395
...command...
==45395==
==45395== TO DEBUG THIS PROCESS USING GDB: start GDB like this
==45395==   /path/to/gdb ./principal
==45395== and then give GDB the following command
==45395==   target remote | /usr/local/libexec/valgrind/../../bin/vgdb
--pid=45395
==45395== --pid is optional if only one valgrind process is running
==45395==
--45395-- REDIR: 0x4025130 (ld-linux-x86-64.so.2:strlen) redirected to
0x580b31e2 (vgPlain_amd64_linux_REDIR_FOR_strlen)
--45395-- REDIR: 0x4024f00 (ld-linux-x86-64.so.2:index) redirected to
0x580b31fc (vgPlain_amd64_linux_REDIR_FOR_index)
--45395-- Reading syms from
/usr/local/libexec/valgrind/vgpreload_core-amd64-linux.so
--45395-- Reading syms from
/usr/local/libexec/valgrind/vgpreload_memcheck-amd64-linux.so
==45395== WARNING: new redirection conflicts with existing -- ignoring it
--45395--     old: 0x04025130 (strlen              ) R-> (0000.0)
0x580b31e2 vgPlain_amd64_linux_REDIR_FOR_strlen
--45395--     new: 0x04025130 (strlen              ) R-> (2007.0)
0x048463c0 strlen
--45395-- REDIR: 0x4021910 (ld-linux-x86-64.so.2:strcmp) redirected to
0x4847220 (strcmp)
--45395-- REDIR: 0x4025690 (ld-linux-x86-64.so.2:mempcpy) redirected to
0x484ac90 (mempcpy)
--45395-- Reading syms from /usr/lib64/libstdc++.so.6.0.29
--45395--   Considering
/usr/lib/debug/.build-id/bd/d633ff5da0bba64d19ecf277a9eed7001da127.debug ..
--45395--   .. build-id is valid
--45395--   Considering
/usr/lib/debug/.build-id/bd/../../../../../usr/lib/debug/usr/lib64/../../.dwz/gcc-11.2.1-1.fc34.x86_64
..
--45395--   .. build-id is valid
--45395-- Reading syms from /usr/lib64/libm-2.33.so
--45395--   Considering
/usr/lib/debug/.build-id/c1/784bbe8a93a6e62f74b16105a2076a03b398ac.debug ..
--45395--   .. build-id is valid
--45395-- Reading syms from /usr/lib64/libgcc_s-11-20210728.so.1
--45395--   Considering
/usr/lib/debug/.build-id/46/e10c9ee769c5cfc7cdb638e3ccbc3169c0a949.debug ..
--45395--   .. build-id is valid
--45395--   Considering
/usr/lib/debug/.build-id/46/../../../../../usr/lib/debug/lib64/../.dwz/gcc-11.2.1-1.fc34.x86_64
..
--45395--   .. build-id is valid
--45395-- Reading syms from /usr/lib64/libc-2.33.so
--45395--   Considering
/usr/lib/debug/.build-id/9d/e0f6e78ec16db4c6c167efc6b37466705edeff.debug ..
--45395--   .. build-id is valid
--45395--   Considering
/usr/lib/debug/.build-id/9d/../../../../../usr/lib/debug/lib64/../.dwz/glibc-2.33-20.fc34.x86_64
..
--45395--   .. build-id is valid
--45395-- REDIR: 0x4c6eee0 (libc.so.6:memmove) redirected to 0x48351b6
(_vgnU_ifunc_wrapper)
==45395== Preferring higher priority redirection:
--45395--     old: 0x04d41710 (__memcpy_avx_unalign) R-> (2018.0)
0x04848470 __memcpy_avx_unaligned_erms
--45395--     new: 0x04d41710 (__memcpy_avx_unalign) R-> (2018.1)
0x04849d10 memmove
--45395-- REDIR: 0x4c6e3e0 (libc.so.6:strncpy) redirected to 0x48351b6
(_vgnU_ifunc_wrapper)
--45395-- REDIR: 0x4c6f220 (libc.so.6:strcasecmp) redirected to 0x48351b6
(_vgnU_ifunc_wrapper)
--45395-- REDIR: 0x4c6de90 (libc.so.6:strcat) redirected to 0x48351b6
(_vgnU_ifunc_wrapper)
--45395-- REDIR: 0x4c6e440 (libc.so.6:rindex) redirected to 0x48351b6
(_vgnU_ifunc_wrapper)
--45395-- REDIR: 0x4c705d0 (libc.so.6:rawmemchr) redirected to 0x48351b6
(_vgnU_ifunc_wrapper)
--45395-- REDIR: 0x4c88680 (libc.so.6:wmemchr) redirected to 0x48351b6
(_vgnU_ifunc_wrapper)
--45395-- REDIR: 0x4c881c0 (libc.so.6:wcscmp) redirected to 0x48351b6
(_vgnU_ifunc_wrapper)
--45395-- REDIR: 0x4c6f040 (libc.so.6:mempcpy) redirected to 0x48351b6
(_vgnU_ifunc_wrapper)
--45395-- REDIR: 0x4c6ee70 (libc.so.6:bcmp) redirected to 0x48351b6
(_vgnU_ifunc_wrapper)
--45395-- REDIR: 0x4c6e380 (libc.so.6:strncmp) redirected to 0x48351b6
(_vgnU_ifunc_wrapper)
--45395-- REDIR: 0x4c6df40 (libc.so.6:strcmp) redirected to 0x48351b6
(_vgnU_ifunc_wrapper)
--45395-- REDIR: 0x4c6efb0 (libc.so.6:memset) redirected to 0x48351b6
(_vgnU_ifunc_wrapper)
--45395-- REDIR: 0x4c88180 (libc.so.6:wcschr) redirected to 0x48351b6
(_vgnU_ifunc_wrapper)
--45395-- REDIR: 0x4c6e2e0 (libc.so.6:strnlen) redirected to 0x48351b6
(_vgnU_ifunc_wrapper)
--45395-- REDIR: 0x4c6e020 (libc.so.6:strcspn) redirected to 0x48351b6
(_vgnU_ifunc_wrapper)
--45395-- REDIR: 0x4c6f270 (libc.so.6:strncasecmp) redirected to 0x48351b6
(_vgnU_ifunc_wrapper)
--45395-- REDIR: 0x4c6dfc0 (libc.so.6:strcpy) redirected to 0x48351b6
(_vgnU_ifunc_wrapper)
--45395-- REDIR: 0x4c6f3c0 (libc.so.6:memcpy@@GLIBC_2.14) redirected to
0x48351b6 (_vgnU_ifunc_wrapper)
--45395-- REDIR: 0x4c898d0 (libc.so.6:wcsnlen) redirected to 0x48351b6
(_vgnU_ifunc_wrapper)
--45395-- REDIR: 0x4c88200 (libc.so.6:wcscpy) redirected to 0x48351b6
(_vgnU_ifunc_wrapper)
--45395-- REDIR: 0x4c6e480 (libc.so.6:strpbrk) redirected to 0x48351b6
(_vgnU_ifunc_wrapper)
--45395-- REDIR: 0x4c6def0 (libc.so.6:index) redirected to 0x48351b6
(_vgnU_ifunc_wrapper)
--45395-- REDIR: 0x4c6e2a0 (libc.so.6:strlen) redirected to 0x48351b6
(_vgnU_ifunc_wrapper)
--45395-- REDIR: 0x4c74a80 (libc.so.6:memrchr) redirected to 0x48351b6
(_vgnU_ifunc_wrapper)
--45395-- REDIR: 0x4c6f2c0 (libc.so.6:strcasecmp_l) redirected to 0x48351b6
(_vgnU_ifunc_wrapper)
--45395-- REDIR: 0x4c6ee30 (libc.so.6:memchr) redirected to 0x48351b6
(_vgnU_ifunc_wrapper)
--45395-- REDIR: 0x4c882d0 (libc.so.6:wcslen) redirected to 0x48351b6
(_vgnU_ifunc_wrapper)
--45395-- REDIR: 0x4c6e5a0 (libc.so.6:strspn) redirected to 0x48351b6
(_vgnU_ifunc_wrapper)
--45395-- REDIR: 0x4c6f1c0 (libc.so.6:stpncpy) redirected to 0x48351b6
(_vgnU_ifunc_wrapper)
--45395-- REDIR: 0x4c6f160 (libc.so.6:stpcpy) redirected to 0x48351b6
(_vgnU_ifunc_wrapper)
--45395-- REDIR: 0x4c70610 (libc.so.6:strchrnul) redirected to 0x48351b6
(_vgnU_ifunc_wrapper)
--45395-- REDIR: 0x4c6f310 (libc.so.6:strncasecmp_l) redirected to
0x48351b6 (_vgnU_ifunc_wrapper)
--45395-- REDIR: 0x4d3e530 (libc.so.6:__strrchr_avx2) redirected to
0x4845e00 (rindex)
--45395-- REDIR: 0x4c6a100 (libc.so.6:malloc) redirected to 0x4840739
(malloc)
--45395-- REDIR: 0x490da50 (libstdc++.so.6:operator new(unsigned long))
redirected to 0x4840ea3 (operator new(unsigned long))
--45395-- REDIR: 0x490dab0 (libstdc++.so.6:operator new[](unsigned long))
redirected to 0x4842095 (operator new[](unsigned long))
--45395-- REDIR: 0x4d3e340 (libc.so.6:__strchrnul_avx2) redirected to
0x484a790 (strchrnul)
--45395-- REDIR: 0x4d416f0 (libc.so.6:__mempcpy_avx_unaligned_erms)
redirected to 0x484a8a0 (mempcpy)
1>Fin
--45395-- REDIR: 0x4d39bf0 (libc.so.6:__strcmp_avx2) redirected to
0x4847120 (strcmp)
--45395-- REDIR: 0x4d3e700 (libc.so.6:__strlen_avx2) redirected to
0x48462a0 (strlen)
Fin.
--45395-- REDIR: 0x4d3a560 (libc.so.6:__memchr_avx2) redirected to
0x48472a0 (memchr)
--45395-- REDIR: 0x4d41710 (libc.so.6:__memcpy_avx_unaligned_erms)
redirected to 0x4849d10 (memmove)
--45395-- REDIR: 0x490bd00 (libstdc++.so.6:operator delete(void*, unsigned
long)) redirected to 0x48436d3 (operator delete(void*, unsigned long))
--45395-- REDIR: 0x490bd20 (libstdc++.so.6:operator delete[](void*))
redirected to 0x48443f9 (operator delete[](void*))
--45395-- REDIR: 0x4c6a760 (libc.so.6:free) redirected to 0x4842f0e (free)
==45395==
==45395== HEAP SUMMARY:
==45395==     in use at exit: 0 bytes in 0 blocks
==45395==   total heap usage: 23 allocs, 23 frees, 75,192 bytes allocated
==45395==
==45395== All heap blocks were freed -- no leaks are possible
==45395==
==45395== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

On Sun, Sep 5, 2021 at 8:29 PM Alvaro Kuolas <ku...@gm...> wrote:

> Hello everyone!
>
> I am running valgrind on my PC with dual boot Windows 10 and Fedora 34.
>
> Running the same test on Ubuntu 20.04 (under Windows 10 WSL2) valgrind
> runs in less than a second, but on Fedora 34 is very slow, several minutes
> slow.
>
> On Fedora 34 it looks like the time spent is reading symbols.
>
> This is the part that takes most of the time:
>
> --23524-- Reading syms from /usr/lib64/libstdc++.so.6.0.29
> --23524--   Considering
> /usr/lib/debug/.build-id/bd/d633ff5da0bba64d19ecf277a9eed7001da127.debug ..
> --23524--   .. build-id is valid
> --23524--   Considering
> /usr/lib/debug/.build-id/bd/../../../../../usr/lib/debug/usr/lib64/../../.dwz/gcc-11.2.1-1.fc34.x86_64
> ..
> --23524--   .. build-id is valid
> --23524-- Reading syms from /usr/lib64/libm-2.33.so
> --23524--   Considering
> /usr/lib/debug/.build-id/c1/784bbe8a93a6e62f74b16105a2076a03b398ac.debug ..
> --23524--   .. build-id is valid
> --23524-- Reading syms from /usr/lib64/libgcc_s-11-20210728.so.1
> --23524--   Considering
> /usr/lib/debug/.build-id/46/e10c9ee769c5cfc7cdb638e3ccbc3169c0a949.debug ..
> --23524--   .. build-id is valid
> --23524--   Considering
> /usr/lib/debug/.build-id/46/../../../../../usr/lib/debug/lib64/../.dwz/gcc-11.2.1-1.fc34.x86_64
> ..
> --23524--   .. build-id is valid
> --23524-- Reading syms from /usr/lib64/libc-2.33.so
> --23524--   Considering
> /usr/lib/debug/.build-id/9d/e0f6e78ec16db4c6c167efc6b37466705edeff.debug ..
> --23524--   .. build-id is valid
> --23524--   Considering
> /usr/lib/debug/.build-id/9d/../../../../../usr/lib/debug/lib64/../.dwz/glibc-2.33-20.fc34.x86_64
> ..
> --23524--   .. build-id is valid
>
> What could be the problem? GGC 11 perhaps?
>
> Thanks!
>

[Valgrind-users] Very slow execution under Fedora 34

[Alvaro K. <ku...@gm...>]

Hello everyone!

I am running valgrind on my PC with dual boot Windows 10 and Fedora 34.

Running the same test on Ubuntu 20.04 (under Windows 10 WSL2) valgrind runs
in less than a second, but on Fedora 34 is very slow, several minutes slow.

On Fedora 34 it looks like the time spent is reading symbols.

This is the part that takes most of the time:

--23524-- Reading syms from /usr/lib64/libstdc++.so.6.0.29
--23524--   Considering
/usr/lib/debug/.build-id/bd/d633ff5da0bba64d19ecf277a9eed7001da127.debug ..
--23524--   .. build-id is valid
--23524--   Considering
/usr/lib/debug/.build-id/bd/../../../../../usr/lib/debug/usr/lib64/../../.dwz/gcc-11.2.1-1.fc34.x86_64
..
--23524--   .. build-id is valid
--23524-- Reading syms from /usr/lib64/libm-2.33.so
--23524--   Considering
/usr/lib/debug/.build-id/c1/784bbe8a93a6e62f74b16105a2076a03b398ac.debug ..
--23524--   .. build-id is valid
--23524-- Reading syms from /usr/lib64/libgcc_s-11-20210728.so.1
--23524--   Considering
/usr/lib/debug/.build-id/46/e10c9ee769c5cfc7cdb638e3ccbc3169c0a949.debug ..
--23524--   .. build-id is valid
--23524--   Considering
/usr/lib/debug/.build-id/46/../../../../../usr/lib/debug/lib64/../.dwz/gcc-11.2.1-1.fc34.x86_64
..
--23524--   .. build-id is valid
--23524-- Reading syms from /usr/lib64/libc-2.33.so
--23524--   Considering
/usr/lib/debug/.build-id/9d/e0f6e78ec16db4c6c167efc6b37466705edeff.debug ..
--23524--   .. build-id is valid
--23524--   Considering
/usr/lib/debug/.build-id/9d/../../../../../usr/lib/debug/lib64/../.dwz/glibc-2.33-20.fc34.x86_64
..
--23524--   .. build-id is valid

What could be the problem? GGC 11 perhaps?

Thanks!

Re: [Valgrind-users] Why valgrind can't see this error?

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

On 9/3/21 12:31 PM, Eric Chamberland wrote:
> Hi,
> 
> I have a simple test and valgrind seems to not see the error:
> 
> cat fread.cc && clang++ -o fread fread.cc && valgrind ./fread
> #include <iostream>
> #include <stdio.h>
> #include <stdlib.h>
> 
> int main(int argc, char ** argv){
>      int lA {1};
>      FILE * f = fopen ( argv[0] , "rb" );
>      fread(&lA,2*sizeof(int),1,f);
>      std::cout << "Hello: "<< lA << std::endl;
>      return 0;
> }

This report is interesting only because it is a bad example:
it does not specify what is the supposed error.
If you don't say what you believe it is, then how are valgrind developers to know?

Besides, the "memcheck error" is covered in the valgrind FAQ.
Look it up in paragraph "4.6.  Why doesn't Memcheck find ..."
The second and third errors are the logic errors of not checking
the return value of fopen and fread.
The fourth error is not documenting the expected invocation command line.
The fifth error is not checking argc.
The sixth error is not documenting the expected format of the input file.
Are you sure that you really are a programmer?

[Valgrind-users] Why valgrind can't see this error?

[Eric C. <Eri...@gi...>]

Hi,

I have a simple test and valgrind seems to not see the error:

cat fread.cc && clang++ -o fread fread.cc && valgrind ./fread
#include <iostream>
#include <stdio.h>
#include <stdlib.h>

int main(int argc, char ** argv){
     int lA {1};
     FILE * f = fopen ( argv[0] , "rb" );
     fread(&lA,2*sizeof(int),1,f);
     std::cout << "Hello: "<< lA << std::endl;
     return 0;
}
==16241== Memcheck, a memory error detector
==16241== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==16241== Using Valgrind-3.16.1 and LibVEX; rerun with -h for copyright info
==16241== Command: ./fread
==16241==
Hello: 1179403647
==16241==
==16241== HEAP SUMMARY:
==16241==     in use at exit: 472 bytes in 1 blocks
==16241==   total heap usage: 4 allocs, 3 frees, 78,296 bytes allocated
==16241==
==16241== LEAK SUMMARY:
==16241==    definitely lost: 0 bytes in 0 blocks
==16241==    indirectly lost: 0 bytes in 0 blocks
==16241==      possibly lost: 0 bytes in 0 blocks
==16241==    still reachable: 472 bytes in 1 blocks
==16241==         suppressed: 0 bytes in 0 blocks
==16241== Rerun with --leak-check=full to see details of leaked memory
==16241==
==16241== For lists of detected and suppressed errors, rerun with: -s
==16241== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

We just discovered this error that we got into our code since many 
years... and even if we use valgrind it didn't detected it...

Is there any command line options I can add to valgrind to make it 
detect the error?

Thanks,

Eric

-- 
Eric Chamberland, ing., M. Ing
Professionnel de recherche
GIREF/Université Laval
(418) 656-2131 poste 41 22 42

Re: [Valgrind-users] Valgrind terminates at AVX instruction with "unrecognised instruction"

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

> I'm using Valgrind 3-13-0 on Ubuntu 18.04.  The package repository has 3-13-0 as its latest version, so if I want 3-17-0 I will need to install from source.  But my question is about AVX instructions that have been supported since before 3-13-0.

Copy+Paste the entire error message here, including the dump of the actual hex instruction bytes.
(You may hide the names of your files, if you wish.)

[Valgrind-users] Valgrind terminates at AVX instruction with "unrecognised instruction"

[Mark <mr...@pr...>]

Hello,

I'm using Valgrind 3-13-0 on Ubuntu 18.04. The package repository has 3-13-0 as its latest version, so if I want 3-17-0 I will need to install from source. But my question is about AVX instructions that have been supported since before 3-13-0.

I ran the following command format:

valgrind --tool=memcheck ./(Program_name).exe

I ran this command on three separate programs, all of which have AVX instructions. In all three cases Valgrind terminated at the first line that contained an AVX instruction with "Unrecognised instruction."

According https://stackoverflow.com/questions/31009094/valgrind-illegal-instruction-avx, support for AVX was added in 3.8.0 and for AVX2 in 3.9.0. Two of the instructions in question are AVX instructions:

vmovupd xmm31,[const_1.962].
This is an AVX instruction, see https://www.felixcloutier.com/x86/movupd, where VMOVUPD xmm1, xmm2/m128 is listed as an AVX instruction.

vaddsd xmm20,xmm0,xmm1
This is also an AVX instruction, see https://www.felixcloutier.com/x86/addsd. The three operand form (without masks) is AVX. VADDSD xmm1, xmm2, xmm3/m64 (AVX)

Why does Valgrind terminate at those AVX instructions when support was added before 3-13-0?

Thanks very much.

Re: [Valgrind-users] Helgrind causing data race warning in mutex_destroy_WRK?

[Schmidt, A. <adr...@si...>]

> >
> > To me it seems that Helgrind itself is causing the warning when
> > calculating mutex_is_init (hg_intercepts.c:859).
> 
> Isn't this rather a race between unlocking a mutex and destroying that mutex?

I'm not sure... I know it's not a very strong argument, but the Poco::Timer code is not that complex, and I could not find anything wrong with it.

What puzzles me is that the location Helgrind reports is "inside" the mutex object itself. Is it even possible to create a race on the memory location of a mutex, when only accessing it through the pthread_mutex_* API?

Re: [Valgrind-users] Helgrind causing data race warning in mutex_destroy_WRK?

[David F. <fa...@kd...>]

On mardi 17 août 2021 09:59:23 CEST Schmidt, Adriaan wrote:
> Hi.
> 
> Running Helgrind (Valgrind 3.17.0) on arm32 (Linux 4.14.139), glibc 2.31,
> and an application using Poco 1.10.1, I see the following:
> 
> ==17922== Possible data race during read of size 1 at 0x64BD4C4 by thread
> #97 ==17922== Locks held: 1, at address 0x1C134CC
> ==17922==    at 0x48536D8: my_memcmp (hg_intercepts.c:220)
> ==17922==    by 0x4853BBF: mutex_destroy_WRK (hg_intercepts.c:859)
> ==17922==    by 0x48572F7: pthread_mutex_destroy (hg_intercepts.c:882)
> ==17922==    by 0x5705F23: Poco::EventImpl::~EventImpl()
> (Event_POSIX.cpp:96) ==17922==    by 0x5706393: Poco::Event::~Event()
> (Event.cpp:40)
> ==17922==    by 0x578099B: Poco::Timer::~Timer() (Timer.cpp:34)
> ==17922==    by 0x5470827: Poco::Data::SessionPool::~SessionPool()
> (SessionPool.cpp:40) ==17922==    by 0x54708A7:
> Poco::Data::SessionPool::~SessionPool() (SessionPool.cpp:50) ==.....==    [
> ... ]
> ==17922==
> ==17922== This conflicts with a previous write of size 4 by thread #7
> ==17922== Locks held: none
> ==17922==    at 0x57F8998: __pthread_mutex_unlock_usercnt
> (pthread_mutex_unlock.c:52) ==17922==    by 0x4854273: mutex_unlock_WRK
> (hg_intercepts.c:1106) ==17922==    by 0x4857337: pthread_mutex_unlock
> (hg_intercepts.c:1124) ==17922==    by 0x5781153: setImpl
> (Event_POSIX.h:61)
> ==17922==    by 0x5781153: set (Event.h:101)
> ==17922==    by 0x5781153: Poco::Timer::run() (Timer.cpp:216)
> ==17922==    by 0x577ACAF: Poco::PooledThread::run() (ThreadPool.cpp:199)
> ==17922==    by 0x57765B3: Poco::ThreadImpl::runnableEntry(void*)
> (Thread_POSIX.cpp:345) ==17922==    by 0x48562FF: mythread_wrapper
> (hg_intercepts.c:398)
> ==17922==    by 0x57F4143: start_thread (pthread_create.c:477)
> 
> To me it seems that Helgrind itself is causing the warning when calculating
> mutex_is_init (hg_intercepts.c:859).

Isn't this rather a race between unlocking a mutex and destroying that mutex?

-- 
David Faure, fa...@kd..., http://www.davidfaure.fr
Working on KDE Frameworks 5

[Valgrind-users] Helgrind causing data race warning in mutex_destroy_WRK?

[Schmidt, A. <adr...@si...>]

Hi.

Running Helgrind (Valgrind 3.17.0) on arm32 (Linux 4.14.139), glibc 2.31, and an application using Poco 1.10.1, I see the following:

==17922== Possible data race during read of size 1 at 0x64BD4C4 by thread #97
==17922== Locks held: 1, at address 0x1C134CC
==17922==    at 0x48536D8: my_memcmp (hg_intercepts.c:220)
==17922==    by 0x4853BBF: mutex_destroy_WRK (hg_intercepts.c:859)
==17922==    by 0x48572F7: pthread_mutex_destroy (hg_intercepts.c:882)
==17922==    by 0x5705F23: Poco::EventImpl::~EventImpl() (Event_POSIX.cpp:96)
==17922==    by 0x5706393: Poco::Event::~Event() (Event.cpp:40)
==17922==    by 0x578099B: Poco::Timer::~Timer() (Timer.cpp:34)
==17922==    by 0x5470827: Poco::Data::SessionPool::~SessionPool() (SessionPool.cpp:40)
==17922==    by 0x54708A7: Poco::Data::SessionPool::~SessionPool() (SessionPool.cpp:50)
==.....==    [ ... ]
==17922== 
==17922== This conflicts with a previous write of size 4 by thread #7
==17922== Locks held: none
==17922==    at 0x57F8998: __pthread_mutex_unlock_usercnt (pthread_mutex_unlock.c:52)
==17922==    by 0x4854273: mutex_unlock_WRK (hg_intercepts.c:1106)
==17922==    by 0x4857337: pthread_mutex_unlock (hg_intercepts.c:1124)
==17922==    by 0x5781153: setImpl (Event_POSIX.h:61)
==17922==    by 0x5781153: set (Event.h:101)
==17922==    by 0x5781153: Poco::Timer::run() (Timer.cpp:216)
==17922==    by 0x577ACAF: Poco::PooledThread::run() (ThreadPool.cpp:199)
==17922==    by 0x57765B3: Poco::ThreadImpl::runnableEntry(void*) (Thread_POSIX.cpp:345)
==17922==    by 0x48562FF: mythread_wrapper (hg_intercepts.c:398)
==17922==    by 0x57F4143: start_thread (pthread_create.c:477)

To me it seems that Helgrind itself is causing the warning when calculating mutex_is_init (hg_intercepts.c:859).

The conflicting access is a write to the field __data.__owner of the mutex (https://elixir.bootlin.com/glibc/glibc-2.31/source/nptl/pthread_mutex_unlock.c#L52).

Any ideas what could be going on here?

Thanks,
Adriaan

[Valgrind-users] Fwd: No "by" message in memcheck output

[Michael O. <mto...@gm...>]

---------- Forwarded message ---------
From: Michael Ortiz <mto...@gm...>
Date: Tue, Jul 13, 2021 at 3:52 PM
Subject: Re: [Valgrind-users] No "by" message in memcheck output
To: Paul FLOYD <pj...@wa...>


I found a resolution to this issue here:
http://arago-project.org/pipermail/meta-arago/2015-August/006016.html

The resolution is to include the debug symbols
for vgpreload_memcheck-arm-linux.so. After doing so the callstack is
reported in the memcheck output:

==8828== Thread 1:
==8828== 5 bytes in 1 blocks are definitely lost in loss record 1 of 1
==8828==    at 0x4845BD4: malloc (vg_replace_malloc.c:309)
==8828==    by 0x73D6B: main (example.cpp:158)

Cheers,
Mike


On Tue, Jul 13, 2021 at 2:01 PM Michael Ortiz <mto...@gm...>
wrote:

> Thanks for the reply,
>
> I set the malloc breakpoint in gdb per your suggestion and the
> callstack shows that the offending call is in main:
>
> Breakpoint 15, 0x00072760 in malloc@plt ()
> (gdb) where
> #0  0x00072760 in malloc@plt ()
> #1  0x00073d6c in main (argc=<optimized out>, argv=<optimized out>) at
> /home/mortiz/test/example.cpp:158
>
> As you noted, I am running on armv7l. I wonder if the callstack output is
> not supported in the "HEAP SUMMARY" for this architecture.
>
> For reference, I am using valgrind provided by yocto zeus (3.0.3).
>
> Mike
>
> On Tue, Jul 13, 2021 at 12:53 AM Paul FLOYD <pj...@wa...> wrote:
>
>>
>> > De : "Michael Ortiz"
>> > Objet : [Valgrind-users] No "by" message in memcheck output
>>
>>
>> Hi
>>
>> It's possible that the call to malloc is before the start of main
>> (either from your libc or for the initialization of some static or global
>> object).
>> I know next to nothing about the ARM ABI, but on amd64 Linux
>> the callstack in this case contains things like
>>
>> ==1441== 4 bytes in 1 blocks are still reachable in loss record 1 of 2
>> ==1441== at 0x402DF66: operator new(unsigned long)
>> (vg_replace_malloc.c:417)
>> ==1441== by 0x401187: __static_initialization_and_destruction_0(int, int)
>> (source.cpp:1)
>> ==1441== by 0x4011A4: _GLOBAL__sub_I_pi (l.cpp:3)
>> ==1441== by 0x4011FC: __libc_csu_init (in /home/user/exe)
>> ==1441== by 0x4D48364: (below main) (in /usr/lib64/libc-2.17.so)
>>
>> Can you run your app under gdb, but a break on malloc and then run.
>> You should be able to see the callstack and then be able to tell if
>> Valgrind is telling you the right thing or not.
>>
>> A+
>> Paul
>>
>>
>> _______________________________________________
>> Valgrind-users mailing list
>> Val...@li...
>> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>>
>

Re: [Valgrind-users] No "by" message in memcheck output

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

> De : "Michael Ortiz" 
> Objet : [Valgrind-users] No "by" message in memcheck output


Hi

It's possible that the call to malloc is before the start of main
(either from your libc or for the initialization of some static or global object).
I know next to nothing about the ARM ABI, but on amd64 Linux
the callstack in this case contains things like

==1441== 4 bytes in 1 blocks are still reachable in loss record 1 of 2
==1441== at 0x402DF66: operator new(unsigned long) (vg_replace_malloc.c:417)
==1441== by 0x401187: __static_initialization_and_destruction_0(int, int) (source.cpp:1)
==1441== by 0x4011A4: _GLOBAL__sub_I_pi (l.cpp:3)
==1441== by 0x4011FC: __libc_csu_init (in /home/user/exe)
==1441== by 0x4D48364: (below main) (in /usr/lib64/libc-2.17.so)

Can you run your app under gdb, but a break on malloc and then run.
You should be able to see the callstack and then be able to tell if
Valgrind is telling you the right thing or not.

A+
Paul

[Valgrind-users] No "by" message in memcheck output

[Michael O. <mto...@gm...>]

Hi,

I'm running valgrind version 3.15.

When I run the following:

valgrind --tool=memcheck --leak-check=yes <path to executable>

I get the following output:

==13501== HEAP SUMMARY:
==13501==     in use at exit: 5 bytes in 1 blocks
==13501==   total heap usage: 137,210 allocs, 137,209 frees, 4,188,260
bytes allocated
==13501==
==13501== Thread 1:
==13501== 5 bytes in 1 blocks are definitely lost in loss record 1 of 1
==13501==    at 0x4845BD4: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-arm-linux.so)

Notice, there is no "by" message indicating where the allocation occurred.
For example, I expected something like this:

==13501==    by 0x804840F: main (example.c:5)

directly following the "at" message, but it's not there. I have debug
symbols preserved in my executable.

Was this behavior (i.e. "by" output) added in some later version?

Thank you,
Mike

Re: [Valgrind-users] Problem with valgrind-3.17.0 and openmpi-4.0.5

[TESSER F. <fed...@po...>]

I have tried valgrind 3.17.0 and openmpi 4.0.2, and it 
works.

Do you know if there are some reported bugs with that 
specific
version?

Regards,

Federico Tesser



On Wed, 07 Jul 2021 10:25:52 +0200
  "TESSER FEDERICO" <fed...@po...> wrote:
> Good morning.
> 
> I have installed valgrind 3.17.0, having previously 
>loaded the
> module for openmpi 4.0.5, so it found the 
>"MPI2-compliant mpicc
> and mpi.h...".
> 
> However, trying to run just a simple program like this 
>one:
> 
> 
> 
> #include <mpi.h>
> #include <stdio.h>
> 
> int main(int argc, char** argv) {
> 
> MPI_Init(NULL, NULL);
> 
> int world_size;
> int world_rank;
> int name_len;
> char processor_name[MPI_MAX_PROCESSOR_NAME];
> 
> MPI_Comm_size(MPI_COMM_WORLD, &world_size);
> MPI_Comm_rank(MPI_COMM_WORLD, &world_rank);
> MPI_Get_processor_name(processor_name, &name_len);
> 
> printf("Hello world from processor %s, rank %d out of %d 
>processors\n",
> 	   processor_name, world_rank, world_size);
> 
> MPI_Finalize();
> 
> }
> 
> 
> 
> will produce the following errors:
> 
> 
> 
> ==113228== Memcheck, a memory error detector
> ==113228== Copyright (C) 2002-2017, and GNU GPL'd, by 
>Julian Seward et al.
> ==113228== Using Valgrind-3.17.0 and LibVEX; rerun with 
>-h for copyright info
> ==113228== Command: ./pure_mpi_valgrind_try/a.out
> ==113228==
> valgrind MPI wrappers 113228: Active for pid 113228
> valgrind MPI wrappers 113228: Try MPIWRAP_DEBUG=help for 
>possible options
> vex amd64->IR: unhandled instruction bytes: 0x62 0xF2 
>0x7D 0x8 0x7C 0xC5 0xC5 0xF9 0xD6 0x43
> 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=NONE
> vex amd64->IR:   PFX.66=0 PFX.F2=0 PFX.F3=0
> ==113228== valgrind: Unrecognised instruction at address 
>0x5c79318.
> ==113228==    at 0x5C79318: opal_pointer_array_init (in 
>/usr/local/openmpi-4.0.5/lib/libopen-pal.so.40.20.5)
> ==113228==    by 0x5CA4BDB: mca_base_var_init (in 
>/usr/local/openmpi-4.0.5/lib/libopen-pal.so.40.20.5)
> ==113228==    by 0x5C82F11: opal_init_util (in 
>/usr/local/openmpi-4.0.5/lib/libopen-pal.so.40.20.5)
> ==113228==    by 0x5157FD9: ompi_mpi_init 
>(ompi_mpi_init.c:428)
> ==113228==    by 0x50FB3A8: PMPI_Init (pinit.c:69)
> ==113228==    by 0x4E4BC26: PMPI_Init 
>(libmpiwrap.c:2288)
> ==113228==    by 0x10893B: main (main.c:6)
> ==113228== Your program just tried to execute an 
>instruction that Valgrind
> ==113228== did not recognise.  There are two possible 
>reasons for this.
> ==113228== 1. Your program has a bug and erroneously 
>jumped to a non-code
> ==113228==    location.  If you are running Memcheck and 
>you just saw a
> ==113228==    warning about a bad jump, it's probably 
>your program's fault.
> ==113228== 2. The instruction is legitimate but Valgrind 
>doesn't handle it,
> ==113228==    i.e. it's Valgrind's fault.  If you think 
>this is the case or
> ==113228==    you are not sure, please let us know and 
>we'll try to fix it.
> ==113228== Either way, Valgrind will now raise a SIGILL 
>signal which will
> ==113228== probably kill your program.
> ==113228==
> ==113228== Process terminating with default action of 
>signal 4 (SIGILL): dumping core
> ==113228==  Illegal opcode at address 0x5C79318
> ==113228==    at 0x5C79318: opal_pointer_array_init (in 
>/usr/local/openmpi-4.0.5/lib/libopen-pal.so.40.20.5)
> ==113228==    by 0x5CA4BDB: mca_base_var_init (in 
>/usr/local/openmpi-4.0.5/lib/libopen-pal.so.40.20.5)
> ==113228==    by 0x5C82F11: opal_init_util (in 
>/usr/local/openmpi-4.0.5/lib/libopen-pal.so.40.20.5)
> ==113228==    by 0x5157FD9: ompi_mpi_init 
>(ompi_mpi_init.c:428)
> ==113228==    by 0x50FB3A8: PMPI_Init (pinit.c:69)
> ==113228==    by 0x4E4BC26: PMPI_Init 
>(libmpiwrap.c:2288)
> ==113228==    by 0x10893B: main (main.c:6)
> slurmstepd: error: *** JOB 159641 ON node01 CANCELLED AT 
>2021-07-07T10:21:29 ***
> srun: Job step aborted: Waiting up to 32 seconds for job 
>step to finish.
> srun: error: Timed out waiting for job step to complete
> slurmstepd: error: *** STEP 159641.0 ON node01 CANCELLED 
>AT 2021-07-07T10:22:48 ***
> 
> 
> 
> What am I doing wrong?
> 
> Regards,
> 
>Federico Tesser

[Valgrind-users] Problem with valgrind-3.17.0 and openmpi-4.0.5

[TESSER F. <fed...@po...>]

Good morning.

I have installed valgrind 3.17.0, having previously loaded 
the
module for openmpi 4.0.5, so it found the "MPI2-compliant 
mpicc
and mpi.h...".

However, trying to run just a simple program like this 
one:



#include <mpi.h>
#include <stdio.h>

int main(int argc, char** argv) {

MPI_Init(NULL, NULL);

int world_size;
int world_rank;
int name_len;
char processor_name[MPI_MAX_PROCESSOR_NAME];

MPI_Comm_size(MPI_COMM_WORLD, &world_size);
MPI_Comm_rank(MPI_COMM_WORLD, &world_rank);
MPI_Get_processor_name(processor_name, &name_len);

printf("Hello world from processor %s, rank %d out of %d 
processors\n",
	   processor_name, world_rank, world_size);

MPI_Finalize();

}



will produce the following errors:



==113228== Memcheck, a memory error detector
==113228== Copyright (C) 2002-2017, and GNU GPL'd, by 
Julian Seward et al.
==113228== Using Valgrind-3.17.0 and LibVEX; rerun with -h 
for copyright info
==113228== Command: ./pure_mpi_valgrind_try/a.out
==113228==
valgrind MPI wrappers 113228: Active for pid 113228
valgrind MPI wrappers 113228: Try MPIWRAP_DEBUG=help for 
possible options
vex amd64->IR: unhandled instruction bytes: 0x62 0xF2 0x7D 
0x8 0x7C 0xC5 0xC5 0xF9 0xD6 0x43
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=NONE
vex amd64->IR:   PFX.66=0 PFX.F2=0 PFX.F3=0
==113228== valgrind: Unrecognised instruction at address 
0x5c79318.
==113228==    at 0x5C79318: opal_pointer_array_init (in 
/usr/local/openmpi-4.0.5/lib/libopen-pal.so.40.20.5)
==113228==    by 0x5CA4BDB: mca_base_var_init (in 
/usr/local/openmpi-4.0.5/lib/libopen-pal.so.40.20.5)
==113228==    by 0x5C82F11: opal_init_util (in 
/usr/local/openmpi-4.0.5/lib/libopen-pal.so.40.20.5)
==113228==    by 0x5157FD9: ompi_mpi_init 
(ompi_mpi_init.c:428)
==113228==    by 0x50FB3A8: PMPI_Init (pinit.c:69)
==113228==    by 0x4E4BC26: PMPI_Init (libmpiwrap.c:2288)
==113228==    by 0x10893B: main (main.c:6)
==113228== Your program just tried to execute an 
instruction that Valgrind
==113228== did not recognise.  There are two possible 
reasons for this.
==113228== 1. Your program has a bug and erroneously 
jumped to a non-code
==113228==    location.  If you are running Memcheck and 
you just saw a
==113228==    warning about a bad jump, it's probably your 
program's fault.
==113228== 2. The instruction is legitimate but Valgrind 
doesn't handle it,
==113228==    i.e. it's Valgrind's fault.  If you think 
this is the case or
==113228==    you are not sure, please let us know and 
we'll try to fix it.
==113228== Either way, Valgrind will now raise a SIGILL 
signal which will
==113228== probably kill your program.
==113228==
==113228== Process terminating with default action of 
signal 4 (SIGILL): dumping core
==113228==  Illegal opcode at address 0x5C79318
==113228==    at 0x5C79318: opal_pointer_array_init (in 
/usr/local/openmpi-4.0.5/lib/libopen-pal.so.40.20.5)
==113228==    by 0x5CA4BDB: mca_base_var_init (in 
/usr/local/openmpi-4.0.5/lib/libopen-pal.so.40.20.5)
==113228==    by 0x5C82F11: opal_init_util (in 
/usr/local/openmpi-4.0.5/lib/libopen-pal.so.40.20.5)
==113228==    by 0x5157FD9: ompi_mpi_init 
(ompi_mpi_init.c:428)
==113228==    by 0x50FB3A8: PMPI_Init (pinit.c:69)
==113228==    by 0x4E4BC26: PMPI_Init (libmpiwrap.c:2288)
==113228==    by 0x10893B: main (main.c:6)
slurmstepd: error: *** JOB 159641 ON node01 CANCELLED AT 
2021-07-07T10:21:29 ***
srun: Job step aborted: Waiting up to 32 seconds for job 
step to finish.
srun: error: Timed out waiting for job step to complete
slurmstepd: error: *** STEP 159641.0 ON node01 CANCELLED 
AT 2021-07-07T10:22:48 ***



What am I doing wrong?

Regards,

Federico Tesser

Re: [Valgrind-users] No used_suppression in verbose memcheck output

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

If you use xml output, the used suppressions are only output when
you give the option --show-error-list=yes.

With xml, increasing the verbosity will not show the used suppressions.
Likewise, when xml output is selected, no ERROR SUMMARY is output
(and probably some other textual output is similarly not produced in xml).

The idea is that xml output is used by front end applications that will
use the relevant options (such as --show-error-list=yes) to select
what to show.

Of course, other choices of when to output what would be possible.
The current state is like it is partially based on history.

For more details of what is output for errors, summary and used suppressions,
you can look at the function VG_(show_all_errors) in file m_errormgr.c

Philippe



On Tue, 2021-06-29 at 16:20 +0000, Mallove, EthanX A wrote:
> Hello,
>  
> I’ve intentionally created a memory leak in my application by adding a malloc() without a corresponding free(), but it seems to be suppressed by this block of my .supp file:
>  
> {
>     libc-2
>     Memcheck:Leak
>     ...
>     obj:*/libc-2.17.so
> }
>  
> When I remove the above from my suppression file, I see the <error> leak in the output XML.
>  
> But when the libc suppression is active, why isn’t there a “used_suppression” line in the -v output?
>  
> Thank you,
> Ethan
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users