valgrind-users — General discussion list for Valgrind users

Re: [Valgrind-users] Suspect "uninitialised value(s)" error

[Karl R. <kro...@zo...>]

I've narrowed down the struct member offset error that Valgrind seems to be 
making.  Uninitialised value errors are being reported for two float members 
with offsets of 36 & 48 bytes into the 72 byte DrawState struct.   Using memset 
to clear just 4 bytes at offset 104 in the ListDrawState causes the error for 
the member at offset 36 to go away.

So before adding the memset the memory at offset 104 is in fact uninitialized.  
The problem is that the actual initialized member used is 68 bytes before that 
at offset 36.


-Karl

[Valgrind-users] Suspect "uninitialised value(s)" error

[Karl R. <kro...@zo...>]

I'm getting the following error on struct members which should absolutely be 
initialized:
  Conditional jump or move depends on uninitialised value(s)

To begin investigating I did a memset of zero on the entire struct and the 
error goes away.  Now this C++ struct inherits another one and the error is 
reported in C code expecting the base struct.  If I only memset the base 
struct the error is still reported, which should be impossible.

Code summary of the weirdness:

    struct ListDrawState : public DrawState { ... };
    extern "C" void draw_func(DrawState*);

    ListDrawState ds;
    memset(&ds, 0, sizeof(DrawState));  // Error in draw_func()
    //memset(&ds, 0, sizeof(ListDrawState));  // No error in draw_func()
    draw_func(&ds);
 
Here's what I'm using to compile and test:
    gcc (GCC) 12.2.1 20221121 (Red Hat 12.2.1-4)
    valgrind-3.21.0

I've tried to re-create the problem in a stand-alone test, but the error 
doesn't happen there.  If someone wants to look at the actual code I can 
provide a GitHub URL.

-Karl

Re: [Valgrind-users] valgrind usage in arm board

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

On 9/28/23 20:55, ramakanth varala wrote:
> I gathered all info at this place https://pastebin.com/1sekb62v <https://pastebin.com/1sekb62v>

Looking at the previous messages of the thread in [Valgrind-users] mailing list,
I don't see any information about the context in which you are working.
Specifically:
   Which version of valgrind ?  (Run "valgrind --version".)
   Which hardware?
   Which operating system and version?
   Which Linux distribution and software [cross-]development environment?
   Which compiler and version, and which C run-time library and version?

Some of that info is *required* in order to help you,
and all of it makes it much easier for maintainers
to understand what the problem might be.

 From the pastebin posting it apears that you are running Linux
on a 32-bit ARM system which uses /lib/ld-linux.so.3 as the
run-time dynamic linker.  But which version of the development
environment, compiler, and run-time C library?  Yes, it might
really matter.  Bottom line: give enough information so that
a maintainer can reproduce the problem that you see.

Getting down to specifics:
> $ readelf --use-dynamic --symbols ./lib/ld-linux.so.3  > /home/labuser/rk/symbols-2.txt
The use of "./lib/ld-linux.so.3" instead of "/lib/ld-linux.so.3"
[the difference is a leading dot '.' or not] triggers alarm bells.
You must be *ABSOLUTELY CERTAIN* that those two files have
identical contents.  Particularly with "cross-system" environments,
it is trivially easy for them to differ inadvertently or on purpose.
Run both 'cmp' and 'sha256sum' to be sure that the contents are the same.
If the contents are not the same, then you must start over from the beginning.

Using a text editor on the contents of the pastebin posting:
=====
:g/index$/p
    857: 0001a300   204 FUNC    LOCAL  DEFAULT   10 index

:g/index$/?Symbol table?p
Symbol table '.symtab' contains 988 entries:

:g/index$/?$ cat?p
$ cat /home/labuser/rk/symbols-1.txt
=====
Therefore the symbol 'index' does exist in the link-time symbols-1.txt,
but not in the run-time symbol table symbols-2.txt.  So if the real
/lib/ld-linux.so.3 has been stripped in order to save space, then
'index' will disappear, and valgrind will not be able to find it.

=====
:g/strchr$/p
    933: 0001a300   204 FUNC    LOCAL  DEFAULT   10 strchr

:g/strchr$/?Symbol table?p
Symbol table '.symtab' contains 988 entries:

:g/strchr$/?$ cat?p
$ cat /home/labuser/rk/symbols-1.txt
=====
Therefore 'strchr' is a synonym for 'index', having the same value
0x0001a300 and the same properties, but a different name, and a
different position in the link-time symbol table.

Overall conclusion: you have found a bug in valgrind,
namely 'index' is optional, and not required as demanded by valgrind.
(Which version of valgrind?  :-) )
Please file a bug report, following the directions at
    https://valgrind.org/support/bug_reports.html
You will need to supply all the version info of the various pieces,
and the analysis of which symbols really are present, and _where_.

Re: [Valgrind-users] valgrind usage in arm board

[ramakanth v. <ram...@gm...>]

Hi John,

Thanks for the pointers,

I gathered all info at this place https://pastebin.com/1sekb62v

Not very familiar on the valgrind with cross compiled binaries.

Still analysis going on .

Thanks
vlrk

On Wed, Sep 27, 2023 at 10:14 PM John Reiser <jr...@bi...> wrote:

> On 9/26/23 23:15, ramakanth varala wrote:
> > valgrind:  A must-be-redirected function
> > valgrind:  whose name matches the pattern:      index
> > valgrind:  in an object with soname matching:   ld-linux.so.3
> > *valgrind:  was not found whilst processing*
> > *valgrind:  symbols from the object with soname: ld-linux.so.3*
>
> 'index' is identical to 'strchr'.  (Run "man 3 index" to see
> documentation.)
> It might be that the source code for your ld-linux.so has been scoured,
> replacing all calls of 'index(' with calls to 'strchr(' instead.
> If so, then 'index' will not appear in the symbol table,
> and valgrind will have a bug, because: 'index' should be optional.
>
> Please run your app under 'strace':
>      strace -f -o strace.out -e trace=file ./my_app args...
> and look in file strace.out for two kinds of info:
> any line containing "ENOENT" (file not found)
> and any line containing "ld-linux" (part of the actual path used
> for the run-time dynamic linker.)
> Make sure that what you see makes sense.
> Also run "readelf --segments ./my_app" and look for the PT_INTERP.
>
> After discovering the actual path that was used for ld-linux,
> then run "readelf --symbols /path/to/ld-linux  > symbols-1.txt"
> and "readelf --use-dynamic --symbols /path/to/ld-linux  > symbols-2.txt" .
> Then look in both symbols-[12].txt files to see about 'index' AND 'strchr'.
>
>
>
>
>
>
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>

Re: [Valgrind-users] valgrind usage in arm board

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

On 9/26/23 23:15, ramakanth varala wrote:
> valgrind:  A must-be-redirected function
> valgrind:  whose name matches the pattern:      index
> valgrind:  in an object with soname matching:   ld-linux.so.3
> *valgrind:  was not found whilst processing*
> *valgrind:  symbols from the object with soname: ld-linux.so.3*

'index' is identical to 'strchr'.  (Run "man 3 index" to see documentation.)
It might be that the source code for your ld-linux.so has been scoured,
replacing all calls of 'index(' with calls to 'strchr(' instead.
If so, then 'index' will not appear in the symbol table,
and valgrind will have a bug, because: 'index' should be optional.

Please run your app under 'strace':
     strace -f -o strace.out -e trace=file ./my_app args...
and look in file strace.out for two kinds of info:
any line containing "ENOENT" (file not found)
and any line containing "ld-linux" (part of the actual path used
for the run-time dynamic linker.)
Make sure that what you see makes sense.
Also run "readelf --segments ./my_app" and look for the PT_INTERP.

After discovering the actual path that was used for ld-linux,
then run "readelf --symbols /path/to/ld-linux  > symbols-1.txt"
and "readelf --use-dynamic --symbols /path/to/ld-linux  > symbols-2.txt" .
Then look in both symbols-[12].txt files to see about 'index' AND 'strchr'.

Re: [Valgrind-users] valgrind usage in arm board

[ramakanth v. <ram...@gm...>]

Hi Paul,

Thanks a lot for reply and inputs.

As said for some it works fine .

In my target board we have busybox binary , this works very fine with
valgrind.

I mean if "ld-linux.so.3 needs to have symbols" ,does this mean busy box
does not use this linker / loader?.

Where as for others it gives error as shown before?.

when I do readelf -S /lib/ld-linux.so.3 , it shows

  [21] .debug_aranges    PROGBITS        00000000 0218f0 0000a0 00      0
0  8
  [22] .debug_info       PROGBITS        00000000 021990 000a81 00      0
0  1
  [23] .debug_abbrev     PROGBITS        00000000 022411 0001b2 00      0
0  1
  [24] .debug_line       PROGBITS        00000000 0225c3 00037f 00      0
0  1
  [25] .debug_frame      PROGBITS        00000000 022944 000608 00      0
0  4
  [26] .debug_str        PROGBITS        00000000 022f4c 0011cf 01  MS  0
0  1
  [27] .debug_loc        PROGBITS        00000000 02411b 0002fb 00      0
0  1

Will this confirm like it has debugging symbols.

You are inputs are very helpful.

Thanks
vlrk




On Wed, Sep 27, 2023 at 1:17 PM Paul Floyd <pj...@wa...> wrote:

>
> On 27/09/2023 08:15, ramakanth varala wrote:
>
>
>
> Not sure enough , what exactly missing , Any inputs in this will be highly
> appreciated.
>
> *valgrind:  symbols from the object with soname: ld-linux.so.3*
>
> Valgrind is looking for symbols in ldrt, the runtime link loader.
>
> Either ld-linux.so.3 needs to have symbols or there needs to be a separate
> debuginfo file.
>
> If the debuginfo is in a non-standard location try
> --extra-debuginfo-path=path and perhaps also
> --allow-mismatched-debuginfo=yes
>
> A+
>
> Paul
>
>

[Valgrind-users] valgrind usage in arm board

[ramakanth v. <ram...@gm...>]

Hi Team,

We are using arm board of i686 arch .

I got valgrind cross compiled using the arm toolchain of i386 ( vendor
given).

We observe for two of the packages could able to run with valgrind .

where as with others I get below error .

valgrind:  Fatal error at startup: a function redirection
valgrind:  which is mandatory for this platform-tool combination
valgrind:  cannot be set up.  Details of the redirection are:
valgrind:
valgrind:  A must-be-redirected function
valgrind:  whose name matches the pattern:      index
valgrind:  in an object with soname matching:   ld-linux.so.3
*valgrind:  was not found whilst processing*
*valgrind:  symbols from the object with soname: ld-linux.so.3*
valgrind:
valgrind:  Possible fixes: (1, short term): install glibc's debuginfo
valgrind:  package on this machine.  (2, longer term): ask the packagers
valgrind:  for your Linux distribution to please in future ship a non-
valgrind:  stripped ld.so (or whatever the dynamic linker .so is called)
valgrind:  that exports the above-named function using the standard
valgrind:  calling conventions for this platform.  The package you need
valgrind:  to install for fix (1) is called
valgrind:
*valgrind:    On Debian, Ubuntu:                 libc6-dbg*
*valgrind:    On SuSE, openSuSE, Fedora, RHEL:   glibc-debuginfo*
*valgrind:*
valgrind:  Note that if you are debugging a 32 bit process on a
valgrind:  64 bit system, you will need a corresponding 32 bit debuginfo
valgrind:  package (e.g. libc6-dbg:i386).
valgrind:
valgrind:  Cannot continue -- exiting now.  Sorry.


In above I see like when I do readelf -S ./lib/libc.so.6

 [63] .debug_aranges    PROGBITS        00000000 131558 000240 00      0
0  8
  [64] .debug_info       PROGBITS        00000000 131798 001571 00      0
0  1
  [65] .debug_abbrev     PROGBITS        00000000 132d09 0003dd 00      0
0  1
  [66] .debug_line       PROGBITS        00000000 1330e6 000e17 00      0
0  1
  [67] .debug_frame      PROGBITS        00000000 133f00 002608 00      0
0  4
  [68] .debug_str        PROGBITS        00000000 136508 0012f8 01  MS  0
0  1
  [69] .debug_loc        PROGBITS        00000000 137800 00039b 00      0
0  1

I belive debug symbols are present

Not sure enough , what exactly missing , Any inputs in this will be highly
appreciated.

Thanks
vlrk

Re: [Valgrind-users] how to proceed when faced with malloc error

[Julian S. <jse...@gm...>]

This generally happens when memory errors in the application under test
(here, "btserver") are so bad they wind up trashing Valgrind's storage
too.  If Valgrind has reported memory errors prior to this point, try
fixing them first.

J

> --19817-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - 
> exiting
> --19817-- si_code=128;  Faulting address: 0x0;  sp: 0x100993be30
> 
> valgrind: the 'impossible' happened:
>     Killed by fatal signal
> 
> host stacktrace:
> ==19817==    at 0x580492FF: get_bszB_as_is (m_mallocfree.c:302)
> ==19817==    by 0x580492FF: get_bszB (m_mallocfree.c:314)
> ==19817==    by 0x580492FF: vgPlain_arena_malloc (m_mallocfree.c:1819)
> ==19817==    by 0x58004D74: vgMemCheck_new_block (mc_malloc_wrappers.c:370)
> ==19817==    by 0x58004F99: vgMemCheck___builtin_new (mc_malloc_wrappers.c:415)
> ==19817==    by 0x58093FD5: do_client_request (scheduler.c:1979)
> ==19817==    by 0x58093FD5: vgPlain_scheduler (scheduler.c:1542)
> ==19817==    by 0x580DA8DA: thread_wrapper (syswrap-linux.c:102)
> ==19817==    by 0x580DA8DA: run_a_thread_NORETURN (syswrap-linux.c:155)
> 
> sched status:
>    running_tid=1
> 
> Thread 1: status = VgTs_Runnable (lwpid 19817)
> ==19817==    at 0x4841EF1: operator new(unsigned long) (vg_replace_malloc.c:472)
> ==19817==    by 0x60FFB3: Card::checkNewPort(LFInfo&, String const&, char 
> const*, bool, char const*, bool&, bool&, unsigned int) (Card.cc:7510)
> ==19817==    by 0x611337: Card::discoverDevices(LFInfo&, char const*, bool) 
> (Card.cc:8205)
> ==19817==    by 0x84815E: btserver_main(int, char**) (main.cc:1034)
> ==19817==    by 0x844F64: main (main.cc:157)
> client stack range: [0x1FFEFEA000 0x1FFF000FFF] client SP: 0x1FFEFFDB30
> valgrind stack range: [0x100983C000 0x100993BFFF] top usage: 13936 of 1048576

[Valgrind-users] how to proceed when faced with malloc error

[Jed R. <je...@ca...>]

Greetings,

I saw the FAQ about bad memory allocations and it looks I have run into 
this situation. What I'd like to know is what tools should I use next to 
try and understand why this area of code is misbehaving. It could be 
machine specific, I don't see this error on one hundred other systems, 
and my memtest86 run passed. Thank you for your suggestions.

Jed

*valgrind --leak-check=full --show-leak-kinds=all --track-origins=yes 
--track-fds=yes ./btserver*

-----

--19817-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11 
(SIGSEGV) - exiting
--19817-- si_code=128;  Faulting address: 0x0;  sp: 0x100993be30

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

host stacktrace:
==19817==    at 0x580492FF: get_bszB_as_is (m_mallocfree.c:302)
==19817==    by 0x580492FF: get_bszB (m_mallocfree.c:314)
==19817==    by 0x580492FF: vgPlain_arena_malloc (m_mallocfree.c:1819)
==19817==    by 0x58004D74: vgMemCheck_new_block (mc_malloc_wrappers.c:370)
==19817==    by 0x58004F99: vgMemCheck___builtin_new 
(mc_malloc_wrappers.c:415)
==19817==    by 0x58093FD5: do_client_request (scheduler.c:1979)
==19817==    by 0x58093FD5: vgPlain_scheduler (scheduler.c:1542)
==19817==    by 0x580DA8DA: thread_wrapper (syswrap-linux.c:102)
==19817==    by 0x580DA8DA: run_a_thread_NORETURN (syswrap-linux.c:155)

sched status:
   running_tid=1

Thread 1: status = VgTs_Runnable (lwpid 19817)
==19817==    at 0x4841EF1: operator new(unsigned long) 
(vg_replace_malloc.c:472)
==19817==    by 0x60FFB3: Card::checkNewPort(LFInfo&, String const&, 
char const*, bool, char const*, bool&, bool&, unsigned int) (Card.cc:7510)
==19817==    by 0x611337: Card::discoverDevices(LFInfo&, char const*, 
bool) (Card.cc:8205)
==19817==    by 0x84815E: btserver_main(int, char**) (main.cc:1034)
==19817==    by 0x844F64: main (main.cc:157)
client stack range: [0x1FFEFEA000 0x1FFF000FFF] client SP: 0x1FFEFFDB30
valgrind stack range: [0x100983C000 0x100993BFFF] top usage: 13936 of 
1048576


-- 
Jed Reynolds, Sr. Developer and Sysadmin
Candela Technologies [PST, GMT -8]
Please CC:su...@ca...  on support emails.

Re: [Valgrind-users] Help

[Floyd, P. <pj...@wa...>]

On 07/09/2023 16:52, John Reiser wrote:
>> ==17348== Warning: invalid file descriptor 1024 in syscall close()
>>
>> Your exe is probably trying to ensure all file descriptors are 
>> closed. You should probably use getrlimit() to query the upper limit 
>> rather than assume anything. Exes under Valgrind have a slighly lower 
>> limit because Valgrind uses some file descriptors itself (e.g., its 
>> log file).
>
> See also the manual page for 'close_range', which is a system call in 
> Linux >= 5.9 and FreeBSD.
> You may have to think about what the parameters should be, but 
> 'close_range' is very efficient.


Ahem. Someone needs to implement close_range for FreeBSD in Valgrind.

Something else for 3.22.

A+

Paul

Re: [Valgrind-users] Help

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

> ==17348== Warning: invalid file descriptor 1024 in syscall close()
> 
> Your exe is probably trying to ensure all file descriptors are closed. You should probably use getrlimit() to query the upper limit rather than assume anything. Exes under Valgrind have a slighly lower limit because Valgrind uses some file descriptors itself (e.g., its log file).

See also the manual page for 'close_range', which is a system call in Linux >= 5.9 and FreeBSD.
You may have to think about what the parameters should be, but 'close_range' is very efficient.

Re: [Valgrind-users] Help

[Domenico P. <pan...@gm...>]

Ok.

Thanks

Il 07/09/23 16:42, Floyd, Paul ha scritto:
>
>
> On 07/09/2023 15:52, Domenico Panella wrote:
>> Hi,
>> I attached a valgrind log for my program.
>> I'd want an help to read it to understand if any error are there or not.
>> I don't think so but a confirm is much better.
>
>
> Hi
>
> There's not a lot to see in your log.
>
> ==17348== Warning: invalid file descriptor 1024 in syscall close()
>
> Your exe is probably trying to ensure all file descriptors are closed. 
> You should probably use getrlimit() to query the upper limit rather 
> than assume anything. Exes under Valgrind have a slighly lower limit 
> because Valgrind uses some file descriptors itself (e.g., its log file).
>
> ==17342==     in use at exit: 31,808 bytes in 474 blocks
>
> A bit of memory that you might be able to free. If you are concerned, 
> do what the ouput says and add --leak-check=full --show-leak-kinds=all
>
>
> A+
>
> Paul
>
>
>
>
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Help

[Floyd, P. <pj...@wa...>]

On 07/09/2023 15:52, Domenico Panella wrote:
> Hi,
> I attached a valgrind log for my program.
> I'd want an help to read it to understand if any error are there or not.
> I don't think so but a confirm is much better.


Hi

There's not a lot to see in your log.

==17348== Warning: invalid file descriptor 1024 in syscall close()

Your exe is probably trying to ensure all file descriptors are closed. 
You should probably use getrlimit() to query the upper limit rather than 
assume anything. Exes under Valgrind have a slighly lower limit because 
Valgrind uses some file descriptors itself (e.g., its log file).

==17342==     in use at exit: 31,808 bytes in 474 blocks

A bit of memory that you might be able to free. If you are concerned, do 
what the ouput says and add --leak-check=full --show-leak-kinds=all


A+

Paul

[Valgrind-users] Help

[Domenico P. <pan...@gm...>]

Hi,
I attached a valgrind log for my program.
I'd want an help to read it to understand if any error are there or not.
I don't think so but a confirm is much better.
Thanks

Re: [Valgrind-users] getting type information for local and global variables?

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

Hi Tia,

On Wed, Aug 02, 2023 at 10:27:10AM -0500, Tia Newhall wrote:
> First, sorry but I'm cutting and pasting below your response from off the
> list archive below since I didn't receive an email with your reply.

email is a little unreliable these days :{
And then I went on vacation. So apologies for the long delay.

> As far as your question about the tool I'm building...I'm building a C code
> tracing tool for educational purposes, and using valgrind as the backend of
> this tool.  The resulting tool will be similar to Python tutor but with
> some differences.  We also have an assembly code tracing tool that uses
> valgrind as the backend that we are close to completing.   It doesn't work
> for ARM due to what I think is a vex bug in the ARM version (
> https://bugs.kde.org/show_bug.cgi?id=460951), but it works for x86
> architectures.

Sorry nobody commented on that bug. I have added a bit on debugging IR
blocks as a comment.
 
> The StackBlock and GlobalBlock structs and the interface for getting these
> are very useful for the tool I'm building.  I really like the interfaces
> you were about to remove, but I'd like to add an TyEnt * entry to
> StackBlock and GlobalBlock to get detailed type information so that I can
> interpret and print out bytes of variables, and the memory they point to in
> some cases, in terms of the variable's specific C type.   I believe the
> TyEnt has all the information I would need, but perhaps I am mistaken.
> 
> What are your thoughts?

I admit I have not used these interfaces ever. And as far as I can see
they were only used by the ptrcheck tool from 2008, renamed to sgcheck
in 2011, which was removed in 2020 (and hadn't really seen any updates
except for that name change).

While reviewing the lazy debuginfo loading patches from Aaron (now
integrated) I realized nothing was using these interfaces, so I didn't
really review whether they still worked correctly. Which is why I
proposed to remove them.
https://bugs.kde.org/show_bug.cgi?id=471807
https://bugs.kde.org/show_bug.cgi?id=472512

Since we don't have any code that uses StackBlock or GlobalBlock we
also don't have any tests. Without tests we don't know whether we
break something.

So if we are going to keep this functionality we really need some
tests.

Cheers,

Mark

> On Tue, 2023-08-01 at 08:56 -0500, Tia Newhall wrote:
> > I'm building a valgrind tool, and as part of its functionality I need
> to get (and ultimately print out) local and global variable values
> based on their C types. However, I do not see a way to get detailed
> type information for locals and globals via the tool public interface.
> >
> > The stack and global structs exported
> via VG_(di_get_global_blocks_from_dihandle)
> and VG_(di_get_stack_blocks_at_ip) give me back structs that include
> the variable name, the address, total size in bytes, and if it is an
> array or not, but this is not sufficient for my purposes.  For example,
> if the variable is an array of 16 bytes I have no idea if it is an
> array of char, short, int, unsigned int, int *, etc., and if it is a
> struct or union I have no idea where the field types are, their names,
> nor their offsets and sizes from the base address, and if it is an
> array of structs or unions I have no idea if there is padding between
> elements or not, and enum and typedefs I'd just be out of luck.   Even
> for non-array base types, I don't know if the value is signed or
> unsigned (ex. if 1 byte variable's value is 0xa1 is it -95 (char) or
> 161 (unsigned char)), and for Word sized values it could be a pointer
> or not, in which case I would want to display a pointer's value in hex,
> but if it is a long long I'd want to display it as a signed decimal.
> >
> > Since code in coregrind/m_debuginfo/ is parsing .debug to get the
> correct and detailed type information, offset, sizes, field names,
> etc., I'd like to get that info from coregrind for globals and locals
> through the public tool interface: it looks like the TyEnt struct has
> what I need.
> 
> Good you write about this, because I was just about to commit the
> proposed patch from https://bugs.kde.org/show_bug.cgi?id=472512
> "Remove Stack and Global Blocks from debuginfo handling"
> 
> The VG_(di_get_stack_blocks_at_ip) and
> VG_(di_get_global_blocks_from_dihandle) functions
> were only used by the exp-sgcheck tool.
> 
> Since this tool was removed a couple of years back this code hasn't
> been used or tested. Lets remove it to reduce the complexity of
> dealing with debuginfo.
> 
> This code confused me till I realized it isn't actually used (and was
> last changed in 2008). So I think it is best to just remove it so it
> doesn't confuse others.
> 
> But... now it seems you do want to use it.
> 
> > First, is there a tool interface to this detailed type information
> about variables that I am missing (like info in TyEnt structs) and if
> so, can someone please point me to it?
> >
> > If not (and I think this is the case), I would have to add something
> new to the public tool interface to get the information I need, adding
> or modifying code in coregrind/m_debuginfo/ to do it. I can build my
> own custom version of valgrind with the functionality I need, but this
> is obviously not ideal for keeping up with new version releases.
> >
> > Is there developer interest in expanding the valgrind public tool
> interface to export the kind of detailed type information that I need
> for my tool?  If so, I'd be happy to discuss with someone the best way
> to design and implement it and help work on its implementation.
> 
> I think you would have to create a new interface. Unless you believe
> the current one is still useful. What does your tool do precisely?
> 
> Cheers,
> 
> Mark

Re: [Valgrind-users] Issues in the callgrind output report

[Floyd, P. <pj...@wa...>]

On 12/07/2023 15:26, Pavankumar S V wrote:
>
>  1. Running my application with this command:
>
> *valgrind --tool=callgrind ****-q ****--collect-systime=yes 
> ****--trace-children=yes**** taskset 0x1 application_name*
>

Hi

Sorry for the late answer.

Does it help if you use higher resolution timing? --collect-systime=yes 
defaults to msec timing.

You could try --collect-systime=usec or --collect-systime=nsec.


A+

Paul

Re: [Valgrind-users] getting type information for local and global variables?

[Tia N. <new...@gm...>]

hi Mark,

Thanks for you reply!

First, sorry but I'm cutting and pasting below your response from off the
list archive below since I didn't receive an email with your reply.

As far as your question about the tool I'm building...I'm building a C code
tracing tool for educational purposes, and using valgrind as the backend of
this tool.  The resulting tool will be similar to Python tutor but with
some differences.  We also have an assembly code tracing tool that uses
valgrind as the backend that we are close to completing.   It doesn't work
for ARM due to what I think is a vex bug in the ARM version (
https://bugs.kde.org/show_bug.cgi?id=460951), but it works for x86
architectures.

The StackBlock and GlobalBlock structs and the interface for getting these
are very useful for the tool I'm building.  I really like the interfaces
you were about to remove, but I'd like to add an TyEnt * entry to
StackBlock and GlobalBlock to get detailed type information so that I can
interpret and print out bytes of variables, and the memory they point to in
some cases, in terms of the variable's specific C type.   I believe the
TyEnt has all the information I would need, but perhaps I am mistaken.

What are your thoughts?

Thanks,
Tia


Hi Tia,

On Tue, 2023-08-01 at 08:56 -0500, Tia Newhall wrote:
> I'm building a valgrind tool, and as part of its functionality I need
to get (and ultimately print out) local and global variable values
based on their C types. However, I do not see a way to get detailed
type information for locals and globals via the tool public interface.
>
> The stack and global structs exported
via VG_(di_get_global_blocks_from_dihandle)
and VG_(di_get_stack_blocks_at_ip) give me back structs that include
the variable name, the address, total size in bytes, and if it is an
array or not, but this is not sufficient for my purposes.  For example,
if the variable is an array of 16 bytes I have no idea if it is an
array of char, short, int, unsigned int, int *, etc., and if it is a
struct or union I have no idea where the field types are, their names,
nor their offsets and sizes from the base address, and if it is an
array of structs or unions I have no idea if there is padding between
elements or not, and enum and typedefs I'd just be out of luck.   Even
for non-array base types, I don't know if the value is signed or
unsigned (ex. if 1 byte variable's value is 0xa1 is it -95 (char) or
161 (unsigned char)), and for Word sized values it could be a pointer
or not, in which case I would want to display a pointer's value in hex,
but if it is a long long I'd want to display it as a signed decimal.
>
> Since code in coregrind/m_debuginfo/ is parsing .debug to get the
correct and detailed type information, offset, sizes, field names,
etc., I'd like to get that info from coregrind for globals and locals
through the public tool interface: it looks like the TyEnt struct has
what I need.

Good you write about this, because I was just about to commit the
proposed patch from https://bugs.kde.org/show_bug.cgi?id=472512
"Remove Stack and Global Blocks from debuginfo handling"

The VG_(di_get_stack_blocks_at_ip) and
VG_(di_get_global_blocks_from_dihandle) functions
were only used by the exp-sgcheck tool.

Since this tool was removed a couple of years back this code hasn't
been used or tested. Lets remove it to reduce the complexity of
dealing with debuginfo.

This code confused me till I realized it isn't actually used (and was
last changed in 2008). So I think it is best to just remove it so it
doesn't confuse others.

But... now it seems you do want to use it.

> First, is there a tool interface to this detailed type information
about variables that I am missing (like info in TyEnt structs) and if
so, can someone please point me to it?
>
> If not (and I think this is the case), I would have to add something
new to the public tool interface to get the information I need, adding
or modifying code in coregrind/m_debuginfo/ to do it. I can build my
own custom version of valgrind with the functionality I need, but this
is obviously not ideal for keeping up with new version releases.
>
> Is there developer interest in expanding the valgrind public tool
interface to export the kind of detailed type information that I need
for my tool?  If so, I'd be happy to discuss with someone the best way
to design and implement it and help work on its implementation.

I think you would have to create a new interface. Unless you believe
the current one is still useful. What does your tool do precisely?

Cheers,

Mark

Re: [Valgrind-users] getting type information for local and global variables?

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

Hi Tia,

On Tue, 2023-08-01 at 08:56 -0500, Tia Newhall wrote:
> I'm building a valgrind tool, and as part of its functionality I need
to get (and ultimately print out) local and global variable values
based on their C types. However, I do not see a way to get detailed
type information for locals and globals via the tool public interface.
> 
> The stack and global structs exported
via VG_(di_get_global_blocks_from_dihandle)
and VG_(di_get_stack_blocks_at_ip) give me back structs that include
the variable name, the address, total size in bytes, and if it is an
array or not, but this is not sufficient for my purposes.  For example,
if the variable is an array of 16 bytes I have no idea if it is an
array of char, short, int, unsigned int, int *, etc., and if it is a
struct or union I have no idea where the field types are, their names,
nor their offsets and sizes from the base address, and if it is an
array of structs or unions I have no idea if there is padding between
elements or not, and enum and typedefs I'd just be out of luck.   Even
for non-array base types, I don't know if the value is signed or
unsigned (ex. if 1 byte variable's value is 0xa1 is it -95 (char) or
161 (unsigned char)), and for Word sized values it could be a pointer
or not, in which case I would want to display a pointer's value in hex,
but if it is a long long I'd want to display it as a signed decimal. 
> 
> Since code in coregrind/m_debuginfo/ is parsing .debug to get the
correct and detailed type information, offset, sizes, field names,
etc., I'd like to get that info from coregrind for globals and locals
through the public tool interface: it looks like the TyEnt struct has
what I need.

Good you write about this, because I was just about to commit the
proposed patch from https://bugs.kde.org/show_bug.cgi?id=472512
"Remove Stack and Global Blocks from debuginfo handling"

The VG_(di_get_stack_blocks_at_ip) and
VG_(di_get_global_blocks_from_dihandle) functions
were only used by the exp-sgcheck tool.
    
Since this tool was removed a couple of years back this code hasn't
been used or tested. Lets remove it to reduce the complexity of
dealing with debuginfo.

This code confused me till I realized it isn't actually used (and was
last changed in 2008). So I think it is best to just remove it so it
doesn't confuse others.

But... now it seems you do want to use it.

> First, is there a tool interface to this detailed type information
about variables that I am missing (like info in TyEnt structs) and if
so, can someone please point me to it?
> 
> If not (and I think this is the case), I would have to add something
new to the public tool interface to get the information I need, adding
or modifying code in coregrind/m_debuginfo/ to do it. I can build my
own custom version of valgrind with the functionality I need, but this
is obviously not ideal for keeping up with new version releases.  
> 
> Is there developer interest in expanding the valgrind public tool
interface to export the kind of detailed type information that I need
for my tool?  If so, I'd be happy to discuss with someone the best way
to design and implement it and help work on its implementation. 

I think you would have to create a new interface. Unless you believe
the current one is still useful. What does your tool do precisely?

Cheers,

Mark

[Valgrind-users] getting type information for local and global variables?

[Tia N. <ne...@cs...>]

hi,

I'm building a valgrind tool, and as part of its functionality I need to
get (and ultimately print out) local and global variable values based on
their C types. However, I do not see a way to get detailed type information
for locals and globals via the tool public interface.

The stack and global structs exported
via VG_(di_get_global_blocks_from_dihandle)
and VG_(di_get_stack_blocks_at_ip) give me back structs that include the
variable name, the address, total size in bytes, and if it is an array or
not, but this is not sufficient for my purposes.  For example, if the
variable is an array of 16 bytes I have no idea if it is an array of char,
short, int, unsigned int, int *, etc., and if it is a struct or union I
have no idea where the field types are, their names, nor their offsets and
sizes from the base address, and if it is an array of structs or unions I
have no idea if there is padding between elements or not, and enum and
typedefs I'd just be out of luck.   Even for non-array base types, I don't
know if the value is signed or unsigned (ex. if 1 byte variable's value is
0xa1 is it -95 (char) or 161 (unsigned char)), and for Word sized values it
could be a pointer or not, in which case I would want to display a
pointer's value in hex, but if it is a long long I'd want to display it as
a signed decimal.

Since code in coregrind/m_debuginfo/ is parsing .debug to get the correct
and detailed type information, offset, sizes, field names, etc., I'd like
to get that info from coregrind for globals and locals through the public
tool interface: it looks like the TyEnt struct has what I need.

First, is there a tool interface to this detailed type information about
variables that I am missing (like info in TyEnt structs) and if so,
can someone please point me to it?

If not (and I think this is the case), I would have to add something new to
the public tool interface to get the information I need, adding or
modifying code in coregrind/m_debuginfo/ to do it. I can build my own
custom version of valgrind with the functionality I need, but this is
obviously not ideal for keeping up with new version releases.

Is there developer interest in expanding the valgrind public tool interface
to export the kind of detailed type information that I need for my tool?
If so, I'd be happy to discuss with someone the best way to design and
implement it and help work on its implementation.

Thanks,
Tia

-------------------------------
Tia Newhall
Professor, Computer Science Dept.
Swarthmore College
www.cs.swarthmore.edu/~newhall
pronouns: she/her

Re: [Valgrind-users] [Valgrind-developers] RFC: support scalable vector model / riscv vector

[Petr P. <pet...@da...>]

On 17. Jul 23 15:05, Jojo R wrote:
> Hi,
> 
> Sorry for the late reply,
> 
> i have been pushing the progress of valgrind RVV implementation 😄
> We finished the first version and tested with full RVV intrinsics spec.
> 
> For real project and developers, we implement the first useable/ full
> functionality's RVV valgrind with dirtycall method,
> and we will make experiment or optimize RVV implementation on ideal RVV
> design.
> 
> Back to the RVV RFC, we are happy to share our thinking of design, see
> attachment for more details :)

This is a good summary.

As mentioned in another part of the thread, I think that in long run it
will be indeed needed to implement the approach described as "RVV to
variable-length IR". I hope to help with making sure it can work for Arm
SVE too.

I guess if initial experiments show that this option is hard and will
take time to implement then it could make sense in short term for the
RISC-V port to go with the "RVV to dirty helper" implementation.

Thanks,
Petr

Re: [Valgrind-users] Does Valgrind support AMD Ryzen 5 5600X processors

[Nicholas N. <n.n...@gm...>]

On Thu, 20 Jul 2023 at 00:50, John Reiser <jr...@bi...> wrote:

>
> RTFM.  It's DOCUMENTED!!  https://valgrind.org/info/platforms.html
>

John, please refrain from this kind of aggressive language. Stuart asked a
reasonable question in good faith, and doesn't deserve a response with that
tone.

Nick

Re: [Valgrind-users] Does Valgrind support AMD Ryzen 5 5600X processors

[Stuart F. <smf...@nt...>]

Thanks for all the replies,.

I use LFS/BLFS for my systems so I think given the feedback I will build 
an additional system on my Ryzen and build with march=x86-64 which from 
what I have understood will allow valgind to work.

Please correct me if I am wrong.

Re: [Valgrind-users] Does Valgrind support AMD Ryzen 5 5600X processors

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

> I am trying to find which of my systems will run valgrind, I know it will not run on my AMD FX-8370� and AMD FX-4350 systems. Does any one know if it should run on my AMD Ryzen 5 5600X (see failure below) ?
> 
> I have access to an Intel core 7 laptop (Haswell), would I stand a better chance with that, I am reluctant to move my whole project to the laptop if there is no chance of Valgrind working there too.
> 

> ==5096== Using Valgrind-3.21.0 and LibVEX; rerun with -h for copyright info
> ==5096== Command: QtWeather -s moira2
> ==5096==
> vex amd64->IR: unhandled instruction bytes: 0xC4 0xE2 0x7D 0xDC 0xC9 0x48 0x39 0xD1 0x73 0x37
> vex amd64->IR:�� REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0
> vex amd64->IR:�� VEX=1 VEX.L=1 VEX.nVVVV=0x0 ESC=0F38
> vex amd64->IR:�� PFX.66=1 PFX.F2=0 PFX.F3=0
> ==5096== valgrind: Unrecognised instruction at address 0x5ee6282.
> ==5096==��� at 0x5EE6282: aeshash256_ge32(long long __vector(4), unsigned char const*, unsigned long) (in /opt/qt-6.4.0/lib/libQt6Core.so.6.4.0)

RTFM.  It's DOCUMENTED!!  https://valgrind.org/info/platforms.html
     AMD64/Linux: up to and including AVX2. This is the primary development target and tends to be well supported.

So: Intel Haswell: yes.  If "grep aes /proc/cpuinfo" is not empty, then NO,
unless you tell the compiler and disto-supplied libraries to avoid aes.
Also search for 'aes' in "$ info gcc".

Re: [Valgrind-users] Does Valgrind support AMD Ryzen 5 5600X processors

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

That depends how you define support.

I use it on a Ryzen all the time, but not with code compiled
to target all the AMD specific extensions, which we do not
currently have support for.

Tom

On 19/07/2023 12:39, Stuart Foster via Valgrind-users wrote:
> I am trying to find which of my systems will run valgrind, I know it 
> will not run on my AMD FX-8370� and AMD FX-4350 systems. Does any one 
> know if it should run on my AMD Ryzen 5 5600X (see failure below) ?
> 
> I have access to an Intel core 7 laptop (Haswell), would I stand a 
> better chance with that, I am reluctant to move my whole project to the 
> laptop if there is no chance of Valgrind working there too.
> 
> ==5096== Memcheck, a memory error detector
> ==5096== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
> ==5096== Using Valgrind-3.21.0 and LibVEX; rerun with -h for copyright info
> ==5096== Command: QtWeather -s moira2
> ==5096==
> vex amd64->IR: unhandled instruction bytes: 0xC4 0xE2 0x7D 0xDC 0xC9 
> 0x48 0x39 0xD1 0x73 0x37
> vex amd64->IR:�� REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0
> vex amd64->IR:�� VEX=1 VEX.L=1 VEX.nVVVV=0x0 ESC=0F38
> vex amd64->IR:�� PFX.66=1 PFX.F2=0 PFX.F3=0
> ==5096== valgrind: Unrecognised instruction at address 0x5ee6282.
> ==5096==��� at 0x5EE6282: aeshash256_ge32(long long __vector(4), 
> unsigned char const*, unsigned long) (in 
> /opt/qt-6.4.0/lib/libQt6Core.so.6.4.0)
> ==5096==��� by 0x5FEBFD1: 
> QFactoryLoaderPrivate::updateSinglePath(QString const&) (in 
> /opt/qt-6.4.0/lib/libQt6Core.so.6.4.0)
> ==5096==��� by 0x5FE8403: QFactoryLoader::update() (in 
> /opt/qt-6.4.0/lib/libQt6Core.so.6.4.0)
> ==5096==��� by 0x5FE8906: QFactoryLoader::QFactoryLoader(char const*, 
> QString const&, Qt::CaseSensitivity) (in 
> /opt/qt-6.4.0/lib/libQt6Core.so.6.4.0)
> ==5096==��� by 0x54DC115: QPlatformIntegrationFactory::keys(QString 
> const&) (in /opt/qt-6.4.0/lib/libQt6Gui.so.6.4.0)
> ==5096==��� by 0x54A1A36: init_platform(QString const&, QString const&, 
> QString const&, int&, char**) (in /opt/qt-6.4.0/lib/libQt6Gui.so.6.4.0)
> ==5096==��� by 0x54A58DF: 
> QGuiApplicationPrivate::createPlatformIntegration() (in 
> /opt/qt-6.4.0/lib/libQt6Gui.so.6.4.0)
> ==5096==��� by 0x54A6517: 
> QGuiApplicationPrivate::createEventDispatcher() (in 
> /opt/qt-6.4.0/lib/libQt6Gui.so.6.4.0)
> ==5096==��� by 0x5F64804: QCoreApplicationPrivate::init() (in 
> /opt/qt-6.4.0/lib/libQt6Core.so.6.4.0)
> ==5096==��� by 0x54A9979: QGuiApplicationPrivate::init() (in 
> /opt/qt-6.4.0/lib/libQt6Gui.so.6.4.0)
> ==5096==��� by 0x4C28708: QApplicationPrivate::init() (in 
> /opt/qt-6.4.0/lib/libQt6Widgets.so.6.4.0)
> ==5096==��� by 0x124098: main (in /usr/bin/QtWeather)
> ==5096== Your program just tried to execute an instruction that Valgrind
> ==5096== did not recognise.� There are two possible reasons for this.
> ==5096== 1. Your program has a bug and erroneously jumped to a non-code
> ==5096==��� location.� If you are running Memcheck and you just saw a
> ==5096==��� warning about a bad jump, it's probably your program's fault.
> ==5096== 2. The instruction is legitimate but Valgrind doesn't handle it,
> ==5096==��� i.e. it's Valgrind's fault.� If you think this is the case or
> ==5096==��� you are not sure, please let us know and we'll try to fix it.
> ==5096== Either way, Valgrind will now raise a SIGILL signal which will
> ==5096== probably kill your program.
> ==5096==
> ...
> 
> Thanks
> 
> 
> 
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users

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

Re: [Valgrind-users] Does Valgrind support AMD Ryzen 5 5600X processors

[Simon S. <sim...@gn...>]

The issue is _very_ likely not about the processor:

==5096== valgrind: Unrecognised instruction at address 0x5ee6282.
==5096==  at 0x5EE6282: aeshash256_ge32(long long __vector(4), unsigned 
char const*, unsigned long) (in /opt/qt-6.4.0/lib/libQt6Core.so.6.4.0)

This library uses an unknown instruction, and it likely will do so on 
other processors, too.

The only solution is to use a QT library that doesn't use this.
Depending on how this is configured/build you may be able to disable use 
of this aes function altogether, if not you _may_ be able to specify via 
CXXFLAGS/CFLAGS to not optimize for a CPU.

Side note: all my projects work on valgrind if I only compile 
"normally", as soon as I use -march/-mtune GCC generates calls to faster 
but cpu specific instructions that valgrind does not support yet.

Simon


Am 19.07.2023 um 13:39 schrieb Stuart Foster via Valgrind-users:
> I am trying to find which of my systems will run valgrind, I know it 
> will not run on my AMD FX-8370� and AMD FX-4350 systems. Does any one 
> know if it should run on my AMD Ryzen 5 5600X (see failure below) ?
> 
> I have access to an Intel core 7 laptop (Haswell), would I stand a 
> better chance with that, I am reluctant to move my whole project to the 
> laptop if there is no chance of Valgrind working there too.
> 
> ==5096== Memcheck, a memory error detector
> ==5096== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
> ==5096== Using Valgrind-3.21.0 and LibVEX; rerun with -h for copyright info
> ==5096== Command: QtWeather -s moira2
> ==5096==
> vex amd64->IR: unhandled instruction bytes: 0xC4 0xE2 0x7D 0xDC 0xC9 
> 0x48 0x39 0xD1 0x73 0x37
> vex amd64->IR:�� REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0
> vex amd64->IR:�� VEX=1 VEX.L=1 VEX.nVVVV=0x0 ESC=0F38
> vex amd64->IR:�� PFX.66=1 PFX.F2=0 PFX.F3=0
> ==5096== valgrind: Unrecognised instruction at address 0x5ee6282.
> ==5096==��� at 0x5EE6282: aeshash256_ge32(long long __vector(4), 
> unsigned char const*, unsigned long) (in 
> /opt/qt-6.4.0/lib/libQt6Core.so.6.4.0)
> ==5096==��� by 0x5FEBFD1: 
> QFactoryLoaderPrivate::updateSinglePath(QString const&) (in 
> /opt/qt-6.4.0/lib/libQt6Core.so.6.4.0)
> ==5096==��� by 0x5FE8403: QFactoryLoader::update() (in 
> /opt/qt-6.4.0/lib/libQt6Core.so.6.4.0)
> ==5096==��� by 0x5FE8906: QFactoryLoader::QFactoryLoader(char const*, 
> QString const&, Qt::CaseSensitivity) (in 
> /opt/qt-6.4.0/lib/libQt6Core.so.6.4.0)
> ==5096==��� by 0x54DC115: QPlatformIntegrationFactory::keys(QString 
> const&) (in /opt/qt-6.4.0/lib/libQt6Gui.so.6.4.0)
> ==5096==��� by 0x54A1A36: init_platform(QString const&, QString const&, 
> QString const&, int&, char**) (in /opt/qt-6.4.0/lib/libQt6Gui.so.6.4.0)
> ==5096==��� by 0x54A58DF: 
> QGuiApplicationPrivate::createPlatformIntegration() (in 
> /opt/qt-6.4.0/lib/libQt6Gui.so.6.4.0)
> ==5096==��� by 0x54A6517: 
> QGuiApplicationPrivate::createEventDispatcher() (in 
> /opt/qt-6.4.0/lib/libQt6Gui.so.6.4.0)
> ==5096==��� by 0x5F64804: QCoreApplicationPrivate::init() (in 
> /opt/qt-6.4.0/lib/libQt6Core.so.6.4.0)
> ==5096==��� by 0x54A9979: QGuiApplicationPrivate::init() (in 
> /opt/qt-6.4.0/lib/libQt6Gui.so.6.4.0)
> ==5096==��� by 0x4C28708: QApplicationPrivate::init() (in 
> /opt/qt-6.4.0/lib/libQt6Widgets.so.6.4.0)
> ==5096==��� by 0x124098: main (in /usr/bin/QtWeather)
> ==5096== Your program just tried to execute an instruction that Valgrind
> ==5096== did not recognise.� There are two possible reasons for this.
> ==5096== 1. Your program has a bug and erroneously jumped to a non-code
> ==5096==��� location.� If you are running Memcheck and you just saw a
> ==5096==��� warning about a bad jump, it's probably your program's fault.
> ==5096== 2. The instruction is legitimate but Valgrind doesn't handle it,
> ==5096==��� i.e. it's Valgrind's fault.� If you think this is the case or
> ==5096==��� you are not sure, please let us know and we'll try to fix it.
> ==5096== Either way, Valgrind will now raise a SIGILL signal which will
> ==5096== probably kill your program.
> ==5096==
> ...
> 
> Thanks
> 
> 
> 
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users