valgrind-users — General discussion list for Valgrind users

[Valgrind-users] See the address of leaked memory

[Corey M. <mi...@ac...>]

Is there any way in valgrind where you can see the address of leaked
memory in the leak report, the address the program would have seen?
That would make a leak much easier for me to debug.

Thanks,

-corey

Re: [Valgrind-users] Memory leak not detected

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

>> Any ideas why this memory leak is not being detected by valgrind?

Because it's not really possible to do so.  Consider the problem of knowing
when an mmap-d page is no longer in use.  Those pages are presumably managed
by your app, in some way that is unknown to Valgrind/Memcheck, hence it has
no way to know when a page is, logically speaking, leaked.

By contrast, blocks in the normal malloc/free heap are "managed" by a
simple protocol (calling malloc, then free) that Memcheck knows about.
So it can figure out when a block is leaked by checking whether any
pointers to it exist.  Even then, that's a heuristic hack: you could
conceivably represent a block address into two values, which, when added
together, produce the address.  Then Memcheck will believe the block to
be leaked, even though you could regain access to it merely by adding
the two values together.

J

Re: [Valgrind-users] Memory leak not detected

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

> I think I found the problem. It seems valgrind doesn't detect memory leaks related to mmap. Why is this the case?

A memory leak is a block that is allocated by malloc/calloc/realloc/reallocarray,
not yet free()d, and with no in-process pointers to it.
mmap is not malloc, and the result of mmap() cannot be a memory leak.
Run "strace -e trace=mmap,mmap2,munmap,mremap ./my_app args..."
or use a debugger to put a breakpoint on appropriate calls.

Re: [Valgrind-users] Memory leak not detected

[James R. <jam...@gm...>]

I think I found the problem. It seems valgrind doesn't detect memory leaks
related to mmap. Why is this the case?

On Thu, Jan 6, 2022 at 7:30 PM James Read <jam...@gm...> wrote:

> I have a program that definitely has a memory leak. I can see the memory
> usage of the program going up rapidly with htop until it gets killed for
> consuming too much memory. Yet this is the output from sudo valgrind -v
> --tool=memcheck --leak-check=full --show-reachable=yes --track-origins=yes
> --log-file=memcheck.log ./my_mmap ip enp3s0 192.168.1.254 :
>
> ==234971==
> ==234971== HEAP SUMMARY:
> ==234971==     in use at exit: 235,528 bytes in 499 blocks
> ==234971==   total heap usage: 499,999 allocs, 499,500 frees, 18,248,456
> bytes allocated
> ==234971==
> ==234971== Searching for pointers to 499 not-freed blocks
> ==234971== Checked 4,186,197,696 bytes
> ==234971==
> ==234971== 235,528 bytes in 499 blocks are still reachable in loss record
> 1 of 1
> ==234971==    at 0x4843839: malloc (in
> /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==234971==    by 0x48F06DD: __fopen_internal (iofopen.c:65)
> ==234971==    by 0x48F06DD: fopen@@GLIBC_2.2.5 (iofopen.c:86)
> ==234971==    by 0x10A2B6: main (my_mmap.c:466)
> ==234971==
> ==234971== LEAK SUMMARY:
> ==234971==    definitely lost: 0 bytes in 0 blocks
> ==234971==    indirectly lost: 0 bytes in 0 blocks
> ==234971==      possibly lost: 0 bytes in 0 blocks
> ==234971==    still reachable: 235,528 bytes in 499 blocks
> ==234971==         suppressed: 0 bytes in 0 blocks
> ==234971==
> ==234971== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
>
> I attach the code for the program in question. It requires an input file
> with one IP address per line.
>
> Any ideas why this memory leak is not being detected by valgrind? Or what
> the source of the memory leak could be?
>
> James Read
>

[Valgrind-users] Memory leak not detected

[James R. <jam...@gm...>]

I have a program that definitely has a memory leak. I can see the memory
usage of the program going up rapidly with htop until it gets killed for
consuming too much memory. Yet this is the output from sudo valgrind -v
--tool=memcheck --leak-check=full --show-reachable=yes --track-origins=yes
--log-file=memcheck.log ./my_mmap ip enp3s0 192.168.1.254 :

==234971==
==234971== HEAP SUMMARY:
==234971==     in use at exit: 235,528 bytes in 499 blocks
==234971==   total heap usage: 499,999 allocs, 499,500 frees, 18,248,456
bytes allocated
==234971==
==234971== Searching for pointers to 499 not-freed blocks
==234971== Checked 4,186,197,696 bytes
==234971==
==234971== 235,528 bytes in 499 blocks are still reachable in loss record 1
of 1
==234971==    at 0x4843839: malloc (in
/usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==234971==    by 0x48F06DD: __fopen_internal (iofopen.c:65)
==234971==    by 0x48F06DD: fopen@@GLIBC_2.2.5 (iofopen.c:86)
==234971==    by 0x10A2B6: main (my_mmap.c:466)
==234971==
==234971== LEAK SUMMARY:
==234971==    definitely lost: 0 bytes in 0 blocks
==234971==    indirectly lost: 0 bytes in 0 blocks
==234971==      possibly lost: 0 bytes in 0 blocks
==234971==    still reachable: 235,528 bytes in 499 blocks
==234971==         suppressed: 0 bytes in 0 blocks
==234971==
==234971== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

I attach the code for the program in question. It requires an input file
with one IP address per line.

Any ideas why this memory leak is not being detected by valgrind? Or what
the source of the memory leak could be?

James Read

Re: [Valgrind-users] [Valgrind-developers] Virtual Valgrind Fosdem Devroom

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

Hi Valgrind Hackers,

A reminder that Valgrind will participate in the Virtual Fosdem on
Sunday 6 February 2022 https://fosdem.org/2022/schedule/track/valgrind/

We are still accepting talk proposals, but will have to finalize the
schedule next week. Please submit a talk proposal asap at
https://penta.fosdem.org/submission/FOSDEM22 Please select the
"Valgrind Devroom" Track.  If you have any trouble creating a penta
login or cannot immediate create a full submission please contact
Julian and me with your proposal so we can still schedule your talk.

More information in the original call for participation below.

On Mon, Dec 13, 2021 at 06:04:33PM +0100, Mark Wielaard wrote:
> Hi valgrind hackers,
> 
> Valgrind will participate in the Virtual Fosdem on Sunday 6 February
> 2022 https://fosdem.org/2022/schedule/track/valgrind/
> 
> We would like to invite people to propose talks on valgrind by
> submitting a talk proposal to 
> https://penta.fosdem.org/submission/FOSDEM22
> Please select the "Valgrind Devroom" Track.
> (If you have any trouble creating a penta login or submission please
> contact Julian and me with your proposal.)
> 
> Because Fosdem will be virtual this year we will likely ask talks to be
> pre-recorded in advance and after playing your presentation we will do
> a live Q/A session using Jitsi and Matrix.
> 
> Please pick a time that includes the length of your (recorded) talk
> plus ~15 minutes Q/A.
> 
> We would like to finalize the schedule the first week of January so
> that people have enough time to record their talk, so please submit
> your proposals before the end of year (31 December 2021).
> 
> Some possible topics for talks/discussions are:
> 
> - New (or recently added) ports.
> - New CPU (instruction) support.
> - New (ideas/prototypes) of valgrind tools.
> - Valgrind release/bugfixing strategy/policy.
> - Advances in gdbserver and the GDB remote serial protocol.
> - DWARF, debuginfo, symbols and debuginfod servers.
> - Using valgrind with "safe" languages (Rust).
> - Adding/Testing Valgrind syscalls support.
> - Infrastructure changes (speedups) to the Valgrind JIT framework.
> - Your interesting use case with Valgrind.
> 
> Sincerely,
> 
> Mark & Julian

[Valgrind-users] Valgrind tool to print VEX IR only for specific blocks

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

Hello

I'm trying to create a Valgrind tool that will print VEX IR only for IR
blocks corresponding to the code of the input program and will exclude IR
blocks corresponding to libraries.
I have used ppIRSB() inside the instrument function of the tool to print
VEX IR for every IR block encountered.

I have tried a simple program for testing this:
int main() { return 2+3; }
However, this seems to print VEX IR for libraries as well.
Is there a way to exclude blocks corresponding to libraries?

I believe one way could be to construct a call-graph by starting from the
main() function and only print blocks corresponding to functions that are
present in the call-graph.
As I understand, callgrind constructs a call-graph and keeps track of
function names. Can callgrind's call-graph construction be repurposed to
obtain a call-graph starting from main()?

Any help with this would be appreciated.

Thanks
Yashas

-- 


Disclaimer:- This footer text is to convey that this email is sent by one 
of the users of IITH. So, do not mark it as SPAM.

Re: [Valgrind-users] pthread_mutex_destroy with invalid argument

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

On 2021-12-21 20:07, Casey Waldren via Valgrind-users wrote:
> Hello,
>
> I am running into the following errors when running helgrind on a C++ 
> binary built with googletest. The host is Ubuntu 20.04.
>
> The invocation is:
>
> valgrind --tool=helgrind --error-exitcode=100 ./tests/google_tests
>
> The errors are:
>
> ---Thread-Announcement------------------------------------------ 
> ==947== ==947== Thread #1 is the program's root thread ==947== ==947== 
> ---------------------------------------------------------------- 
> ==947== ==947== Thread #1: pthread_mutex_destroy with invalid argument 
> ==947== at 0x483FC96: ??? (in 
> /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_helgrind-amd64-linux.so) 
> ==947== by 0x5AD316F: ??? (in 
> /usr/lib/x86_64-linux-gnu/libp11-kit.so.0.3.0) ==947== by 0x4011F5A: 
> _dl_fini (dl-fini.c:138) ==947== by 0x4D12A26: __run_exit_handlers 
> (exit.c:108) ==947== by 0x4D12BDF: exit (exit.c:139) ==947== by 
> 0x4CF00B9: (below main) (libc-start.c:342) ==947== ==947== 
> ---------------------------------------------------------------- 
> ==947== ==947== Thread #1: pthread_mutex_destroy with invalid argument 
> ==947== at 0x483FC96: ??? (in 
> /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_helgrind-amd64-linux.so) 
> ==947== by 0x4011F5A: _dl_fini (dl-fini.c:138) ==947== by 0x4D12A26: 
> __run_exit_handlers (exit.c:108) ==947== by 0x4D12BDF: exit 
> (exit.c:139) ==947== by 0x4CF00B9: (below main) (libc-start.c:342)
> I am wondering if anyone has seen this or can shed some light on what 
> these imply? I used --tool=drd and it failed with almost identical 
> errors.


Hi

Which version of Valgrind is this with?

I've been trying to do some cleanup of C++ and DRD/Helgrind, but I 
haven't seen this sort of problem.

This looks like pthread_mutex_destroy being called from a destructor. 
Can you provide a simple reproducer?


A+

Paul

[Valgrind-users] pthread_mutex_destroy with invalid argument

[Casey W. <cwa...@la...>]

Hello,

I am running into the following errors when running helgrind on a C++
binary built with googletest. The host is Ubuntu 20.04.

The invocation is:

valgrind --tool=helgrind --error-exitcode=100 ./tests/google_tests

The errors are:

---Thread-Announcement------------------------------------------==947==
==947== Thread #1 is the program's root thread==947== ==947==
----------------------------------------------------------------==947==
==947== Thread #1: pthread_mutex_destroy with invalid argument==947==
  at 0x483FC96: ??? (in
/usr/lib/x86_64-linux-gnu/valgrind/vgpreload_helgrind-amd64-linux.so)==947==
   by 0x5AD316F: ??? (in
/usr/lib/x86_64-linux-gnu/libp11-kit.so.0.3.0)==947==    by 0x4011F5A:
_dl_fini (dl-fini.c:138)==947==    by 0x4D12A26: __run_exit_handlers
(exit.c:108)==947==    by 0x4D12BDF: exit (exit.c:139)==947==    by
0x4CF00B9: (below main) (libc-start.c:342)==947== ==947==
----------------------------------------------------------------==947==
==947== Thread #1: pthread_mutex_destroy with invalid argument==947==
  at 0x483FC96: ??? (in
/usr/lib/x86_64-linux-gnu/valgrind/vgpreload_helgrind-amd64-linux.so)==947==
   by 0x4011F5A: _dl_fini (dl-fini.c:138)==947==    by 0x4D12A26:
__run_exit_handlers (exit.c:108)==947==    by 0x4D12BDF: exit
(exit.c:139)==947==    by 0x4CF00B9: (below main) (libc-start.c:342)

I am wondering if anyone has seen this or can shed some light on what
these imply?

I used --tool=drd and it failed with almost identical errors.

Thank you.

Re: [Valgrind-users] 'make check' for valgrind-3.18.1

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

Hi John



On 12/19/21 16:16, John Crow wrote:
> I ought to have said at first how much I appreciate having Valgrind 
> available. It's invaluable, and thank you for your attention.
>
> 'You are building with the same compiler that was used at configure time?'
> Yes. I verified by doing a configure>>make>>make check right now in a 
> freshly untarred build folder. Outside of specifying --prefix to 
> configure, defaults all the way.


It shouldn't make a difference, but does running the 'autogen.sh' script 
in the Valgrind root directory before configure make any difference?


>
> 'I'm using GCC 11 and in /usr/include/c++/11/new there is [snipped] 
> ... Does yours look similar?'
> Yes, for me it's in /usr/include/c++/9/new.
>
> I'll have to figure out the diff --git suggestion.


In both case the unsigned constant for the size [64U and 320U] is 
changed to be cast to size_t [size_t(64U) and size_t(320U)]


>
> Two chunks out of config.log that might or might not be pertinent, I 
> simply searched for 'delete':
>
> configure:10224: result: no
>
>
> configure:10857: result: yes
> configure:10888: checking if g++ supports aligned new and delete
> configure:10916: c++ -c -std=c++17  conftest.cpp >&5
> configure:10916: $? = 0
> configure:10919: result: yes


That's the one.


Can you also try directly compiling the file to try to find out what 
does and does not work.


For instance (tests done with GCC 9.4 on FreeBSD)


cd memcheck/tests

  g++9 -g cxx17_aligned_new.cpp  -std=c++17 -o foo // this works


g++9 -g cxx17_aligned_new.cpp  -std=c++17 -o foo -fno-sized-deallocation
cxx17_aligned_new.cpp: In function 'int main()':
cxx17_aligned_new.cpp:25:56: error: no matching function for call to 
'operator delete(MyClass*&, unsigned int, std::align_val_t)'
    25 |     operator delete(myClass, 64U, std::align_val_t(64U));
       |                                                        ^
In file included from cxx17_aligned_new.cpp:2:
/usr/local/lib/gcc9/include/c++/new:129:6: note: candidate: 'void 
operator delete(void*)'
   129 | void operator delete(void*) _GLIBCXX_USE_NOEXCEPT

[SNIP other candidates and 2nd error]


One last suggestion, you can you run the preprocessor and see if the 
delete overloads are there?


g++9 -g cxx17_aligned_new.cpp  -std=c++17 -E -o foo.E


then view foo.E and look for "operator delete". The last two overloads 
that I see are


void operator delete(void*, std::size_t, std::align_val_t)
   noexcept __attribute__((__externally_visible__));
void operator delete[](void*, std::size_t, std::align_val_t)
   noexcept __attribute__((__externally_visible__));


A+

Paul

Re: [Valgrind-users] 'make check' for valgrind-3.18.1

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

On 18/12/2021 21:07, John Crow wrote:
> Fwiw I'm seeing a failure, snippet below, when running `make check` on 
> valgrind-3.18.1. The package configures, makes, installs, and, as far 
> as I can tell, executes successfully.
>
> $ uname -a
> Linux foo-Inspiron-3583 5.4.0-91-generic #102-Ubuntu SMP Fri Nov 5 
> 16:31:28 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
> $ gcc --version
> gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0
> $ ./configure --prefix=/my/prefix  # seems to work fine
> $ make                             # completes successfully
> $ make check
> . . . snip ...
>
> c++ -DHAVE_CONFIG_H -I. -I../..  -I../.. -I../../include 
> -I../../coregrind -I../../include -I../../VEX/pub -I../../VEX/pub 
> -DVGA_amd64=1 -DVGO_linux=1 -DVGP_amd64_linux=1 
> -DVGPV_amd64_linux_vanilla=1    -std=c++17 -Wno-mismatched-new-delete 
>  -MT cxx17_aligned_new-cxx17_aligned_new.o -MD -MP -MF 
> .deps/cxx17_aligned_new-cxx17_aligned_new.Tpo -c -o 
> cxx17_aligned_new-cxx17_aligned_new.o `test -f 'cxx17_aligned_new.cpp' 
> || echo './'`cxx17_aligned_new.cpp
> cxx17_aligned_new.cpp:25:5: error: no matching function for call to 
> 'operator delete'
>     operator delete(myClass, 64U, std::align_val_t(64U));
>     ^~~~~~~~~~~~~~~
> /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/new:154:6: 
> note: candidate function not viable: no known conversion from 
> 'unsigned int' to 'std::align_val_t' for 2nd argument
> void operator delete(void*, std::align_val_t, const std::nothrow_t&)
>

Hi

That's for me.

You are building with the same compiler that was used at configure time?

configure.ac does contain a test for "operator delete(nullptr, 
std::align_val_t(64U));" which I presume passes. It seems strange that 
this passes (a C++17 feature) but the sized overload doesn't (which is a 
combination of C++14 and C++17).


I'm using GCC 11 and in /usr/include/c++/11/new there is


/** These are replaceable signatures:
  *  - normal single new and delete (no arguments, throw @c bad_alloc on 
error)
  *  - normal array new and delete (same)
  *  - @c nothrow single new and delete (take a @c nothrow argument, return
  *    @c NULL on error)
  *  - @c nothrow array new and delete (same)
  *
  *  Placement new and delete signatures (take a memory address argument,
  *  does nothing) may not be replaced by a user's program.
*/
_GLIBCXX_NODISCARD void* operator new(std::size_t) _GLIBCXX_THROW 
(std::bad_alloc)
   __attribute__((__externally_visible__));

SNIP

#if __cpp_aligned_new
_GLIBCXX_NODISCARD void* operator new(std::size_t, std::align_val_t)
   __attribute__((__externally_visible__, __alloc_size__ (1), __malloc__));

SNIP

#if __cpp_sized_deallocation

this is the one we want

void operator delete(void*, std::size_t, std::align_val_t)
   _GLIBCXX_USE_NOEXCEPT __attribute__((__externally_visible__));
void operator delete[](void*, std::size_t, std::align_val_t)
   _GLIBCXX_USE_NOEXCEPT __attribute__((__externally_visible__));
#endif // __cpp_sized_deallocation
#endif // __cpp_aligned_new


Does yours look similar?


Does the following change help


diff --git a/memcheck/tests/cxx17_aligned_new.cpp 
b/memcheck/tests/cxx17_aligned_new.cpp
index 6f574d066..0eeec2ba6 100644
--- a/memcheck/tests/cxx17_aligned_new.cpp
+++ b/memcheck/tests/cxx17_aligned_new.cpp
@@ -22,10 +22,10 @@ int main() {

      // sized versions
      myClass = new MyClass();
-    operator delete(myClass, 64U, std::align_val_t(64U));
+    operator delete(myClass, size_t(64U), std::align_val_t(64U));

      myClass5 = new MyClass[5];
-    operator delete [](myClass5, 320U, std::align_val_t(64U));
+    operator delete [](myClass5, size_t(320U), std::align_val_t(64U));

      MyClass* myClassNt = new (std::nothrow) MyClass;
      operator delete(myClassNt, std::align_val_t(64U), std::nothrow);

(a size_t literal suffix may come one day, but not for a few years at 
least http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p0330r8.html)


A+

Paul

[Valgrind-users] 'make check' for valgrind-3.18.1

[John C. <cr...@gm...>]

Fwiw I'm seeing a failure, snippet below, when running `make check` on
valgrind-3.18.1. The package configures, makes, installs, and, as far as I
can tell, executes successfully.

$ uname -a
Linux foo-Inspiron-3583 5.4.0-91-generic #102-Ubuntu SMP Fri Nov 5 16:31:28
UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
$ gcc --version
gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0
$ ./configure --prefix=/my/prefix  # seems to work fine
$ make                             # completes successfully
$ make check
. . . snip ...

c++ -DHAVE_CONFIG_H -I. -I../..  -I../.. -I../../include -I../../coregrind
-I../../include -I../../VEX/pub -I../../VEX/pub -DVGA_amd64=1 -DVGO_linux=1
-DVGP_amd64_linux=1 -DVGPV_amd64_linux_vanilla=1    -std=c++17
-Wno-mismatched-new-delete  -MT cxx17_aligned_new-cxx17_aligned_new.o -MD
-MP -MF .deps/cxx17_aligned_new-cxx17_aligned_new.Tpo -c -o
cxx17_aligned_new-cxx17_aligned_new.o `test -f 'cxx17_aligned_new.cpp' ||
echo './'`cxx17_aligned_new.cpp
cxx17_aligned_new.cpp:25:5: error: no matching function for call to
'operator delete'
    operator delete(myClass, 64U, std::align_val_t(64U));
    ^~~~~~~~~~~~~~~
/usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/new:154:6:
note: candidate function not viable: no known conversion from 'unsigned
int' to 'std::align_val_t' for 2nd argument
void operator delete(void*, std::align_val_t, const std::nothrow_t&)

Re: [Valgrind-users] Info message

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

In data mercoledì 15 dicembre 2021 10:15:51 CET, David Chapman ha scritto:
Ok. Thanks

> On 12/15/2021 12:34 AM, Domenico Panella wrote:
> > Hi ,
> > 
> > I'm getting this message when I run :
> > 
> > valgrind --leak-check=full ./MyProg
> > 
> > ==4189== HEAP SUMMARY:
> > ==4189==     in use at exit: 192 bytes in 12 blocks
> > ==4189==   total heap usage: 21 allocs, 9 frees, 3,513 bytes allocated
> > ==4189==
> > ==4189== LEAK SUMMARY:
> > ==4189==    definitely lost: 0 bytes in 0 blocks
> > ==4189==    indirectly lost: 0 bytes in 0 blocks
> > ==4189==      possibly lost: 0 bytes in 0 blocks
> > ==4189==    still reachable: 192 bytes in 12 blocks
> > ==4189==         suppressed: 0 bytes in 0 blocks
> > ==4189== Reachable blocks (those to which a pointer was found) are not
> > shown. ==4189== To see them, rerun with: --leak-check=full
> > --show-leak-kinds=all ==4189==
> > ==4189== For lists of detected and suppressed errors, rerun with: -s
> > ==4189== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
> > 
> > I don't see errors but some still reachable blocks.
> > Now, If i run :
> > 
> > valgrind --leak-check=full --show-leak-kinds=all -s ./MyProg
> > 
> > ==7209== HEAP SUMMARY:
> > ==7209==     in use at exit: 192 bytes in 12 blocks
> > ==7209==   total heap usage: 21 allocs, 9 frees, 3,513 bytes allocated
> > ==7209==
> > ==7209== 48 bytes in 6 blocks are still reachable in loss record 1 of 2
> > ==7209==    at 0x48437B5: malloc (in
> > /usr/libexec/valgrind/vgpreload_memcheck- amd64-linux.so)
> > ==7209==    by 0x4D9FC20: ??? (in /usr/lib64/libgcrypt.so.20.3.4)
> > ==7209==    by 0x4D2235C: ??? (in /usr/lib64/libgcrypt.so.20.3.4)
> > ==7209==    by 0x4D197E7: ??? (in /usr/lib64/libgcrypt.so.20.3.4)
> > ==7209==    by 0x4012A6D: call_init (in /usr/lib64/ld-linux-x86-64.so.2)
> > ==7209==    by 0x4012B6B: _dl_init (in /usr/lib64/ld-linux-x86-64.so.2)
> > ==7209==    by 0x40030C9: ??? (in /usr/lib64/ld-linux-x86-64.so.2)
> > ==7209==
> > ==7209== 144 bytes in 6 blocks are still reachable in loss record 2 of 2
> > ==7209==    at 0x48437B5: malloc (in
> > /usr/libexec/valgrind/vgpreload_memcheck- amd64-linux.so)
> > ==7209==    by 0x4D9FC20: ??? (in /usr/lib64/libgcrypt.so.20.3.4)
> > ==7209==    by 0x4D2235C: ??? (in /usr/lib64/libgcrypt.so.20.3.4)
> > ==7209==    by 0x4D197DA: ??? (in /usr/lib64/libgcrypt.so.20.3.4)
> > ==7209==    by 0x4012A6D: call_init (in /usr/lib64/ld-linux-x86-64.so.2)
> > ==7209==    by 0x4012B6B: _dl_init (in /usr/lib64/ld-linux-x86-64.so.2)
> > ==7209==    by 0x40030C9: ??? (in /usr/lib64/ld-linux-x86-64.so.2)
> > ==7209==
> > ==7209== LEAK SUMMARY:
> > ==7209==    definitely lost: 0 bytes in 0 blocks
> > ==7209==    indirectly lost: 0 bytes in 0 blocks
> > ==7209==    possibly lost: 0 bytes in 0 blocks
> > ==7209==    still reachable: 192 bytes in 12 blocks
> > ==7209==    suppressed: 0 bytes in 0 blocks
> > ==7209==
> > ==7209== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
> > 
> > Could you help me to understand if I'm wronging something ?
> 
> A system library (in this case libgcrypt.so) is allocating memory but
> not releasing it (keeping the memory for the life of the program). 
> There are pointers to those memory blocks, so strictly speaking they are
> not lost memory.  Even this is not the fault of your code, so don't
> worry about it.  Your code does not have a memory leak.

Re: [Valgrind-users] Info message

[David C. <dcc...@ac...>]

On 12/15/2021 12:34 AM, Domenico Panella wrote:
> Hi ,
>
> I'm getting this message when I run :
>
> valgrind --leak-check=full ./MyProg
>
> ==4189== HEAP SUMMARY:
> ==4189==     in use at exit: 192 bytes in 12 blocks
> ==4189==   total heap usage: 21 allocs, 9 frees, 3,513 bytes allocated
> ==4189==
> ==4189== LEAK SUMMARY:
> ==4189==    definitely lost: 0 bytes in 0 blocks
> ==4189==    indirectly lost: 0 bytes in 0 blocks
> ==4189==      possibly lost: 0 bytes in 0 blocks
> ==4189==    still reachable: 192 bytes in 12 blocks
> ==4189==         suppressed: 0 bytes in 0 blocks
> ==4189== Reachable blocks (those to which a pointer was found) are not shown.
> ==4189== To see them, rerun with: --leak-check=full --show-leak-kinds=all
> ==4189==
> ==4189== For lists of detected and suppressed errors, rerun with: -s
> ==4189== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
>
> I don't see errors but some still reachable blocks.
> Now, If i run :
>
> valgrind --leak-check=full --show-leak-kinds=all -s ./MyProg
>
> ==7209== HEAP SUMMARY:
> ==7209==     in use at exit: 192 bytes in 12 blocks
> ==7209==   total heap usage: 21 allocs, 9 frees, 3,513 bytes allocated
> ==7209==
> ==7209== 48 bytes in 6 blocks are still reachable in loss record 1 of 2
> ==7209==    at 0x48437B5: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-
> amd64-linux.so)
> ==7209==    by 0x4D9FC20: ??? (in /usr/lib64/libgcrypt.so.20.3.4)
> ==7209==    by 0x4D2235C: ??? (in /usr/lib64/libgcrypt.so.20.3.4)
> ==7209==    by 0x4D197E7: ??? (in /usr/lib64/libgcrypt.so.20.3.4)
> ==7209==    by 0x4012A6D: call_init (in /usr/lib64/ld-linux-x86-64.so.2)
> ==7209==    by 0x4012B6B: _dl_init (in /usr/lib64/ld-linux-x86-64.so.2)
> ==7209==    by 0x40030C9: ??? (in /usr/lib64/ld-linux-x86-64.so.2)
> ==7209==
> ==7209== 144 bytes in 6 blocks are still reachable in loss record 2 of 2
> ==7209==    at 0x48437B5: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-
> amd64-linux.so)
> ==7209==    by 0x4D9FC20: ??? (in /usr/lib64/libgcrypt.so.20.3.4)
> ==7209==    by 0x4D2235C: ??? (in /usr/lib64/libgcrypt.so.20.3.4)
> ==7209==    by 0x4D197DA: ??? (in /usr/lib64/libgcrypt.so.20.3.4)
> ==7209==    by 0x4012A6D: call_init (in /usr/lib64/ld-linux-x86-64.so.2)
> ==7209==    by 0x4012B6B: _dl_init (in /usr/lib64/ld-linux-x86-64.so.2)
> ==7209==    by 0x40030C9: ??? (in /usr/lib64/ld-linux-x86-64.so.2)
> ==7209==
> ==7209== LEAK SUMMARY:
> ==7209==    definitely lost: 0 bytes in 0 blocks
> ==7209==    indirectly lost: 0 bytes in 0 blocks
> ==7209==    possibly lost: 0 bytes in 0 blocks
> ==7209==    still reachable: 192 bytes in 12 blocks
> ==7209==    suppressed: 0 bytes in 0 blocks
> ==7209==
> ==7209== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
>
> Could you help me to understand if I'm wronging something ?
A system library (in this case libgcrypt.so) is allocating memory but 
not releasing it (keeping the memory for the life of the program).  
There are pointers to those memory blocks, so strictly speaking they are 
not lost memory.  Even this is not the fault of your code, so don't 
worry about it.  Your code does not have a memory leak.

-- 
     David Chapman      dcc...@ac...
     Chapman Consulting -- San Jose, CA
     EDA Software Developer, Expert Witness
     www.chapman-consulting-sj.com
     2018-2019 Chair, IEEE Consultants' Network of Silicon Valley

Re: [Valgrind-users] Info message

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

> Could you help me to understand if I'm wronging something ?

Hi

This probably just means that libgcrypt is allocating some memory that 
it doesn't free. It's called in _dl_init, when the library is loaded) so 
it is most likely a one-off allocation and not dangerous.

You have 2 choices. Either get debuginfo or a debug build for libgcrypt 
and find out exactly what is happening. Then you would need to either 
fix it yourself or get it fixed upstream.

Alternatively (and much easier) is to use a suppression file.

Run

valgrind --leak-check=full --show-leak-kinds=all -s --gen-suppressions=all ./MyProg

Copy and paste the suppresson file, editing it a bit to give a meaningful name and maybe reducing the calstack and/or using some wildcards (look at default.suppr for examples).

Then run

valgrind --leak-check=full --show-leak-kinds=all -s --suppressions=myprog.supp ./MyProg

A+
Paul

[Valgrind-users] Info message

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

Hi ,

I'm getting this message when I run :

valgrind --leak-check=full ./MyProg

==4189== HEAP SUMMARY:
==4189==     in use at exit: 192 bytes in 12 blocks
==4189==   total heap usage: 21 allocs, 9 frees, 3,513 bytes allocated
==4189== 
==4189== LEAK SUMMARY:
==4189==    definitely lost: 0 bytes in 0 blocks
==4189==    indirectly lost: 0 bytes in 0 blocks
==4189==      possibly lost: 0 bytes in 0 blocks
==4189==    still reachable: 192 bytes in 12 blocks
==4189==         suppressed: 0 bytes in 0 blocks
==4189== Reachable blocks (those to which a pointer was found) are not shown.
==4189== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==4189== 
==4189== For lists of detected and suppressed errors, rerun with: -s
==4189== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

I don't see errors but some still reachable blocks. 
Now, If i run :

valgrind --leak-check=full --show-leak-kinds=all -s ./MyProg

==7209== HEAP SUMMARY:
==7209==     in use at exit: 192 bytes in 12 blocks
==7209==   total heap usage: 21 allocs, 9 frees, 3,513 bytes allocated
==7209== 
==7209== 48 bytes in 6 blocks are still reachable in loss record 1 of 2
==7209==    at 0x48437B5: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-
amd64-linux.so)
==7209==    by 0x4D9FC20: ??? (in /usr/lib64/libgcrypt.so.20.3.4)
==7209==    by 0x4D2235C: ??? (in /usr/lib64/libgcrypt.so.20.3.4)
==7209==    by 0x4D197E7: ??? (in /usr/lib64/libgcrypt.so.20.3.4)
==7209==    by 0x4012A6D: call_init (in /usr/lib64/ld-linux-x86-64.so.2)
==7209==    by 0x4012B6B: _dl_init (in /usr/lib64/ld-linux-x86-64.so.2)
==7209==    by 0x40030C9: ??? (in /usr/lib64/ld-linux-x86-64.so.2)
==7209== 
==7209== 144 bytes in 6 blocks are still reachable in loss record 2 of 2
==7209==    at 0x48437B5: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-
amd64-linux.so)
==7209==    by 0x4D9FC20: ??? (in /usr/lib64/libgcrypt.so.20.3.4)
==7209==    by 0x4D2235C: ??? (in /usr/lib64/libgcrypt.so.20.3.4)
==7209==    by 0x4D197DA: ??? (in /usr/lib64/libgcrypt.so.20.3.4)
==7209==    by 0x4012A6D: call_init (in /usr/lib64/ld-linux-x86-64.so.2)
==7209==    by 0x4012B6B: _dl_init (in /usr/lib64/ld-linux-x86-64.so.2)
==7209==    by 0x40030C9: ??? (in /usr/lib64/ld-linux-x86-64.so.2)
==7209== 
==7209== LEAK SUMMARY:
==7209==    definitely lost: 0 bytes in 0 blocks
==7209==    indirectly lost: 0 bytes in 0 blocks
==7209==    possibly lost: 0 bytes in 0 blocks
==7209==    still reachable: 192 bytes in 12 blocks
==7209==    suppressed: 0 bytes in 0 blocks
==7209== 
==7209== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

Could you help me to understand if I'm wronging something ?

[Valgrind-users] Virtual Valgrind Fosdem Devroom

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

Hi valgrind hackers,

Valgrind will participate in the Virtual Fosdem on Sunday 6 February
2022 https://fosdem.org/2022/schedule/track/valgrind/

We would like to invite people to propose talks on valgrind by
submitting a talk proposal to 
https://penta.fosdem.org/submission/FOSDEM22
Please select the "Valgrind Devroom" Track.
(If you have any trouble creating a penta login or submission please
contact Julian and me with your proposal.)

Because Fosdem will be virtual this year we will likely ask talks to be
pre-recorded in advance and after playing your presentation we will do
a live Q/A session using Jitsi and Matrix.

Please pick a time that includes the length of your (recorded) talk
plus ~15 minutes Q/A.

We would like to finalize the schedule the first week of January so
that people have enough time to record their talk, so please submit
your proposals before the end of year (31 December 2021).

Some possible topics for talks/discussions are:

- New (or recently added) ports.
- New CPU (instruction) support.
- New (ideas/prototypes) of valgrind tools.
- Valgrind release/bugfixing strategy/policy.
- Advances in gdbserver and the GDB remote serial protocol.
- DWARF, debuginfo, symbols and debuginfod servers.
- Using valgrind with "safe" languages (Rust).
- Adding/Testing Valgrind syscalls support.
- Infrastructure changes (speedups) to the Valgrind JIT framework.
- Your interesting use case with Valgrind.

Sincerely,

Mark & Julian

Re: [Valgrind-users] Using Valgrind with custom memory management

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

Did you see this?

https://valgrind.org/docs/manual/mc-manual.html#mc-manual.mempools

On Thu, Nov 18, 2021 at 10:53 AM Abhijit Gokaraju <Abh...@rb...>
wrote:

> Hello Valgrind team,
>
>
>
> We have an application which uses its own memory management (e.g. allocate
> buffer pools of specific sizes).
>
> So, the calls to allocate/free memory do not result in calls to
> malloc()/free().
>
> Only when the buffer pools need more memory, there are calls to
> malloc()/free().
>
>
>
> Could you please suggest if Valgrind has provisions to help detect memory
> leaks, for applications such as ours.
>
> Thanks & Regards,
>
> Abhijit
>
> Notice: This e-mail together with any attachments may contain information
> of Ribbon Communications Inc. and its Affiliates that is confidential
> and/or proprietary for the sole use of the intended recipient. Any review,
> disclosure, reliance or distribution by others or forwarding without
> express permission is strictly prohibited. If you are not the intended
> recipient, please notify the sender immediately and then delete all copies,
> including any attachments.
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>


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

Re: [Valgrind-users] Using Valgrind with custom memory management

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

 

> Could you please suggest if Valgrind has provisions to help detect memory leaks, for applications such as ours.


Hi Abhijit

Yes, Valgrind has provisions for this. It will, however, require you to modify your code.

The procedure is documented in the manual here https://valgrind.org/docs/manual/mc-manual.html#mc-manual.mempools

A+
Paul

[Valgrind-users] Using Valgrind with custom memory management

[Abhijit G. <Abh...@rb...>]

Hello Valgrind team,

We have an application which uses its own memory management (e.g. allocate buffer pools of specific sizes).
So, the calls to allocate/free memory do not result in calls to malloc()/free().
Only when the buffer pools need more memory, there are calls to malloc()/free().

Could you please suggest if Valgrind has provisions to help detect memory leaks, for applications such as ours.
Thanks & Regards,
Abhijit

Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments.

[Valgrind-users] Valgrind-3.18.1 is available

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

We are pleased to announce a new release of Valgrind, version 3.18.1,
available from http://valgrind.org/downloads/current.html.

3.18.1 fixes a number of bugs and adds support for glibc-2.34, and for new
platforms x86/FreeBSD and amd64/FreeBSD.  Debuginfo reading is faster, and
Rust demangling has been improved. For PPC64, ISA 3.1 support has been
completed, and some newer ARM64 and S390 instructions are also supported.  See
the release notes below for details of changes.  Note, 3.18.0 had no formal
release -- it was pulled at the last minute due to a packaging problem.

Our thanks to all those who contribute to Valgrind's development.  This
release represents a great deal of time, energy and effort on the part of many
people.

Happy and productive debugging and profiling,

-- The Valgrind Developers


Release 3.18.0 (15 Oct 2021)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~

This release supports X86/Linux, AMD64/Linux, ARM32/Linux, ARM64/Linux,
PPC32/Linux, PPC64BE/Linux, PPC64LE/Linux, S390X/Linux, MIPS32/Linux,
MIPS64/Linux, ARM/Android, ARM64/Android, MIPS32/Android, X86/Android,
X86/Solaris, AMD64/Solaris, AMD64/MacOSX 10.12, X86/FreeBSD and
AMD64/FreeBSD.  There is also preliminary support for X86/macOS 10.13,
AMD64/macOS 10.13 and nanoMIPS/Linux.

* ==================== CORE CHANGES ===================

* The libiberty demangler has been updated, which brings support for
  Rust v0 name demangling

* __libc_freeres isn't called anymore after the program recieves a
  fatal signal. Causing some internal glibc resources to hang around,
  but preventing any crashes after the program has ended.

* The DWARF reader is now very much faster at startup when just
  --read-inline-info=yes (the default in most cases) is given.

* glibc 2.34, which moved various functions from libpthread.so into
  libc.so, is now supported.

* ================== PLATFORM CHANGES =================

* arm64:

  - v8.2 scalar and vector FABD, FACGE, FACGT and FADD.
  - v8.2 FP compare & conditional compare instructions.
  - Zero variants of v8.2 FP compare instructions.

* s390:

  - Support the miscellaneous-instruction-extensions facility 3 and
    the vector-enhancements facility 2.  This enables programs
    compiled with "-march=arch13" or "-march=z15" to be executed
    under Valgrind.

* ppc64:

  - ISA 3.1 support is now complete
  - ISA 3.0 support for the darn instruction added.
  - ISA 3.0 support for the vector system call instruction scv added.
  - ISA 3.0 support for the copy, paste and cpabort instructions added.

* Support for X86/FreeBSD and AMD64/FreeBSD has been added.

* ==================== OTHER CHANGES ====================

* Memcheck on amd64: minor fixes to remove some false positive
  undef-value errors

* ==================== FIXED BUGS ====================

The following bugs have been fixed or resolved.  Note that "n-i-bz"
stands for "not in bugzilla" -- that is, a bug that was reported to us
but never got a bugzilla entry.  We encourage you to file bugs in
bugzilla (https://bugs.kde.org/enter_bug.cgi?product=valgrind) rather
than mailing the developers (or mailing lists) directly -- bugs that
are not entered into bugzilla tend to get forgotten about or ignored.

208531  [PATCH]: FreeBSD support for valgrind
368960  WARNING: unhandled amd64-linux syscall: 163 (acct)
407589  [Linux] Add support for C11 aligned_alloc() and GNU reallocarray()
423963  Error in child thread when CLONE_PIDFD is used
426148  crash with "impossible happened" when running BPF CO-RE programs
429375  PPC ISA 3.1 support is missing, part 9
431157  PPC_FEATURE2_SCV needs to be masked in AT_HWCAP2
431306  Update demangler to support Rust v0 name mangling
432387  s390x: z15 instructions support
433437  FreeBSD support, part 1
433438  FreeBSD support, part 2
433439  FreeBSD support, part 3
433469  FreeBSD support, part 4
433473  FreeBSD support, part 5
433477  FreeBSD support, part 6
433479  FreeBSD support, part 7
433504  FreeBSD support, part 8
433506  FreeBSD support, part 9
433507  FreeBSD support, part 10
433508  FreeBSD support, part 11
433510  FreeBSD support, part 12
433801  PPC ISA 3.1 support is missing, part 10 (ISA 3.1 support complete)
433863  s390x: memcheck/tests/s390x/{cds,cs,csg} failures
434296  s390x: False-positive memcheck diagnostics from vector string
        instructions
434840  PPC64 darn instruction not supported
435665  PPC ISA 3.0 copy, paste, cpabort instructions are not supported
435908  valgrind tries to fetch from deubginfod for files which already
        have debug information
438871  unhandled instruction bytes: 0xF3 0x49 0xF 0x6F 0x9C 0x24 0x60 0x2
439046  valgrind is unusably large when linked with lld
439090  Implement close_range(2)
439326  Valgrind 3.17.0 won't compile with Intel 2021 oneAPI compilers
439590  glibc-2.34 breaks suppressions against obj:*/lib*/libc-2.*so*
440670  unhandled ppc64le-linux syscall: 252 statfs64 and 253 fstatfs64
440906  Fix impossible constraint issue in P10 testcase.
441512  Remove a unneeded / unnecessary prefix check.
441534  Update the expected output for test_isa_3_1_VRT.
442061  very slow execution under Fedora 34 (readdwarf3)
443031  Gcc -many change requires explicit .machine directives
443033  Add support for the ISA 3.0 mcrxrx instruction
443034  Sraw, srawi, srad, sradi, mfs
443178  Powerpc, test jm-mfspr expected output needs to be updated.
443179  Need new test for the lxvx and stxvx instructions on ISA 2.07 and
        ISA 3.0 systems.
443180  The subnormal test and the ISA 3.0 test generate compiler warnings
443314  In the latest GIT version, Valgrind with "--trace-flags" crashes
        at "al" register
443605  Don't call final_tidyup (__libc_freeres) on FatalSignal

To see details of a given bug, visit
  https://bugs.kde.org/show_bug.cgi?id=XXXXXX
where XXXXXX is the bug number as listed below.

(3.18.0.RC1: 12 Oct 2021)
(3.18.0:     15 Oct 2021)

MD5SUM:  de56a5532b0c81781db677ca712c585a         valgrind-3.18.1.tar.bz2
SHA1SUM: 0a694a8d0c2152978bf64b67ad0b3dd972bbeb54 valgrind-3.18.1.tar.bz2

Re: [Valgrind-users] Possible bug in valgrind uninitialized variable detection (negative array index)

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

At 2021-11-10 01:18Z, Kyryl Melekhin wrote:
> Ok, stop. I forgot, the executables likely won't work because my MuslC was
> -march native optimized. And obviously static linking will include that code.

Whn I look at this file:
     $ ls -l piketcc  # compiled by tcc
     -rwxr-xr-x. 1 user group 80208 Nov 10 20:38Z  piketcc
     $ sha256sum piketcc
     6579786352c53de2fc8dc8322b866256870b911fc1b700202889b6fee9a45ff4  piketcc

disassembled by gdb, and next examined in a text editor, then I see
curious manipulation of the stack pointer %rsp:

Dump of assembler code for function re_pikevm:  [VLA = Variable-Length Array]
:g/%rsp,/p   ## direct reads of the stack pointer
    0x000000000040235f <+1>:     mov    %rsp,%rbp  # Frame pointer at entry
    0x00000000004023e1 <+131>:   mov    %rsp,-0x88(%rbp)  # remember the address of a VLA
    0x00000000004023f2 <+148>:   mov    %rsp,-0x80(%rbp)
    0x0000000000402416 <+184>:   mov    %rsp,-0x98(%rbp)
    0x000000000040243d <+223>:   mov    %rsp,-0xa8(%rbp)
    0x0000000000402489 <+299>:   mov    %rsp,-0x7a1f8(%rbp)
    0x00000000004024b3 <+341>:   mov    %rsp,-0x7a208(%rbp)

:g/,%rsp/p   ## writes to the stack pointer
    0x0000000000402362 <+4>:     sub    $0x7a240,%rsp  # allocate fixed portion of stack frame
    0x00000000004023eb <+141>:   sub    %rax,%rsp  # allocate a VLA: %rsp -= %rax
    0x00000000004023ee <+144>:   and    $0xfffffffffffffff0,%rsp  # 16-byte align a VLA
    0x000000000040240f <+177>:   sub    %rax,%rsp
    0x0000000000402412 <+180>:   and    $0xfffffffffffffff0,%rsp
    0x0000000000402436 <+216>:   sub    %rax,%rsp
    0x0000000000402439 <+219>:   and    $0xfffffffffffffff0,%rsp
    0x0000000000402482 <+292>:   sub    %rax,%rsp
    0x0000000000402485 <+295>:   and    $0xfffffffffffffff0,%rsp
    0x00000000004024ac <+334>:   sub    %rax,%rsp
    0x00000000004024af <+337>:   and    $0xfffffffffffffff0,%rsp
    0x00000000004024fa <+412>:   mov    -0x88(%rbp),%rsp
    0x00000000004026c4 <+870>:   mov    -0x7a208(%rbp),%rsp
    0x00000000004026ec <+910>:   mov    -0x7a208(%rbp),%rsp
    0x00000000004026f3 <+917>:   mov    -0x7a208(%rbp),%rsp
    0x000000000040272c <+974>:   mov    -0x7a208(%rbp),%rsp
    0x000000000040278d <+1071>:  mov    -0x7a208(%rbp),%rsp
    0x00000000004027de <+1152>:  mov    -0x7a208(%rbp),%rsp
    0x0000000000402e3e <+2784>:  mov    -0x7a208(%rbp),%rsp
    0x0000000000402e8c <+2862>:  mov    -0x7a208(%rbp),%rsp
    0x0000000000402f63 <+3077>:  mov    -0x7a208(%rbp),%rsp
    0x0000000000402fbc <+3166>:  mov    -0x7a208(%rbp),%rsp
    0x000000000040309c <+3390>:  mov    -0x7a208(%rbp),%rsp
    0x00000000004030fd <+3487>:  mov    -0x7a208(%rbp),%rsp
    0x000000000040314e <+3568>:  mov    -0x7a208(%rbp),%rsp
    0x0000000000403683 <+4901>:  mov    -0x88(%rbp),%rsp
    0x0000000000403813 <+5301>:  mov    -0x88(%rbp),%rsp
    0x0000000000403824 <+5318>:  mov    -0x88(%rbp),%rsp


When run with command-line arguments "./piketcc abc abc", then examination
of all the "mov -0x7a208(%rbp),%rsp" instructions shows that the value
in register %rsp does not change.  I wonder if valgrind does something
strange here, such as marking some portion of the fixed frame as uninit
even though nothing changes.

The corresponding pikegcc never re-loads %rsp after allocating the VLAs:
     $ ls -l pikegcc
     -rwxr-xr-x. 1 user group 72960 Nov 10 20:37Z pikegcc
     $ sha256sum pikegcc
     952ce60eb5f66445f08d8ffc14b348febdefc99f4985cd4e725ae3d1682246c8  pikegcc

:g/%rsp,/p  # direct reads of stack pointer %rsp
    0x40328d <re_pikevm+1>:      mov    %rsp,%rbp
    0x000000000040328d <+1>:     mov    %rsp,%rbp
    0x00000000004032ca <+62>:    mov    %rsp,%rax
    0x0000000000403395 <+265>:   mov    %rsp,%rax
    0x0000000000403406 <+378>:   mov    %rsp,%rax
    0x0000000000403489 <+509>:   mov    %rsp,%rax
    0x0000000000403523 <+663>:   mov    %rsp,%rax
    0x00000000004035a7 <+795>:   mov    %rsp,%rax
:g/,%rsp/p  # writes to register %rsp
    0x403299 <re_pikevm+13>:     sub    $0x7a298,%rsp
    0x0000000000403299 <+13>:    sub    $0x7a298,%rsp
    0x0000000000403392 <+262>:   sub    %rax,%rsp  # allocate VLA; %rax is pre-aligned to (0 mod 16)
    0x0000000000403403 <+375>:   sub    %rax,%rsp
    0x0000000000403486 <+506>:   sub    %rax,%rsp
    0x0000000000403520 <+660>:   sub    %rax,%rsp
    0x00000000004035a4 <+792>:   sub    %rax,%rsp
    0x0000000000404956 <+5834>:  mov    %rbx,%rsp
    0x000000000040496d <+5857>:  lea    -0x28(%rbp),%rsp  # begin subroutine epilog

Investigation continues...

Re: [Valgrind-users] Possible bug in valgrind uninitialized variable detection (negative array index)

[Kyryl M. <k.m...@gm...>]

I think I might have an idea about the cause of this error now.
If you read the CodingStyle file located at the root of tcc directory
it mentions:
"
- Test with Valgrind to detect some uses of uninitialised values:
make clean
./configure
make
# On Intel, because Valgrind does floating-point arithmetic differently:
( cd tests && gcc -I.. tcctest.c && valgrind -q ./a.out > test.ref )
make test TCC="valgrind -q --leak-check=full `pwd`/tcc -B`pwd` -I`pwd`"
(Because of how VLAs are implemented, invalid reads are expected
with 79_vla_continue.)"

This file has not been updated in 6 years, but I know for a fact
that there have been some patches and fixes applied to VLAs
in that time. My code does make extensive use of VLA and that
might be the offending root cause here. But now I am 100%
sure what the problem is. If I replace the VLA with malloc
the error vanishes.

So the question is up for debate: tcc generates VLA code that
seems wrong in the eyes of valgrind. Though this code is not
necessarily invalid. If the code is not invalid then it must be
valgrind fault and not tcc.

Re: [Valgrind-users] Possible bug in valgrind uninitialized variable detection (negative array index)

[Kyryl M. <k.m...@gm...>]

Ok, stop. I forgot, the executables likely won't work because my MuslC was
-march native optimized. And obviously static linking will include that code.

I've updated the executables and verified that they do indeed run on lower spec
hardware.

Re: [Valgrind-users] Possible bug in valgrind uninitialized variable detection (negative array index)

[Kyryl M. <k.m...@gm...>]

(This is a CC to mailing list)
Hello John,

Thanks for the suggestion.
Here are the executables (both statically linked with musl, they will
work under any linux kernel 2.0+):
This is my personal website, feel free to download.
https://kyryl.tk/pikegcc
https://kyryl.tk/piketcc

both compiled with
tcc pike.c -g -static -o piketcc
gcc pike.c -g -static -o pikegcc

gcc 11.20 release
tcc (git+git://repo.or.cz/tinycc.git) last commit

My software build environment is nothing too out of the ordinary, it's
all bleeding edge
from the git repos. I don't run some hopelessly outdated system or
anything like that.
Personally I would find it simple to recreate from source, but
anyways, here is a screenshot
to better aid in understanding what I am looking at.

https://kyryl.tk/2021-11-10-002850_2559x1413_scrot.png

What's interesting is even if there is an error and tcc produces bad code,
how to does it manage to pass 150+ various test cases non stop
for a few hours without faulting once, if as you can see on the screenshot
the error gets detected in the simplest of cases imaginable.

It seems very likely that valgrind is at fault here. Both gcc and clang
compiled versions work with no errors from valgrind on any optimization level.