valgrind-users — General discussion list for Valgrind users

Re: [Valgrind-users] [Valgrind-developers] Valgrind-3.22.0.RC2 is available for testing

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

Hi,

On Thu, Oct 26, 2023 at 12:38:04PM -0700, Carl Love via Valgrind-developers wrote:
> Valgrind-3.22.0.RC2 looks good on power. I have run the RC2 on Power
> 10LE, Power 9 LE, Power 8 LE/BE, and Power 7 BE. I see the two failures
> 
> memcheck/tests/bug340392                 (stderr)
> memcheck/tests/linux/rfcomm              (stderr)
> 
> everywhere which is normal.  A couple of the older systems also report
> 
> memcheck/tests/leak_cpp_interior         (stderr)
> memcheck/tests/linux/sys-execveat        (stderr)
> 
> which is also consistent on those platforms.
> 
> It all looks good on PowerPC.

Thanks.

= I ran make regtest on Fedora 38 POWER9 ppc64le and got:

== 732 tests, 2 stderr failures, 0 stdout failures, 0 stderrB failures, 0 stdoutB failures, 0 post failures ==
memcheck/tests/bug340392                 (stderr)
drd/tests/std_thread2                    (stderr)

--- std_thread2.stderr.exp      2023-04-27 15:25:16.109185858 +0000
+++ std_thread2.stderr.out      2023-10-26 23:12:41.571112420 +0000
@@ -1,9 +1,14 @@
 
 Thread 2:
+Conflicting load by thread 2 at 0x........ size 8
+   at 0x........: _dl_new_hash (dl-new-hash.h:90)
+   by 0x........: _dl_lookup_symbol_x (dl-lookup.c:757)
+Allocation context: Data section of /usr/lib64/ld64.so.2
+
 Conflicting store by thread 2 at 0x........ size 4
    at 0x........: main::LAMBDA::operator()() const (std_thread2.cpp:21)
 Allocation context: BSS section of std_thread2
 
 Done.
 
-ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
+ERROR SUMMARY: 6 errors from 2 contexts (suppressed: 0 from 0)

I haven't really looked into that more. It is a deterministic
failure. But I think data races in ld.so should be suppressed?

= On Fedora 40 (rawhide) x86 (32bit) here are zero failures !

= On Fedora 38 s390x

== 842 tests, 1 stderr failure, 0 stdout failures, 0 stderrB failure, 0 stdoutB failure, 0 post failures ==
memcheck/tests/vbit-test/vbit-test       (stderr)

--- vbit-test.stderr.exp		 2022-02-09 22:47:30.491170867 +0000
+++ vbit-test.stderr.out		 2023-10-26 22:51:38.544254194 +0000
@@ -0,0 +1,3 @@
+Conditional jump or move depends on uninitialised value(s)
+   ...
+

I believe I saw this with 3.21.0 too.

= On RHEL8 x86_64

== 880 tests, 1 stderr failure, 0 stdout failures, 0 stderrB failures, 0 stdoutB failures, 9 post failures ==
memcheck/tests/overlap                   (stderr)

Which is https://bugs.kde.org/show_bug.cgi?id=402833

Cheers,

Mark

[Valgrind-users] Valgrind-3.22.0.RC2 is available for testing

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

An RC2 tarball for 3.22.0 is now available at
https://sourceware.org/pub/valgrind/valgrind-3.22.0.RC2.tar.bz2
(md5sum = 07bb18b0fd1c7347b350d8d71dc940f6)
(sha1sum = 61c29e47efdc933ea3f23cb2f0fcebcd6d96dab1)
https://sourceware.org/pub/valgrind/valgrind-3.22.0.RC2.tar.bz2.asc

Changes since RC1:

Andreas Arnez (5):
      s390x: Fix memcheck false positives with certain comparisons
      s390x regtest: Fix memcheck tests for cu21 and cu42 with Clang
      Update NEWS to reflect Clang support for s390x
      s390x: Adjust .gitignore after commit 7cf98163adb3f
      s390x regtest: Activate 128 bit SIMD tests for s390x in vbit-test

Carl Love (3):
      Bug 476025 - Powerpc, update expected results for the vbit-test
      Revert "Bug 476025 - Powerpc, update expected results for the
vbit-test"
      Change the vbit test specification for Iop_CmpGT64Ux2

Mark Wielaard (7):
      Add new drd/tests/thrd_create test to .gitignore
      Add arm-linux build artifacts to .gitignore
      vg_replace_malloc DELETE should not check size
      Add 32bit variant of new_aligned_delete_default.stderr.exp
      Add x86 variant of origin5-bz2.stderr.exp-glibc25-amd64-b
      Add new exp files to EXTRA_DIST in memcheck/tests/Makefile.am
      Set version to 3.22.0-RC2

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 Tuesday 31
October.

Re: [Valgrind-users] [Valgrind-developers] Valgrind-3.22.0.RC1 is available for testing

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

Hi,

On Wed, Oct 18, 2023 at 01:04:21AM +0200, Mark Wielaard wrote:
> An RC1 tarball for 3.22.0 is now available at
> https://sourceware.org/pub/valgrind/valgrind-3.22.0.RC1.tar.bz2
> (md5sum = 786715e301f9b1d3e10faf2a5b360598)
> (sha1sum = ea0e9ca5b5c45168bfcb795e1d19d9d3f5d58223)
> https://sourceware.org/pub/valgrind/valgrind-3.22.0.RC1.tar.bz2.asc
> 
> 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
> 
> RC2 will appear in one week, Tuesday 24 October. And if nothing
> critical emerges after that, a final release will happen a week after
> that on Tuesday 31 October.

I am pushing out RC2 two days to Thursday 26 October so we can get a
fix in for https://bugs.kde.org/show_bug.cgi?id=476025 It is not super
urgent since it looks like a testsuite only issue. But it would be
nice to be able to check the vbit tests correct on all arches.

Cheers,

Mark

[Valgrind-users] Valgrind-3.22.0.RC1 is available for testing

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

An RC1 tarball for 3.22.0 is now available at
https://sourceware.org/pub/valgrind/valgrind-3.22.0.RC1.tar.bz2
(md5sum = 786715e301f9b1d3e10faf2a5b360598)
(sha1sum = ea0e9ca5b5c45168bfcb795e1d19d9d3f5d58223)
https://sourceware.org/pub/valgrind/valgrind-3.22.0.RC1.tar.bz2.asc

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

RC2 will appear in one week, Tuesday 24 October. And if nothing
critical emerges after that, a final release will happen a week after
that on Tuesday 31 October.

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

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

On Thursday, October 12, 2023 4:16:17 AM EDT Paul Floyd wrote:
> Yes, a lot of users tend to be confused in thinking that once an object
> has been initialized then it will always be initialized.

I found the problem in my code and it was as you say Paul.  Due to a bug 
elsewhere, some member in the uninitialized part of the structure was being 
used to overwrite a previously set member.

Thanks for your feedback and your continued work on Valgrind! 


-Karl

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

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

On Thursday, October 12, 2023 4:16:17 AM EDT Paul Floyd wrote:
> Yes, a lot of users tend to be confused in thinking that once an object
> has been initialized then it will always be initialized.
> 
> We can't see when is happening between the possibly incomplete
> initialization and the actual error.

You can see the actual errors reported and the memset test line which 
eliminates them here:
    https://github.com/WickedSmoke/xu4/compare/valgrind?expand=1

The memset is before the actual initialization in txf_begin(), so if an 
uninitialized value were assigned later then it should not be changing the 
valgrind report.

The actual struct names are ListDrawState & TxfDrawState and both are plain 
data of 128 bytes & 72 bytes respectively.


-Karl

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

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

On 12/10/2023 08:53, Paul Floyd wrote:
> 
> On 11/10/2023 23:47, Karl Robillard via Valgrind-users wrote:
>> 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()
> 
> I don't think that this is legal C++. You can't assume that a C++ class 
> object has the same kind of memory layout as a POD C struct.

That's not any part of the problem code though, so it's not
really relevant to the original problem.

There's no way we can comment on the original problem though
because we can't actually see any of the code, only a few top
level highlights which is nowhere near enough to tell us
anything about what is happening.

Tom

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

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

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

On 12/10/2023 10:06, Tom Hughes wrote:
>
> That's not any part of the problem code though, so it's not
> really relevant to the original problem.
>
> There's no way we can comment on the original problem though
> because we can't actually see any of the code, only a few top
> level highlights which is nowhere near enough to tell us
> anything about what is happening.


Yes, a lot of users tend to be confused in thinking that once an object 
has been initialized then it will always be initialized.

We can't see when is happening between the possibly incomplete 
initialization and the actual error.


Just to explain that first point, in pseudo code

Uninit x; // not initialized

Widget w;

memset w to 0;

// w now all initialized

w.thing = x;

// w.thing now uninitialized


A+

Paul

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

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

On 11/10/2023 23:47, Karl Robillard via Valgrind-users wrote:
> 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()

I don't think that this is legal C++. You can't assume that a C++ class 
object has the same kind of memory layout as a POD C struct.

Does this apply in your case?

https://en.cppreference.com/w/cpp/language/ebo

If ListDrawState isn't using EBO then its size will be larger DrawState 
even though it may not add any data members.


In summary, you should either stick to POD structures and then you can 
use memset or else use C++ classes and constructors.


A+

Paul

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