valgrind-users — General discussion list for Valgrind users

Re: [Valgrind-users] Timer delete

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

On 11/11/22 13:23, Domenico Panella wrote:
> Operating System: Slackware 15.0 (Current) Kernel Version: 5.19.17 (64-bit) Graphics Platform: X11 Processors: 8 × Intel® Core™ i7-8565U CPU @ 1.80GHz
> 
> A small example:
> 
> #include<stdbool.h>
  [[snip horrible formatting]]
> 

It's a bug (or implementation constraint) in glibc timer.

When I run it under valgrind-3.19.0 with glibc-debuginfo and glibc-debugsource
installed (2.35-17.fc36.x86_64):  [Notice the annotation "LOOK HERE"]
=====
$ valgrind --leak-check=full --sim-hints=no-nptl-pthread-stackcache ./a.out
==281161== Memcheck, a memory error detector
==281161== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==281161== Using Valgrind-3.19.0 and LibVEX; rerun with -h for copyright info
==281161== Command: ./a.out
==281161==
--281161:0:   sched WARNING: pthread stack cache cannot be disabled!  <<<<< LOOK HERE <<<<<
==281161==
==281161== HEAP SUMMARY:
==281161==     in use at exit: 272 bytes in 1 blocks
==281161==   total heap usage: 3 allocs, 2 frees, 512 bytes allocated
==281161==
==281161== 272 bytes in 1 blocks are possibly lost in loss record 1 of 1
==281161==    at 0x484A464: calloc (vg_replace_malloc.c:1328)
==281161==    by 0x4012E42: UnknownInlinedFun (rtld-malloc.h:44)
==281161==    by 0x4012E42: allocate_dtv (dl-tls.c:375)
==281161==    by 0x4013841: _dl_allocate_tls (dl-tls.c:634)
==281161==    by 0x48F5A98: allocate_stack (allocatestack.c:428)
==281161==    by 0x48F5A98: pthread_create@@GLIBC_2.34 (pthread_create.c:647)
==281161==    by 0x4900864: __timer_start_helper_thread (timer_routines.c:147)
==281161==    by 0x48F9E36: __pthread_once_slow (pthread_once.c:116)
==281161==    by 0x49002CA: timer_create@@GLIBC_2.34 (timer_create.c:70)
==281161==    by 0x4011E2: main (timer.c:40)
==281161==
==281161== LEAK SUMMARY:
==281161==    definitely lost: 0 bytes in 0 blocks
==281161==    indirectly lost: 0 bytes in 0 blocks
==281161==      possibly lost: 272 bytes in 1 blocks
==281161==    still reachable: 0 bytes in 0 blocks
==281161==         suppressed: 0 bytes in 0 blocks
==281161==
==281161== For lists of detected and suppressed errors, rerun with: -s
==281161== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
=====

Re: [Valgrind-users] Timer delete

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

Operating System: Slackware 15.0 (Current) Kernel Version: 5.19.17 
(64-bit) Graphics Platform: X11 Processors: 8 × Intel® Core™ i7-8565U 
CPU @ 1.80GHz

A small example:

#include<stdbool.h>

#include<stdlib.h>

#include<assert.h>

#include<time.h>

#include<string.h>

#include<stdio.h>

#include<ctype.h>

#include<sys/time.h>

#include<stddef.h>

#include<errno.h>

#include<math.h>

#include<sys/types.h>

#include<inttypes.h>

#include<signal.h>

void

expired(){

printf("Test");

}

intmain()

{

intrv=0;

longinterval=30;

timer_ttimerId=0;

constchar*data=NULL;

structsigeventsev={0};

structitimerspecits={.it_value.tv_sec=1,

.it_value.tv_nsec=0,

.it_interval.tv_sec=interval,

.it_interval.tv_nsec=0

};

sev.sigev_notify=SIGEV_THREAD;

sev.sigev_notify_function=&expired;

sev.sigev_value.sival_ptr=&data;

/*Createtimer*/

rv=timer_create(CLOCK_REALTIME,&sev,&timerId);

rv=timer_delete(timerId);

returnrv;

}


valgrind --leak-check=full --sim-hints=no-nptl-pthread-stackcache main 
==5693== Memcheck, a memory error detector ==5693== Copyright (C) 
2002-2022, and GNU GPL'd, by Julian Seward et al. ==5693== Using 
Valgrind-3.19.0 and LibVEX; rerun with -h for copyright info ==5693== 
Command: wrapper ==5693== --5693:0:   sched WARNING: pthread stack cache 
cannot be disabled! ==5693== ==5693== HEAP SUMMARY: ==5693==     in use 
at exit: 272 bytes in 1 blocks ==5693==   total heap usage: 3 allocs, 2 
frees, 512 bytes allocated ==5693== ==5693== 272 bytes in 1 blocks are 
possibly lost in loss record 1 of 1 ==5693==    at 0x48475FF: calloc 
(vg_replace_malloc.c:1328) ==5693==    by 0x4012075: _dl_allocate_tls 
(in /lib64/ld-2.36.so) ==5693==    by 0x4916B49: 
pthread_create@@GLIBC_2.34 (in /lib64/libc-2.36.so) ==5693==    by 
0x492122D: __timer_start_helper_thread (in /lib64/libc-2.36.so) ==5693== 
    by 0x491AE66: __pthread_once_slow (in /lib64/libc-2.36.so) ==5693== 
    by 0x4920D3A: timer_create@@GLIBC_2.34 (in /lib64/libc-2.36.so) 
==5693==    by 0x4011E2: main (timer_delete.c:37) ==5693== ==5693== LEAK 
SUMMARY: ==5693==    definitely lost: 0 bytes in 0 blocks ==5693== 
    indirectly lost: 0 bytes in 0 blocks ==5693==      possibly lost: 
272 bytes in 1 blocks ==5693==    still reachable: 0 bytes in 0 blocks 
==5693==         suppressed: 0 bytes in 0 blocks ==5693== ==5693== For 
lists of detected and suppressed errors, rerun with: -s ==5693== ERROR 
SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

Domenico


Il 11/11/22 18:13, Paul Floyd ha scritto:
>
>
> On 11/11/22 17:47, Domenico Panella wrote:
>> Hi,
>>
>> I am getting a memory leak in my program about timer_delete function.
>>
>> According valgrind output,
>>
>> It seems that the timer_delete function doesn't release the memory.
>>
>> ==18483== HEAP SUMMARY:
>> ==18483==     in use at exit: 272 bytes in 1 blocks
>> ==18483==   total heap usage: 54 allocs, 53 frees, 9,354 bytes allocated
>> ==18483==
>> ==18483== 272 bytes in 1 blocks are possibly lost in loss record 1 of 1
>> ==18483==    at 0x48475FF: calloc (vg_replace_malloc.c:1328)
>> ==18483==    by 0x4012075: _dl_allocate_tls (in /lib64/ld-2.36.so)
>> ==18483==    by 0x491EB49: pthread_create@@GLIBC_2.34 (in 
>> /lib64/libc-2.36.so)
>> ==18483==    by 0x492922D: __timer_start_helper_thread (in 
>> /lib64/libc-2.36.so)
>> ==18483==    by 0x4922E66: __pthread_once_slow (in /lib64/libc-2.36.so)
>> ==18483==    by 0x4928D3A: timer_create@@GLIBC_2.34 (in 
>> /lib64/libc-2.36.so)
>> ==18483==    by 0x401711: main (main.c:224)
>> ==18483==
>> ==18483== LEAK SUMMARY:
>> ==18483==    definitely lost: 0 bytes in 0 blocks
>> ==18483==    indirectly lost: 0 bytes in 0 blocks
>> ==18483==      possibly lost: 272 bytes in 1 blocks
>> ==18483==    still reachable: 0 bytes in 0 blocks
>> ==18483==         suppressed: 0 bytes in 0 blocks
>> ==18483==
>> ==18483== For lists of detected and suppressed errors, rerun with: -s
>> ==18483== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
>>
>> What do i wrong?
>
> Which OS and CPU?
>
> Is this repeatable?
>
> It's possible that this is some memory that ought to be freed by the 
> glibc freeres function.
>
> Can you also post a small examp,e that reproduces the issue?
>
> A+
> Paul
>
>
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Timer delete

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

On Fri, 2022-11-11 at 18:13 +0100, Paul Floyd wrote:
> 
> On 11/11/22 17:47, Domenico Panella wrote:
> > Hi,
> > 
> > I am getting a memory leak in my program about timer_delete function.
> > 
> > According valgrind output,
> > 
> > It seems that the timer_delete function doesn't release the memory.
> > 
> > ==18483== HEAP SUMMARY:
> > ==18483==     in use at exit: 272 bytes in 1 blocks
> > ==18483==   total heap usage: 54 allocs, 53 frees, 9,354 bytes allocated
> > ==18483==
> > ==18483== 272 bytes in 1 blocks are possibly lost in loss record 1 of 1
> > ==18483==    at 0x48475FF: calloc (vg_replace_malloc.c:1328)
> > ==18483==    by 0x4012075: _dl_allocate_tls (in /lib64/ld-2.36.so)
> > ==18483==    by 0x491EB49: pthread_create@@GLIBC_2.34 (in 
> > /lib64/libc-2.36.so)
> > ==18483==    by 0x492922D: __timer_start_helper_thread (in 
> > /lib64/libc-2.36.so)
> > ==18483==    by 0x4922E66: __pthread_once_slow (in /lib64/libc-2.36.so)
> > ==18483==    by 0x4928D3A: timer_create@@GLIBC_2.34 (in 
> > /lib64/libc-2.36.so)
> > ==18483==    by 0x401711: main (main.c:224)
> > ==18483==
> > ==18483== LEAK SUMMARY:
> > ==18483==    definitely lost: 0 bytes in 0 blocks
> > ==18483==    indirectly lost: 0 bytes in 0 blocks
> > ==18483==      possibly lost: 272 bytes in 1 blocks
> > ==18483==    still reachable: 0 bytes in 0 blocks
> > ==18483==         suppressed: 0 bytes in 0 blocks
> > ==18483==
> > ==18483== For lists of detected and suppressed errors, rerun with: -s
> > ==18483== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
> > 
> > What do i wrong?
> 
> Which OS and CPU?
> 
> Is this repeatable?
> 
> It's possible that this is some memory that ought to be freed by the 
> glibc freeres function.
Possibly --sim-hints=no-nptl-pthread-stackcache might help (if I re-read the manual entry
for this sim-hint).

Philippe

Re: [Valgrind-users] Timer delete

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

On 11/11/22 17:47, Domenico Panella wrote:
> Hi,
> 
> I am getting a memory leak in my program about timer_delete function.
> 
> According valgrind output,
> 
> It seems that the timer_delete function doesn't release the memory.
> 
> ==18483== HEAP SUMMARY:
> ==18483==     in use at exit: 272 bytes in 1 blocks
> ==18483==   total heap usage: 54 allocs, 53 frees, 9,354 bytes allocated
> ==18483==
> ==18483== 272 bytes in 1 blocks are possibly lost in loss record 1 of 1
> ==18483==    at 0x48475FF: calloc (vg_replace_malloc.c:1328)
> ==18483==    by 0x4012075: _dl_allocate_tls (in /lib64/ld-2.36.so)
> ==18483==    by 0x491EB49: pthread_create@@GLIBC_2.34 (in 
> /lib64/libc-2.36.so)
> ==18483==    by 0x492922D: __timer_start_helper_thread (in 
> /lib64/libc-2.36.so)
> ==18483==    by 0x4922E66: __pthread_once_slow (in /lib64/libc-2.36.so)
> ==18483==    by 0x4928D3A: timer_create@@GLIBC_2.34 (in 
> /lib64/libc-2.36.so)
> ==18483==    by 0x401711: main (main.c:224)
> ==18483==
> ==18483== LEAK SUMMARY:
> ==18483==    definitely lost: 0 bytes in 0 blocks
> ==18483==    indirectly lost: 0 bytes in 0 blocks
> ==18483==      possibly lost: 272 bytes in 1 blocks
> ==18483==    still reachable: 0 bytes in 0 blocks
> ==18483==         suppressed: 0 bytes in 0 blocks
> ==18483==
> ==18483== For lists of detected and suppressed errors, rerun with: -s
> ==18483== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
> 
> What do i wrong?

Which OS and CPU?

Is this repeatable?

It's possible that this is some memory that ought to be freed by the 
glibc freeres function.

Can you also post a small examp,e that reproduces the issue?

A+
Paul

[Valgrind-users] Timer delete

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

Hi,

I am getting a memory leak in my program about timer_delete function.

According valgrind output,

It seems that the timer_delete function doesn't release the memory.

==18483== HEAP SUMMARY:
==18483==     in use at exit: 272 bytes in 1 blocks
==18483==   total heap usage: 54 allocs, 53 frees, 9,354 bytes allocated
==18483==
==18483== 272 bytes in 1 blocks are possibly lost in loss record 1 of 1
==18483==    at 0x48475FF: calloc (vg_replace_malloc.c:1328)
==18483==    by 0x4012075: _dl_allocate_tls (in /lib64/ld-2.36.so)
==18483==    by 0x491EB49: pthread_create@@GLIBC_2.34 (in 
/lib64/libc-2.36.so)
==18483==    by 0x492922D: __timer_start_helper_thread (in 
/lib64/libc-2.36.so)
==18483==    by 0x4922E66: __pthread_once_slow (in /lib64/libc-2.36.so)
==18483==    by 0x4928D3A: timer_create@@GLIBC_2.34 (in 
/lib64/libc-2.36.so)
==18483==    by 0x401711: main (main.c:224)
==18483==
==18483== LEAK SUMMARY:
==18483==    definitely lost: 0 bytes in 0 blocks
==18483==    indirectly lost: 0 bytes in 0 blocks
==18483==      possibly lost: 272 bytes in 1 blocks
==18483==    still reachable: 0 bytes in 0 blocks
==18483==         suppressed: 0 bytes in 0 blocks
==18483==
==18483== For lists of detected and suppressed errors, rerun with: -s
==18483== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

What do i wrong?

Thanks

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

[Mathieu M. <ma...@de...>]

Hi Mark !

On Mon, Oct 24, 2022 at 10:01 PM Mark Wielaard <ma...@kl...> wrote:
>
> Hi Mathieu,
>
> On Fri, Oct 21, 2022 at 08:20:01AM +0200, Mathieu Malaterre wrote:
> > Could someone apply the following patch:
> >
> > sed -i -e 's/cortex-a8/generic-armv7-a/g' Makefile.all.am
> >
> > ref:
> > https://bugs.kde.org/show_bug.cgi?id=456200
>
> Sorry this didn't make the release. I would have to retest the build
> on a arm machine without neon and I didn't immediately have one. But
> this change is probably correct if we want to make valgrind work on
> systems that don't have neon. Given that Debian uses this, they
> probably support such arm machines.

Just FYI, this patch is in use in Debian/valgrind package since July
2022 (armhf arch).

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

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

Hi Mathieu,

On Fri, Oct 21, 2022 at 08:20:01AM +0200, Mathieu Malaterre wrote:
> Could someone apply the following patch:
> 
> sed -i -e 's/cortex-a8/generic-armv7-a/g' Makefile.all.am
> 
> ref:
> https://bugs.kde.org/show_bug.cgi?id=456200

Sorry this didn't make the release. I would have to retest the build
on a arm machine without neon and I didn't immediately have one. But
this change is probably correct if we want to make valgrind work on
systems that don't have neon. Given that Debian uses this, they
probably support such arm machines.

Cheers,

Mark

[Valgrind-users] Valgrind-3.20.0 is available

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

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

See the release notes below for details of changes.

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

~~~~~~~~~~~~~~~~~~~~~~~~~~~~

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 option "--vgdb-stop-at=event1,event2,..." accepts the new value abexit.
  This indicates to invoke gdbserver when your program exits abnormally
  (i.e. with a non zero exit code).
* Fix Rust v0 name demangling.
* The Linux rseq syscall is now implemented as (silently) returning ENOSYS.
* Add FreeBSD syscall wrappers for __specialfd and __realpathat.
* Remove FreeBSD dependencies on COMPAT10, which fixes compatibility with
  HardenedBSD
* The option --enable-debuginfod=<no|yes> [default: yes] has been added on
  Linux.
* More DWARF5 support as generated by clang14.

* ==================== 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.

131186  writev reports error in (vector[...])
434764  iconv_open causes ld.so v2.28+ to use optimised strncmp
446754  Improve error codes from alloc functions under memcheck
452274  memcheck crashes with Assertion 'sci->status.what == SsIdle' failed
452779  Valgrind fails to build on FreeBSD 13.0 with llvm-devel (15.0.0)
453055  shared_timed_mutex drd test fails with "Lock shared failed" message
453602  Missing command line option to enable/disable debuginfod
452802  Handle lld 9+ split RW PT_LOAD segments correctly
454040  s390x: False-positive memcheck:cond in memmem on arch13 systems 
456171  [PATCH] FreeBSD: Don't record address errors when accessing the 'kern.ps_strings' sysctl struct
n-i-bz  Implement vgdb invoker on FreeBSD
458845  PowerPC: The L field for the dcbf and sync instruction should be
        3 bits in ISA 3.1.
458915  Remove register cache to fix 458915 gdbserver causes wrong syscall return
459031  Documentation on --error-exitcode incomplete
459477  XERROR messages lacks ending '\n' in vgdb

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 above.

(3.20.0.RC1: 20 Oct 2022)

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

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

On Sun, 2022-10-23 at 00:11 +0200, Mark Wielaard wrote:
> Hi Philippe,
> 
> On Sat, Oct 22, 2022 at 02:58:28PM +0200, Philippe Waroquiers wrote:
> > I have started running valgrind on valgrind (outer/inner setup).
> > Results should be available tomorrow evening or so ...
> > For the first few tests, seems ok.
> > 
> > Just one strange thing:
> > The outer valgrind crashes on the below test (while the native run of this test is ok).
> > (this is on gcc farm gcc186).
> > 
> > Not very clear to me how the ld-linux.so.2 redirection could be ok in native mode,
> > but would not be ok when the same valgrind runs as an outer.
> > In any case, this is not blocking.
> > 
> > More complete results will follow ...
> 
> Thanks. I have no theory for the outer valgrind crash. But it doesn't
> seem blocking indeed. I am also still running some tests. Please let
> me know of further results. And do the actual release on Monday
> (unless some regression blocker turns up).
> 
> Cheers,
> 
> Mark
> 

For the crash of the outer valgrind: there is in fact some debug info really
missing on gcc186 (also for the inner) for the 32 bits version.

I have looked at the results of this outer/inner setup and found nothing that
seems problematic.

Note that analysis the outer logs is always painful, as the outer reports as "bugs"
the fact the inner uses e.g. some invalid memory because the guest
program run by the inner is designed to test the usage of such invalid memory.

Thanks
Philippe

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

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

Hi Philippe,

On Sat, Oct 22, 2022 at 02:58:28PM +0200, Philippe Waroquiers wrote:
> I have started running valgrind on valgrind (outer/inner setup).
> Results should be available tomorrow evening or so ...
> For the first few tests, seems ok.
> 
> Just one strange thing:
> The outer valgrind crashes on the below test (while the native run of this test is ok).
> (this is on gcc farm gcc186).
> 
> Not very clear to me how the ld-linux.so.2 redirection could be ok in native mode,
> but would not be ok when the same valgrind runs as an outer.
> In any case, this is not blocking.
> 
> More complete results will follow ...

Thanks. I have no theory for the outer valgrind crash. But it doesn't
seem blocking indeed. I am also still running some tests. Please let
me know of further results. And do the actual release on Monday
(unless some regression blocker turns up).

Cheers,

Mark

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

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

Hi,

On Thu, Oct 20, 2022 at 01:25:44PM -0700, Carl Love wrote:
> The only issue noted, as discussed on #valgrind-dev channel, is the
> addition of four post errors for the 3.20RC tree on all of the Power
> platforms.  Specifically:
> 
> cachegrind/tests/ann1                    (post)
> cachegrind/tests/ann2                    (post)
> callgrind/tests/ann1                     (post)
> callgrind/tests/ann2                     (post)
> 
> The output from  cachegrind/tests/ann1.post.diff is:
> 
> --- ann1.post.exp	2021-01-21 09:09:33.000000000 -0600
> +++ ann1.post.out	2022-10-20 14:07:33.272141328 -0500
> @@ -33,6 +33,13 @@
>  --------------------------------------------------------------------
> -----------
> -
>  -- Auto-annotated source: a.c
>  --------------------------------------------------------------------
> -----------
> -
> +@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
> @@@@@@@@@
> +@@ WARNING @@ WARNING @@ WARNING @@ WARNING @@ WARNING @@ WARNING @@
> WARNING @@
> +@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
> @@@@@@@@@
> +@ Source file 'a.c' is more recent than input file 'cgout-test'.
> +@ Annotations may not be correct.
> +@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
> @@@@@@@@@
> +
>  Ir        I1mr ILmr 
>  
>          2    0    0  int main(void) {
> 
> As discussed on the #valgrind-dev channel, this appears to be a
> timestamp issue.  Doing a touch * in directory cachegrind/tests seems
> to fix all four post errors.
> 
> No other issues were noted.  I would vote to do the touch * command and
> go ahead with the release.

I added the touch to the testcases as attached. That makes sure the
cgout-test file is always newer.

Cheers,

Mark

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

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

I have started running valgrind on valgrind (outer/inner setup).
Results should be available tomorrow evening or so ...
For the first few tests, seems ok.

Just one strange thing:
The outer valgrind crashes on the below test (while the native run of this test is ok).
(this is on gcc farm gcc186).

Not very clear to me how the ld-linux.so.2 redirection could be ok in native mode,
but would not be ok when the same valgrind runs as an outer.
In any case, this is not blocking.

More complete results will follow ...

Philippe

cachegrind/tests/x86/fpu-28-108.outer.log:10:valgrind:  Fatal error at startup: a function redirection
cachegrind/tests/x86/fpu-28-108.outer.log:11:valgrind:  which is mandatory for this platform-tool combination
cachegrind/tests/x86/fpu-28-108.outer.log:12:valgrind:  cannot be set up.  Details of the redirection are:
cachegrind/tests/x86/fpu-28-108.outer.log:13:valgrind:  
cachegrind/tests/x86/fpu-28-108.outer.log:14:valgrind:  A must-be-redirected function
cachegrind/tests/x86/fpu-28-108.outer.log:15:valgrind:  whose name matches the pattern:      strlen
cachegrind/tests/x86/fpu-28-108.outer.log:16:valgrind:  in an object with soname matching:   ld-linux.so.2
cachegrind/tests/x86/fpu-28-108.outer.log:17:valgrind:  was not found whilst processing
cachegrind/tests/x86/fpu-28-108.outer.log:18:valgrind:  symbols from the object with soname: ld-linux.so.2
cachegrind/tests/x86/fpu-28-108.outer.log:19:valgrind:  
cachegrind/tests/x86/fpu-28-108.outer.log:20:valgrind:  Possible fixes: (1, short term): install glibc's debuginfo
cachegrind/tests/x86/fpu-28-108.outer.log:21:valgrind:  package on this machine.  (2, longer term): ask the packagers
cachegrind/tests/x86/fpu-28-108.outer.log:22:valgrind:  for your Linux distribution to please in future ship a non-
cachegrind/tests/x86/fpu-28-108.outer.log:23:valgrind:  stripped ld.so (or whatever the dynamic linker .so is called)
cachegrind/tests/x86/fpu-28-108.outer.log:24:valgrind:  that exports the above-named function using the standard
cachegrind/tests/x86/fpu-28-108.outer.log:25:valgrind:  calling conventions for this platform.  The package you need
cachegrind/tests/x86/fpu-28-108.outer.log:26:valgrind:  to install for fix (1) is called
cachegrind/tests/x86/fpu-28-108.outer.log:27:valgrind:  
cachegrind/tests/x86/fpu-28-108.outer.log:28:valgrind:    On Debian, Ubuntu:                 libc6-dbg
cachegrind/tests/x86/fpu-28-108.outer.log:29:valgrind:    On SuSE, openSuSE, Fedora, RHEL:   glibc-debuginfo
cachegrind/tests/x86/fpu-28-108.outer.log:30:valgrind:  
cachegrind/tests/x86/fpu-28-108.outer.log:31:valgrind:  Note that if you are debugging a 32 bit process on a
cachegrind/tests/x86/fpu-28-108.outer.log:32:valgrind:  64 bit system, you will need a corresponding 32 bit debuginfo
cachegrind/tests/x86/fpu-28-108.outer.log:33:valgrind:  package (e.g. libc6-dbg:i386).
cachegrind/tests/x86/fpu-28-108.outer.log:34:valgrind:  
cachegrind/tests/x86/fpu-28-108.outer.log:35:valgrind:  Cannot continue -- exiting now.  Sorry.

On Thu, 2022-10-20 at 01:52 +0200, Mark Wielaard wrote:
> Greetings.
> 
> A first release candidate for 3.20.0 is available at
> https://sourceware.org/pub/valgrind/valgrind-3.20.0.RC1.tar.bz2
> (md5 = 981b9276536843090700c1268549186e)
> 
> Please give it a try on platforms that are important for you.  If no
> serious issues are reported, the 3.20.0 final release will happen on
> 22 October.
> 
> 
> 
> _______________________________________________
> Valgrind-developers mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-developers

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

[Mathieu M. <ma...@de...>]

Hi there,

On Thu, Oct 20, 2022 at 9:16 PM Paul Floyd <pj...@wa...> wrote:
>
>
>
> On 10/20/22 01:52, Mark Wielaard wrote:
> > Greetings.
> >
> > A first release candidate for 3.20.0 is available at
> > https://sourceware.org/pub/valgrind/valgrind-3.20.0.RC1.tar.bz2
> > (md5 = 981b9276536843090700c1268549186e)
> >
> > Please give it a try on platforms that are important for you.  If no
> > serious issues are reported, the 3.20.0 final release will happen on
> > 22 October.
>

Could someone apply the following patch:

sed -i -e 's/cortex-a8/generic-armv7-a/g' Makefile.all.am

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

Thanks & Regards

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

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

On 10/20/22 01:52, Mark Wielaard wrote:
> Greetings.
> 
> A first release candidate for 3.20.0 is available at
> https://sourceware.org/pub/valgrind/valgrind-3.20.0.RC1.tar.bz2
> (md5 = 981b9276536843090700c1268549186e)
> 
> Please give it a try on platforms that are important for you.  If no
> serious issues are reported, the 3.20.0 final release will happen on
> 22 October.

Hi

And finally, macOS. On my old macbook (10.7) there was a build error 
that I corrected last night.

Otherwise no real change since 3.19
- two regtests fail to build
- 236 regtest failures out of 671 with 1 hang

A+
Paul

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

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

On 10/20/22 01:52, Mark Wielaard wrote:
> Greetings.
> 
> A first release candidate for 3.20.0 is available at
> https://sourceware.org/pub/valgrind/valgrind-3.20.0.RC1.tar.bz2
> (md5 = 981b9276536843090700c1268549186e)
> 
> Please give it a try on platforms that are important for you.  If no
> serious issues are reported, the 3.20.0 final release will happen on
> 22 October.


FreeBSD 13.1

LGTM

One slight oddity.

I had a couple of failures (the ann1 and ann2 callgrind and cachegrind 
tests) after doing

autogen && configure && make && make check && make regtest


That seems to be because the timestamp of cgout-test is older than a.c 
causing


+@@ WARNING @@ WARNING @@ WARNING @@ WARNING @@ WARNING @@ WARNING @@ 
WARNING @@
+@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
+@ Source file 'a.c' is more recent than input file 
'../../cachegrind/tests/cgout-test'.
+@ Annotations may not be correct.
+@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
+


A+
Paul

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

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

Greetings.

A first release candidate for 3.20.0 is available at
https://sourceware.org/pub/valgrind/valgrind-3.20.0.RC1.tar.bz2
(md5 = 981b9276536843090700c1268549186e)

Please give it a try on platforms that are important for you.  If no
serious issues are reported, the 3.20.0 final release will happen on
22 October.

Re: [Valgrind-users] callgrind.out file size is zero

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

On 18/10/2022 14:54, Mahin Pandya wrote:
>
> Hi All,
>
> I am tying to use Valgrind to generate code profiling, generated 
> callgrind.out.2199511 file is of zero size. After enabling the debug 
> log below message is displayed:
>
> ...
>
> ==== SB 2759 (evchecks 30598) [tid 1] 0x415b170 execve 
> /usr/lib/x86_64-linux-gnu/libc-2.31.so+0xe3170
>
> --1314389:1: syswrap Exec of /devsrc/wineinst/bin/wine64-preloader
>
> --1314389:1: gdbsrv remote_finish (reason orderly_finish) 1030 -1
>
> --1314389:1: gdbsrv 1314389 (creator 1314389) maybe unlinking
>
> ...
>
> Any idea why it does not generate profiling data? I am new to 
> Valgrind, so not sure may have missed obvious things. Any 
> pointers/suggestion are welcome.
>
> Thanking you.
>
> regards,
>
> Mahin
>

Hi

My guess is that your process is doing a fork/exec (or maybe just an exec).

Try with --trace-children=yes

I'd also recommend that you start with --tool=none before moving on to 
callgrind.

A+

Paul

Re: [Valgrind-users] callgrind.out file size is zero

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

As a wild guess: looks like your application is doing fork and exec.
You might try to add then  --trace-children=yes 
  (and possibly if needed you should use --trace-children-skip=...... if tracing
   all children is too much).

Otherwise, try first with a very simple standalone program
e.g. something like:
   for (int i = 0; i < 1000; i++)
	printf ("hello world %d\n", i);

see if that works, and compare the debug trace of the very simple working
case with the more complex non working case.

Philippe


On Tue, 2022-10-18 at 12:54 +0000, Mahin Pandya wrote:
> Hi All,
>  
> I am tying to use Valgrind to generate code profiling, generated callgrind.out.2199511
> file is of zero size. After enabling the debug log below message is displayed:
>  
> ...
> ==== SB 2759 (evchecks 30598) [tid 1] 0x415b170 execve /usr/lib/x86_64-linux-gnu/libc-
> 2.31.so+0xe3170
> --1314389:1: syswrap Exec of /devsrc/wineinst/bin/wine64-preloader
> --1314389:1:  gdbsrv remote_finish (reason orderly_finish) 1030 -1
> --1314389:1:  gdbsrv 1314389 (creator 1314389) maybe unlinking
> ...
>  
> Any idea why it does not generate profiling data? I am new to Valgrind, so not sure may
> have missed obvious things. Any pointers/suggestion are welcome.
> Thanking you.
>  
> regards,
> Mahin
>  
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users

[Valgrind-users] callgrind.out file size is zero

[Mahin P. <mah...@ac...>]

Hi All,

I am tying to use Valgrind to generate code profiling, generated callgrind.out.2199511 file is of zero size. After enabling the debug log below message is displayed:

...
==== SB 2759 (evchecks 30598) [tid 1] 0x415b170 execve /usr/lib/x86_64-linux-gnu/libc-2.31.so+0xe3170
--1314389:1: syswrap Exec of /devsrc/wineinst/bin/wine64-preloader
--1314389:1:  gdbsrv remote_finish (reason orderly_finish) 1030 -1
--1314389:1:  gdbsrv 1314389 (creator 1314389) maybe unlinking
...

Any idea why it does not generate profiling data? I am new to Valgrind, so not sure may have missed obvious things. Any pointers/suggestion are welcome.
Thanking you.

regards,
Mahin

Re: [Valgrind-users] bug report: bugzilla refused to accept this saying it contains spam. But it doesn't.

[ISHIKAWA,chiaki <ish...@yk...>]

Still No Go.

If anyone reading this e-mail is involved in bugs.kde.org bugzilla 
management, please let the "sysadmin" know there is a perplexed
developer why on earth the following is deemed a spam, and being blocked 
to the bugzilla web.

Oh, yes, please also ask whoever is responsible to list the sysadmin 
address so that it would be much easier for someone to reach them.
That way, I don't have to bother the mailing list.

I have removed the stack trace with timestamp into a separate file in 
the hope that submission now works. It does not.


---- when I tried to submit bugzilla entry.

Your comment has been automatically blocked as it is believed to contain 
spam. Please contact Sysadmin if you believe this to be incorrect.

Please press Back and try again.

I tried a few times, removing a few strings, changing @ to AT and 
removing the URL reference to the e-mail exchange at the sourceforge 
archive.
To no avail...

--- begin quote ---

SUMMARY

valgrind 3.20GIT crashes due to SIGFPE while trying to run Thunderbird 
mail client.

I wrote this message initially on September 22.
So "one week ago", etc. are relative to that epoch origin.

I am trying to run thunderbird mail client (TB for short) under valgrind.
TB is created from the so-called comm-central source tree.
My local source was synced with the public source tree about a week ago.

Well, I could run TB under valgrind on August 15.
Also, I believe I could run it about 10 days ago.
However, in the last few days, when I tried to run TB under valgrind, 
valgrind crashed.

I suspect something has changed in the TB's binary toolchain in the last 
10 days or so.

Valgrind version
Valgrind-3.20.0.GIT-90763ca763-20220522X and LibVEX

OS:
Linux version 5.18.0-4-amd64 (debian-kerne AT lists.debian.org) (gcc-11 
(Debian 11.3.0-5) 11.3.0, GNU ld (GNU Binutils for Debian) 
2.38.90.20220713) #1 SMP PREEMPT_DYNAMIC Debian 5.18.16-1 (2022-08-10)

It seems the binary toolchain for TB seemed to have generated debug 
information that valgrind could not grok (?)

I am uploading the relvant part of the log from the test run when the 
fatal error occurred.

When valgrind failed, TB was created using ordinary -g flag of gcc-10.

On a hunch, I re-created TB using -gsplit-dwarf flag to gcc..
Then, with the newly created version of TB, valgrind did not crash 
although it did print
"### unhandled dwarf2 ..." warnings.

So something in the debug information in the libxul.so (about 120MB) is 
not quite right when ordinary non-split dwarf information is in the object..

STEPS TO REPRODUCE
1. run valgrind to check the memory usage of thunderbird mail client 
when it runs a test.
     The command line is dumped in the attached log.
2. Wait for the completion of a test run.
3. valgrind crashes.

OBSERVED RESULT
SIGFPE crash.
VALGRIND INTERNAL ERROR: Valgrind received a signal 8 (SIGFPE) - exiting
See the attachment.

EXPECTED RESULT
valgrind ought to finish the execution of TB running its test successfully.

SOFTWARE/OS VERSIONS
Debian GNU/Linux.
Linux version 5.18.0-4-amd64 (deb...@li...) (gcc-11 
(Debian 11.3.0-5) 11.3.0, GNU ld (GNU Binutils for Debian) 
2.38.90.20220713) #1 SMP PREEMPT_DYNAMIC Debian 5.18.16-1 (2022-08-10)

Linux/KDE Plasma:
(available in About System) <--- not sure about this. My Debian XFCE4 
desltop does not ahve "About System" anywhere.
I don't believe the GUI middleware has anything to do with the bug 
reported here.
KDE Plasma Version:
KDE Frameworks Version:
Qt Version:

ADDITIONAL INFORMATION

As I noted above, if I recompile TB using -gsplit-dwarf flag to gcc-10, 
then valgrind prints warnings about
unknown dwarf2 symbol, but it runs TB running its test to its completion.
I pass "-gdwarf-4 " to gcc.
So if something is generating dwarf2 info, it is not gcc, I think.
Maybe rust compiler being used?
  rustc --version
  rustc 1.63.0 (4b91a6ea7 2022-08-08)

In a discussion about this issue in valgrind-users mailing list, John 
Reiser suggested a following simple work-around:
(But I think we need to do something about the "unhandled dwarf2 abbrev 
code 0x25" in the long run.)

--- begin quote
 >  O think valgrind experienced a division by zero.
 >
 > readdwarf.c:
 >
 >        if (op_code >= info.li_opcode_base) {
 >           op_code -= info.li_opcode_base;
 >           Word adv = (op_code / info.li_line_range) <--- line 831
 >                         * info.li_min_insn_length;
 >           Int advAddr = adv;
 >           state_machine_regs.address += adv;

If you can re-build valgrind, then a quick-and-dirty work-around
might be

 >           Word adv = (op_code / (info.li_line_range ?: 1))
 >                         * info.li_min_insn_length;

where "x ?: y" is a deprecated-but-useful slang for "x ? x : y".
--- end quote


TIA

PS: BTW, initially, I could not post this bug report to the kde bugzilla 
due to the following error message.

==========
Your comment has been automatically blocked as it is believed to contain 
spam. Please contact Sysadmin if you believe this to be incorrect.
==========

Well, it does not, and the bugzilla web does not list sysadmin address.

It was suggested in the valgrind-users mailing list that I
should move the stacktrace dump from thunderbird test suite framework
to an attachment since the timestamp string attached by the test suite
may confuse the bugzilla system, and this is what I am doing now.

--- end quote ---

Re: [Valgrind-users] bug report: bugzilla refused to accept this saying it contains spam. But it doesn't.

[ISHIKAWA,chiaki <ish...@yk...>]

On 2022/09/23 9:11, John Reiser wrote:
>> I think valgrind experienced a division by zero.
>>
>> readdwarf.c:
>>
>>        if (op_code >= info.li_opcode_base) {
>>           op_code -= info.li_opcode_base;
>>           Word adv = (op_code / info.li_line_range)    <--- line 831
>>                         * info.li_min_insn_length;
>>           Int advAddr = adv;
>>           state_machine_regs.address += adv;
>
> If you can re-build valgrind, then a quick-and-dirty work-around
> might be
>
> >           Word adv = (op_code / (info.li_line_range ?: 1))
> >                         * info.li_min_insn_length;
>
> where "x ?: y" is a deprecated-but-useful slang for "x ? x : y".
>
> Also, one probable reason for the bug reporting system rejecting
> your first submission is the many consecutive lines that begin with
> "00:08.54 GECKO(319869) ".  The work-around for this is to put
> the text of the valgrind complaint into an attachment, and say
> "See the attachment for the full text of the valgrind complaint."



Thank you for the comment.


I will try to re-submit the bugzilla entry.

I didn't realize the lines starting with timestamp string such as 
""00:08.54 GECKO(319869) " causing the problem.
I thought there were no URLs, and so no spam. :-)

Sorry, somehow I overlooked your e-mail and thus this very tardy response.

TIA

Chiaki

[Valgrind-users] [Android] Warning linker with memcheck library

[$<ri...@nt...>]

Dear Valgrind Users,

I am trying to use valgrind on an Android device running version 12 to
debug some issue in the application. I am facing two issues here.

1. Valgrind reporting below warnings. Does this mean no track of
malloc/free etc..?

WARNING: linker: Warning:
"/data/local/tmp/Inst/libexec/valgrind/vgpreload_core-arm64-linux.so" has
unsupported flags DT_FLAGS_1=0x421 (ignoring unsupported flags)
WARNING: linker: Warning:
"/data/local/tmp/Inst/libexec/valgrind/vgpreload_memcheck-arm64-linux.so"
has unsupported flags DT_FLAGS_1=0x421 (ignoring unsupported flags)

2. How to launch an android application through valgrind. I am getting
command used `/data/local/tmp/Inst/bin/valgrind --tool=memcheck
--leak-check=full am start -a android.intent.action.MAIN -n
org.codeaurora.dialer/com.android.dialer.main.impl.MainActivity`
/system/bin/am[9]: /system/bin/cmd: Bad address

Please advise anyone who come across this issue and how to resolve this
issue.
-- 
Thanks & Regards,
M.Srikanth Kumar.

Re: [Valgrind-users] Valgrind not finding issue with writing/reading past array?

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

This is in fact documented in the FAQ here:

https://valgrind.org/docs/manual/faq.html#faq.overruns

The fact it's an array is not actually important - there is no
overrun detection for any global or stack variables.

The reason is that because valgrind is operating on an existing
binary there is no way to insert guards between variables because
the compiler has already fixed the layout - for the heap valgrind
can replace the allocate with one that adds guards around each
allocated block.

The tool Philippe refers to tried to use debug information where
possible to spot out of bounds writes but it wasn't very successful.

Better is to use address sanitizer, which requires recompilation
but because of that it is able to add guards around variables.

Tom

On 26/09/2022 21:20, Philippe Waroquiers wrote:
> Valgrind does not check out of bound write in arrays, unless these arrays are malloc-ed
> (and so valgrind can detect the write out of the limit of the malloc-ed block).
> 
> Valgrind used to contain an experimental tool (sgcheck) that did such stack array checks,
> but it had several limitations and problems, and was removed.
> 
> Thanks
> Philippe
> 
> On Mon, 2022-09-26 at 14:13 -0600, Grant Schoep wrote:
>> So I noticed something in my code that looked wrong to me, but valgrind didn't report
>> anything. I made a small example of it, and still no findings. I'm sure this code is
>> reading/writing past its array. But valgind doesn't say anything.
>>
>> I'm I not understanding something or is this a bug.
>>
>> Using:
>>   valgrind-3.19.0, gcc 4.8.5, CentOS 7
>>
>> I also tried
>> valgrind-3.19.0, gcc 7.3.1, Amazon Linux 2
>>
>> Here is the code.
>> ------
>> #include <string.h>
>> #include <stdio.h>
>>
>> int main()
>> {
>>     char retStr[32];
>>     
>>     // this is bad right? 40 bytes when above was 32?
>>     memset(retStr, 'F', 40);
>>        
>>     // These are "writing"  past the allocated memory?
>>     retStr[32] = 'A';
>>     retStr[33] = 'B';
>>     
>>     // These should be fine
>>     printf("***********  retStr is %c\n", retStr[30]);
>>     printf("***********  retStr is %c\n", retStr[31]);
>>     
>>     // These are reading past allocated memory?
>>     printf("***********  retStr is %c\n", retStr[32]);
>>     printf("***********  retStr is %c\n", retStr[33]);
>>
>>     return 0;
>> }
>> ---
>>
>>
>> Compiled:
>> "gcc filename.cxx"
>>
>> Ran via this command
>> "valgrind ./a.out"
>>
>>
>>
>> _______________________________________________
>> Valgrind-users mailing list
>> Val...@li...
>> https://lists.sourceforge.net/lists/listinfo/valgrind-users
> 
> 
> 
> 
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users

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

Re: [Valgrind-users] Valgrind not finding issue with writing/reading past array?

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

Valgrind does not check out of bound write in arrays, unless these arrays are malloc-ed
(and so valgrind can detect the write out of the limit of the malloc-ed block).

Valgrind used to contain an experimental tool (sgcheck) that did such stack array checks,
but it had several limitations and problems, and was removed.

Thanks
Philippe

On Mon, 2022-09-26 at 14:13 -0600, Grant Schoep wrote:
> So I noticed something in my code that looked wrong to me, but valgrind didn't report
> anything. I made a small example of it, and still no findings. I'm sure this code is
> reading/writing past its array. But valgind doesn't say anything. 
> 
> I'm I not understanding something or is this a bug.
> 
> Using:
>  valgrind-3.19.0, gcc 4.8.5, CentOS 7
> 
> I also tried
> valgrind-3.19.0, gcc 7.3.1, Amazon Linux 2
> 
> Here is the code.
> ------
> #include <string.h>
> #include <stdio.h>
> 
> int main()
> {
>    char retStr[32];
>    
>    // this is bad right? 40 bytes when above was 32?
>    memset(retStr, 'F', 40);
>       
>    // These are "writing"  past the allocated memory?
>    retStr[32] = 'A';
>    retStr[33] = 'B';
>    
>    // These should be fine
>    printf("***********  retStr is %c\n", retStr[30]);
>    printf("***********  retStr is %c\n", retStr[31]);
>    
>    // These are reading past allocated memory?
>    printf("***********  retStr is %c\n", retStr[32]);
>    printf("***********  retStr is %c\n", retStr[33]);
> 
>    return 0;
> }
> ---
> 
> 
> Compiled:
> "gcc filename.cxx"
> 
> Ran via this command
> "valgrind ./a.out"
> 
> 
> 
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users

[Valgrind-users] Valgrind not finding issue with writing/reading past array?

[Grant S. <mat...@gm...>]

So I noticed something in my code that looked wrong to me, but valgrind
didn't report anything. I made a small example of it, and still no
findings. I'm sure this code is reading/writing past its array. But valgind
doesn't say anything.

I'm I not understanding something or is this a bug.

Using:
valgrind-3.19.0, gcc 4.8.5, CentOS 7

I also tried
valgrind-3.19.0, gcc 7.3.1, Amazon Linux 2

Here is the code.
------
#include <string.h>
#include <stdio.h>

int main()
{
   char retStr[32];

   // this is bad right? 40 bytes when above was 32?
   memset(retStr, 'F', 40);

   // These are "writing"  past the allocated memory?
   retStr[32] = 'A';
   retStr[33] = 'B';

   // These should be fine
   printf("***********  retStr is %c\n", retStr[30]);
   printf("***********  retStr is %c\n", retStr[31]);

   // These are reading past allocated memory?
   printf("***********  retStr is %c\n", retStr[32]);
   printf("***********  retStr is %c\n", retStr[33]);

   return 0;
}
---


Compiled:
"gcc filename.cxx"

Ran via this command
"valgrind ./a.out"