valgrind-users — General discussion list for Valgrind users

Re: [Valgrind-users] Question about Valgrind tool in Intel new platform

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

On 20/04/2022 09:01, Yang Zhong wrote:

> So, from above issue in Intel new platform, the valgrind need do some enablings to be compatible
> with on new platform? Seems valgrind tool can't identify the real HW platform because cpuid can't
> read correct register value. thanks!

When running under valgrind you are running on an emulated CPU not
the real CPU and the results of cpuid will reflect the capabilities
of that emulated CPU rather than the real CPU.

Do the bits that you are trying to check reflect something (like new
instructions) that valgrind will need to be concerned about?

Tom

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

[Valgrind-users] Question about Valgrind tool in Intel new platform

[Yang Z. <yan...@in...>]

Hello all,

Recently our QAs used valgrind tool(valgrind-3.20.0.GIT) to verify memory leak 
with Qemu release on Intel new Sapphire Rapids platform. They only focused on
Sapphire Rapids' new features which are merged into Linux and Qemu release.

#The command
/usr/local/bin/valgrind --log-file=/root/valgrind.log --leak-check=full -v \
./qemu-system-x86_64 \
 ...... 

#Qemu will report below issue with valgrind tool:
qemu-system-x86_64: warning: prctl(ARCH_REQ_XCOMP_GUEST_PERM) failure for feature bit 18
qemu-system-x86_64: kvm_init_vcpu: kvm_arch_init_vcpu failed (0): Operation not permitted

W/o valgrind tool, the AMX can work normally in latest Linux and Qemu release.

I checked the Qemu code, below syscall will fail(rc=-1) with valgrind tool
int rc = syscall(SYS_arch_prctl, ARCH_REQ_XCOMP_GUEST_PERM, bit);
Notice: bit=18, which is AMX feature in xstate area.

I also use same valgrind command to check amx selftool on Sapphire Rapids platform.

/usr/local/bin/valgrind --log-file=/root/valgrind.log --leak-check=full -v linux/tools/testing/selftests/x86/amx_64
amx_64: [FAIL]  xstate cpuid: invalid tile data size/offset: 0/0: Success

from the linux/tools/testing/selftests/x86/amx.c

        eax = CPUID_LEAF_XSTATE;
        ecx = XFEATURE_XTILEDATA;

        cpuid(&eax, &ebx, &ecx, &edx);
        /*
         * eax: XTILEDATA state component size
         * ebx: XTILEDATA state component offset in user buffer
         */
        if (!eax || !ebx)
                fatal_error("xstate cpuid: invalid tile data size/offset: %d/%d",
                                eax, ebx);

Above code only read AMX xtilestate's offset and size from xstate buffer by cpuid.
But from the error information, with valgrind tool, the amx selftest tool in Linux can't
read correct Sapphire Rapids platform's cpuid registers. 

I also tried this same command w/o valgrind tool in intel older platform(without this feature),
we can get same error information, but this should be normal behavior.
root@icx:~/yangzhon/projects/amx/linux# tools/testing/selftests/x86/amx_64
amx_64: [FAIL]  xstate cpuid: invalid tile data size/offset: 0/0: Success

So, from above issue in Intel new platform, the valgrind need do some enablings to be compatible
with on new platform? Seems valgrind tool can't identify the real HW platform because cpuid can't
read correct register value. thanks!

Regards,
Yang

Re: [Valgrind-users] Error building valgrind on petalinux ARM host

[Aaron B. <bo...@pr...>]

Some further info : the .in_place folder is empty, which explains why ln command fails.

------- Original Message -------
On Friday, March 25th, 2022 at 13:05, Aaron Boxer via Valgrind-users <val...@li...> wrote:

> Hello!
>
> I am trying to build valgrind 3.18 on a petalinux system (embedded Xilinx board)
> Even though I am logged in as root., I get this error about symbolic link :
>
> mkdir -p ../.in_place; \
> for f in vgpreload_core-arm64-linux.so ; do \
> rm -f ../.in_place/$f; \
> ln -f -s ../coregrind/$f ../.in_place; \
> done
> mkdir -p ../.in_place; \
> for f in ; do \
> rm -f ../.in_place/$f.dSYM; \
> ln -f -s ../coregrind/$f.dSYM ../.in_place; \
> done
> ln: failed to create symbolic link '../.in_place/vgpreload_core-arm64-linux.so': Operation not permitted
>
> Any insight here would be greatly appreciated.
> Thanks!
> Aaron
>
> Sent with [ProtonMail](https://protonmail.com/) secure email.

[Valgrind-users] Error building valgrind on petalinux ARM host

[Aaron B. <bo...@pr...>]

Hello!

I am trying to build valgrind 3.18 on a petalinux system (embedded Xilinx board)
Even though I am logged in as root., I get this error about symbolic link :

mkdir -p ../.in_place; \
for f in vgpreload_core-arm64-linux.so ; do \
rm -f ../.in_place/$f; \
ln -f -s ../coregrind/$f ../.in_place; \
done
mkdir -p ../.in_place; \
for f in ; do \
rm -f ../.in_place/$f.dSYM; \
ln -f -s ../coregrind/$f.dSYM ../.in_place; \
done
ln: failed to create symbolic link '../.in_place/vgpreload_core-arm64-linux.so': Operation not permitted

Any insight here would be greatly appreciated.
Thanks!
Aaron

Sent with [ProtonMail](https://protonmail.com/) secure email.

Re: [Valgrind-users] Can't extend stack during signal delivery : too small or bad protection modes

[Narayanan I. <na...@yo...>]

Hi Philippe,

Thank you for your reply.

1) I am using valgrind-3.17.0 on a Ubuntu 21.10 box (sorry I had incorrectly mentioned Ubuntu 20.04 in my original report). Not sure if this is the latest release or not.

2) I did not try it with --tool=none. It takes some time of testing to happen even with memcheck so not sure a none tool would help.

3) Yes this is the first error that I encounter. And I had tried the approach that you suggest with --vgdb-error=1 and did attach to the process through gdb at exactly the point when the error is issued. But did not know what more to do then. The application stack trace looks good just like I would expect.

4) I am not sure how to make use of the debug switches in further analyzing this.

I have found a workaround for my issue and that is to remove a 1Mb allocation in the stack and move it to the heap. For reasons not yet known, that made the error disappear.

So I have decided to move on for now. To me, the symptoms I have seen so far make it seem like a valgrind issue and not an application issue.

If there is anything that you or other valgrind experts would like to know from the failing case, I can try work with you.

Thanks again.

Narayanan.

Re: [Valgrind-users] Can't extend stack during signal delivery : too small or bad protection modes

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

If you are not using the last release of valgrind, you might try with the last release.

Wondering if the problem also happens with other tools (e.g.  --tool=none).


Otherwise, you could try to debug your application when running under valgrind
when it encounters the problem.
Eg. use arguments --vgdb=full --vgdb-error=1 --vgdb-stop-at=exit,valgrindabexit
(assuming the below is the first error you encounter. If not, you should first fix your
code to solve the errors previously reported by valgrind).


You could also compare the valgrind trace between a succesful run and an unsuccesful run,
with e.g. the valgrind debug switches -v -v -v -d -d -d --trace-signals=yes
and see if you detect a difference between the 2 runs.
Note that with the above switches, you should see some debug log of the signal handling
and of the stack extension mechanism.

Hope this helps

Philippe


On Mon, 2022-03-14 at 11:30 -0400, Narayanan Iyer via Valgrind-users wrote:
> One correction (not sure it matters). I believe the application uses 1.25Mb of stack space at the time of the failure (not .25 as I had originally mentioned).
> 
> Narayanan.
> 
> -----Original Message-----
> From: Narayanan Iyer [mailto:na...@yo...] 
> Sent: Monday, March 14, 2022 11:27 AM
> To: val...@li...
> Cc: 'Narayanan Iyer' <na...@yo...>
> Subject: Can't extend stack during signal delivery : too small or bad protection modes
> 
> Hi,
> 
> While running the automated test suite (which has hundreds of tests) for my application with valgrind, I occasionally see failures like the following in some of the tests.
> 
> ==29753== Can't extend stack to 0x1ffeec7948 during signal delivery for thread 1:
> ==29753==   too small or bad protection modes
> ==29753== 
> ==29753== Process terminating with default action of signal 11 (SIGSEGV): dumping core
> ==29753==  Access not within mapped region at address 0x1FFEEC7948
> ==29753==    at 0x4849FD8: strncpy (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==29753==    by 0x489AE7C: cli_get_sub_quals (sr_unix/cli_parse.c:593)
> ==29753==    by 0x489ABC3: parse_arg (sr_unix/cli_parse.c:0)
> ==29753==    by 0x489BD6E: parse_triggerfile_cmd (sr_unix/cli_parse.c:1128)
> ==29753==    by 0x4BD2377: trigger_parse (sr_unix/trigger_parse.c:1416)
> ==29753==    by 0x4B12152: trigger_update_rec (sr_unix/trigger_update.c:1386)
> ==29753==    by 0x4B16171: trigger_update_rec_helper (sr_unix/trigger_update.c:2171)
> ==29753==    by 0x4B163B9: trigger_update (sr_unix/trigger_update.c:2224)
> ==29753==    by 0x4B86385: op_fnztrigger (sr_port/op_fnztrigger.c:248)
> ==29753==    by 0x5ABA384: _ydboctoplanhelpers (in YDBOcto/build/src/_ydbocto.so)
> ==29753==    by 0x1774F1EF: ???
> ==29753==    by 0xAAAAAAAAAAAAAAA9: ???
> ==29753==  If you believe this happened as a result of a stack
> ==29753==  overflow in your program's main thread (unlikely but
> ==29753==  possible), you can try to increase the size of the
> ==29753==  main thread stack using the --main-stacksize= flag.
> ==29753==  The main thread stack size used in this run was 268435456.
> ==29753== Invalid write of size 8
> ==29753==    at 0x483A124: _vgnU_freeres (in /usr/libexec/valgrind/vgpreload_core-amd64-linux.so)
> ==29753==  Address 0x1ffeec8808 is on thread 1's stack
> 
> If I rerun just the failing test, it passes fine. Every time the list of tests that fail keeps changing. If I run the test without valgrind, it passes all the time.
> 
> Originally I got a failure with the --main-stacksize set to 16Mb so I bumped it to 256Mb. And I still keep getting this failure at different tests. I also set the ulimit for stacksize to 256Mb just in case and I still see the failures.
> 
> The application is a single-threaded application and I know for sure it does not use anywhere near 256Mb of stack space. The stack trace shown above keeps changing across the many random failures but in all of those stack traces, I believe only around .25Mb of stack space would be used at the most. 
> 
> In this application, a SIGALRM signal would happen every 1 second or so. The application does not set up any alternate stack (i.e. no sigaltstack() call). Not sure if that can be related to the random failure or not.
> 
> This is on a Ubuntu 20.04 system. And my application was compiled with gcc.
> 
> Not sure how to debug this further. Any help in this regard is appreciated.
> 
> Thanks,
> Narayanan.
> 
> 
> 
> 
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Can't extend stack during signal delivery : too small or bad protection modes

[Narayanan I. <na...@yo...>]

One correction (not sure it matters). I believe the application uses 1.25Mb of stack space at the time of the failure (not .25 as I had originally mentioned).

Narayanan.

-----Original Message-----
From: Narayanan Iyer [mailto:na...@yo...] 
Sent: Monday, March 14, 2022 11:27 AM
To: val...@li...
Cc: 'Narayanan Iyer' <na...@yo...>
Subject: Can't extend stack during signal delivery : too small or bad protection modes

Hi,

While running the automated test suite (which has hundreds of tests) for my application with valgrind, I occasionally see failures like the following in some of the tests.

==29753== Can't extend stack to 0x1ffeec7948 during signal delivery for thread 1:
==29753==   too small or bad protection modes
==29753== 
==29753== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==29753==  Access not within mapped region at address 0x1FFEEC7948
==29753==    at 0x4849FD8: strncpy (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==29753==    by 0x489AE7C: cli_get_sub_quals (sr_unix/cli_parse.c:593)
==29753==    by 0x489ABC3: parse_arg (sr_unix/cli_parse.c:0)
==29753==    by 0x489BD6E: parse_triggerfile_cmd (sr_unix/cli_parse.c:1128)
==29753==    by 0x4BD2377: trigger_parse (sr_unix/trigger_parse.c:1416)
==29753==    by 0x4B12152: trigger_update_rec (sr_unix/trigger_update.c:1386)
==29753==    by 0x4B16171: trigger_update_rec_helper (sr_unix/trigger_update.c:2171)
==29753==    by 0x4B163B9: trigger_update (sr_unix/trigger_update.c:2224)
==29753==    by 0x4B86385: op_fnztrigger (sr_port/op_fnztrigger.c:248)
==29753==    by 0x5ABA384: _ydboctoplanhelpers (in YDBOcto/build/src/_ydbocto.so)
==29753==    by 0x1774F1EF: ???
==29753==    by 0xAAAAAAAAAAAAAAA9: ???
==29753==  If you believe this happened as a result of a stack
==29753==  overflow in your program's main thread (unlikely but
==29753==  possible), you can try to increase the size of the
==29753==  main thread stack using the --main-stacksize= flag.
==29753==  The main thread stack size used in this run was 268435456.
==29753== Invalid write of size 8
==29753==    at 0x483A124: _vgnU_freeres (in /usr/libexec/valgrind/vgpreload_core-amd64-linux.so)
==29753==  Address 0x1ffeec8808 is on thread 1's stack

If I rerun just the failing test, it passes fine. Every time the list of tests that fail keeps changing. If I run the test without valgrind, it passes all the time.

Originally I got a failure with the --main-stacksize set to 16Mb so I bumped it to 256Mb. And I still keep getting this failure at different tests. I also set the ulimit for stacksize to 256Mb just in case and I still see the failures.

The application is a single-threaded application and I know for sure it does not use anywhere near 256Mb of stack space. The stack trace shown above keeps changing across the many random failures but in all of those stack traces, I believe only around .25Mb of stack space would be used at the most. 

In this application, a SIGALRM signal would happen every 1 second or so. The application does not set up any alternate stack (i.e. no sigaltstack() call). Not sure if that can be related to the random failure or not.

This is on a Ubuntu 20.04 system. And my application was compiled with gcc.

Not sure how to debug this further. Any help in this regard is appreciated.

Thanks,
Narayanan.

[Valgrind-users] Can't extend stack during signal delivery : too small or bad protection modes

[Narayanan I. <na...@yo...>]

Hi,

While running the automated test suite (which has hundreds of tests) for my application with valgrind, I occasionally see failures like the following in some of the tests.

==29753== Can't extend stack to 0x1ffeec7948 during signal delivery for thread 1:
==29753==   too small or bad protection modes
==29753== 
==29753== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==29753==  Access not within mapped region at address 0x1FFEEC7948
==29753==    at 0x4849FD8: strncpy (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==29753==    by 0x489AE7C: cli_get_sub_quals (sr_unix/cli_parse.c:593)
==29753==    by 0x489ABC3: parse_arg (sr_unix/cli_parse.c:0)
==29753==    by 0x489BD6E: parse_triggerfile_cmd (sr_unix/cli_parse.c:1128)
==29753==    by 0x4BD2377: trigger_parse (sr_unix/trigger_parse.c:1416)
==29753==    by 0x4B12152: trigger_update_rec (sr_unix/trigger_update.c:1386)
==29753==    by 0x4B16171: trigger_update_rec_helper (sr_unix/trigger_update.c:2171)
==29753==    by 0x4B163B9: trigger_update (sr_unix/trigger_update.c:2224)
==29753==    by 0x4B86385: op_fnztrigger (sr_port/op_fnztrigger.c:248)
==29753==    by 0x5ABA384: _ydboctoplanhelpers (in YDBOcto/build/src/_ydbocto.so)
==29753==    by 0x1774F1EF: ???
==29753==    by 0xAAAAAAAAAAAAAAA9: ???
==29753==  If you believe this happened as a result of a stack
==29753==  overflow in your program's main thread (unlikely but
==29753==  possible), you can try to increase the size of the
==29753==  main thread stack using the --main-stacksize= flag.
==29753==  The main thread stack size used in this run was 268435456.
==29753== Invalid write of size 8
==29753==    at 0x483A124: _vgnU_freeres (in /usr/libexec/valgrind/vgpreload_core-amd64-linux.so)
==29753==  Address 0x1ffeec8808 is on thread 1's stack

If I rerun just the failing test, it passes fine. Every time the list of tests that fail keeps changing. If I run the test without valgrind, it passes all the time.

Originally I got a failure with the --main-stacksize set to 16Mb so I bumped it to 256Mb. And I still keep getting this failure at different tests. I also set the ulimit for stacksize to 256Mb just in case and I still see the failures.

The application is a single-threaded application and I know for sure it does not use anywhere near 256Mb of stack space. The stack trace shown above keeps changing across the many random failures but in all of those stack traces, I believe only around .25Mb of stack space would be used at the most. 

In this application, a SIGALRM signal would happen every 1 second or so. The application does not set up any alternate stack (i.e. no sigaltstack() call). Not sure if that can be related to the random failure or not.

This is on a Ubuntu 20.04 system. And my application was compiled with gcc.

Not sure how to debug this further. Any help in this regard is appreciated.

Thanks,
Narayanan.

Re: [Valgrind-users] *** SPAM *** Helgrind and Meyers' singletons

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

On 2022-02-22 17:28, Norbert Reher wrote:
>
> So I was searching the mailing list for a possible work around to reduce
> the number of false/positives reported and found a mail (with identical
> subject) from Adriaan Schmidt dated 2016-11-28 14:42:43.
>

Not an answer, but just for reference the thread in question can be 
found here


https://sourceforge.net/p/valgrind/mailman/valgrind-users/thread/1C789EC78A01A643ACB88798B277DCED0523382A%40DENBGAT9EL4MSX.ww902.siemens.net/#msg35518667


A+

Paul

Re: [Valgrind-users] Application doesn't leak memory running valgrind

[Stefano A. <san...@al...>]

On Mon, 2022-02-28 at 13:11 -0800, Stefano Antonelli wrote:
> When the leak occurs, the number of 4k pages owned by this render
> device increases.  Running valgrind leak-test (or gdb with malloc
> breakpoint), the number of 4k pages owned by this render device _do
> not_ increase.

When I run callgrind, the same behaviour happens.

valgrind  --tool=callgrind --instr-atstart=no ./qml-mwe3

Once the application is up and running, I use:

:~# callgrind_control --instr=on 4120
PID 4120: ./qml-mwe3
sending command instrumentation on to pid 4120
  OK.
:~# callgrind_control -s 4120
PID 4120: ./qml-mwe3
sending command status internal to pid 4120
  Number of running threads: 4, thread IDs: 1 2 3 4
  Events collected: Ir
  Functions: 1,104 (executed 1,289, contexts 1,104)
  Basic blocks: 1,816 (executed 1,120,586,516, call sites 452)

:~# callgrind_control --instr=off 4120
PID 4120: ./qml-mwe3
sending command instrumentation off to pid 4120
  OK.

After the I turn on the instrumentation, the display stops updating
completely (it's running an animation).  Once I turn off the
instrumentation, the display resumes.  I would expect the animation to
run dreadfully slow, but not freeze in place for the duration of time
instrumentation was on.  I don't know exactly how much time this was,
but if I had to guess I'd say around 10 minutes.

I should also add that the processor is armhf and I noticed with
callgrind I get a couple of warnings:

==4120== Callgrind, a call-graph generating cache profiler
==4120== Copyright (C) 2002-2017, and GNU GPL'd, by Josef Weidendorfer
et al.
==4120== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright
info
==4120== Command: ./qml-mwe3
==4120== 
==4120== For interactive control, run 'callgrind_control -h'.
==4120== Warning: noted but unhandled ioctl 0x6443 with no
size/direction hints.
==4120==    This could cause spurious value errors to appear.
==4120==    See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing
a proper wrapper.
==4120== Warning: noted but unhandled ioctl 0x4b51 with no
size/direction hints.
==4120==    This could cause spurious value errors to appear.
==4120==    See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing
a proper wrapper.
disInstr(thumb): unhandled instruction: 0xDEFF 0xF8DD

I don't know if that's breaking things or not.  Nor do I know what
these IOCTLs are, but I am trying to
parse README_MISSING_SYSCALL_OR_IOCTL as I go along here.

-Stef

Re: [Valgrind-users] Application doesn't leak memory running valgrind

[Stefano A. <san...@al...>]

On Mon, 2022-02-28 at 09:45 -0800, Stefano Antonelli wrote:
> On Mon, 2022-02-28 at 18:00 +0100, Floyd, Paul wrote:
> > On 2022-02-28 17:28, Stefano Antonelli wrote:
> > 
> Using a memory pool doesn't explain why the leak doesn't get bigger
> when running valgrind though does it?

So I think I understand the problem.

QML sits on top of EGL.  The EGL layer is supplied in binary form.

In pmap I see a growing number of pages owned by /dev/dri/renderD129
which is a device file.

crw-rw---- 1 root render 226, 129 Feb 23 15:48 /dev/dri/renderD129

When the leak occurs, the number of 4k pages owned by this render
device increases.  Running valgrind leak-test (or gdb with malloc
breakpoint), the number of 4k pages owned by this render device _do
not_ increase.

I believe that QML creates "a graphic thing" from this render device
and probably also deletes it, but I don't think the library controlling
the render device is freeing the memory.

I *think* this library (libglapi.so) is using malloc, but I don't have
any source code.  ldd shows me:

12: 00000000     0 FUNC    GLOBAL DEFAULT  UND malloc@GLIBC_2.4 (3)

So something real is happening when valgrind leak-test is used that's
affecting this graphics library in a good way.

Can anyone explain what valgrind does?  I know it replaces malloc with
vg_malloc, but does anything else happen?

Thanks,
Stef

Re: [Valgrind-users] Application doesn't leak memory running valgrind

[Stefano A. <san...@al...>]

On Mon, 2022-02-28 at 18:00 +0100, Floyd, Paul wrote:
> On 2022-02-28 17:28, Stefano Antonelli wrote:

> I don't know much about Qml. Does this use any sort of memory manager
> or
> garbage collector?

Qml is built on top of javascript.  There is definitely a garbage
collector.

> One thing that you could try is to run your application with
> --tool=massif and then repeat the run but add --pages-as-heap=yes. If
> there is a big difference in the two then it means that your
> application
> is using a memory pool not based on malloc. Use ms_print (or
> massif-visualizer) to see the massif profiles.

There is a huge difference.  1MB vs 90MB.

Using a memory pool doesn't explain why the leak doesn't get bigger
when running valgrind though does it?

And thanks for the help!

-Stef

Re: [Valgrind-users] Application doesn't leak memory running valgrind

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

On 2022-02-28 17:28, Stefano Antonelli wrote:
> Hello list,
>
> I have a Qml application that leaks memory when run normally.  I've
> reduced it to a very simple Qml app and it still leaks.  And the leak
> is visible with pmap almost immediately.  The application runs on an
> embedded device (armhf).


Hi Stefano

I don't know much about Qml. Does this use any sort of memory manager or 
garbage collector?

One thing that you could try is to run your application with 
--tool=massif and then repeat the run but add --pages-as-heap=yes. If 
there is a big difference in the two then it means that your application 
is using a memory pool not based on malloc. Use ms_print (or 
massif-visualizer) to see the massif profiles.


A+

Paul

[Valgrind-users] Application doesn't leak memory running valgrind

[Stefano A. <san...@al...>]

Hello list,

I have a Qml application that leaks memory when run normally.  I've
reduced it to a very simple Qml app and it still leaks.  And the leak
is visible with pmap almost immediately.  The application runs on an
embedded device (armhf).

When I run it with valgrind:

 /usr/bin/valgrind.bin --tool=memcheck --error-limit=no \
--log-file=vg-220214.log  --leak-check=full \
--leak-resolution=high --show-reachable=yes ./qml-mwe3

There is no leak.  I've tried running it for a solid day and pmap
doesn't show any leak.

If I run the same application in gdb (just letting it run).  It leaks.
 However, if I put a break point on malloc:

gdb ./qml-mwe3
(gbd) run
--- some time passes ---
^C
(gdb) break malloc
(gdb) commands
> continue
> end
(gdb) run

Then the leak stops.  No memory is freed, but it absolutely stops
increasing.

Can anyone offer any guesses as to what's going on?  I would appreciate
any ideas to debug this further.

Thanks,
Stef

[Valgrind-users] Helgrind and Meyers' singletons

[Norbert R. <Nor...@gm...>]

Dear all,

I am analyzing a program with Helgrind for possible data races.
Thread-safe static initialization is used to implement singletons inside
the code.
As expected several false/positves are reported.

gcc version: 10.2.1
compile options: -std=c++17 -O3 -m64 -g ...
Valgrind version: 3.16.1.

So I was searching the mailing list for a possible work around to reduce
the number of false/positives reported and found a mail (with identical
subject) from Adriaan Schmidt dated 2016-11-28 14:42:43.

He used helgrind annotations ANNOTATE_HAPPENS_AFTER and
ANNOTATE_HAPPENS_BEFORE to make Helgrind warnings disappear for
singletons using thread-safe static initialization.

I haven't found any reply to his final question if the solution found
could brake the analysis.

If I missed the reply please let me know.

Thank you in advance.

[Valgrind-users] Helgrind lock order detection and memory re-use

[Nikolaus R. <Nik...@ra...>]

Hello,

I'm debugging a C++ program with Helgrind. The program is memcheck
clean. I am getting the following error (trimmed the stacktraces to the
relevant parts):

==1910679== Thread #4: lock order "0x4EB0948 before 0x18B920" violated
==1910679== 
==1910679== Observed (incorrect) order is: acquisition of lock at 0x18B920
==1910679==    by 0x1405CB: unique_lock (unique_lock.h:68)
==1910679==    by 0x1405CB: steamfs::do_lookup(unsigned long, char const*, fuse_entry_param*) (callbacks.cpp:410)
==1910679==    by 0x1491CA: create (callbacks.cpp:1429)
==1910679==    by 0x1491CA: operator() (callbacks.cpp:1447)
==1910679== 
==1910679==  followed by a later acquisition of lock at 0x4EB0948
==1910679==    by 0x14060D: unique_lock (unique_lock.h:68)
==1910679==    by 0x14060D: steamfs::do_lookup(unsigned long, char const*, fuse_entry_param*) (callbacks.cpp:418)
==1910679==    by 0x1491CA: create (callbacks.cpp:1429)
==1910679==    by 0x1491CA: operator() (callbacks.cpp:1447)
==1910679== 
==1910679== Required order was established by acquisition of lock at 0x4EB0948
==1910679==    by 0x141648: lock_guard (std_mutex.h:159)
==1910679==    by 0x141648: steamfs::do_readdir(fuse_req*, unsigned long, unsigned long, long, fuse_file_info const*, int) (callbacks.cpp:600)
==1910679==    by 0x14240F: readdirplus (callbacks.cpp:1384)
==1910679==    by 0x14240F: operator() (callbacks.cpp:1389)
==1910679== 
==1910679==  followed by a later acquisition of lock at 0x18B920
==1910679==    by 0x1405CB: unique_lock (unique_lock.h:68)
==1910679==    by 0x1405CB: steamfs::do_lookup(unsigned long, char const*, fuse_entry_param*) (callbacks.cpp:410)
==1910679==    by 0x141839: steamfs::do_readdir(fuse_req*, unsigned long, unsigned long, long, fuse_file_info const*, int) (callbacks.cpp:677)
==1910679==    by 0x14240F: readdirplus (callbacks.cpp:1384)
==1910679==    by 0x14240F: operator() (callbacks.cpp:1389)


The problem is that the code that accesses the second lock (0x4EB0948)
is not accessing the same variable. Now, it could of course be that
there is a bug somewhere that results in both variables pointing to the
same address, but it is much more likely that this is coincidence (since
both variables are part of structures that are dynamically allocated and
freed).

Is it possible that Helgrind is not recognizing that these are two
*different* locks with different lifetimes that just happen to be
allocated at the same address?


Best,
-Nikolaus


-- 
GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             »Time flies like an arrow, fruit flies like a Banana.«

[Valgrind-users] Fosdem Talks, next release & developer meetup

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

Hi valgrind hackers,

TLDR; The Fosdem talks are online, the next valgrind 3.19.0 release is
proposed for April 8th and there will be a Valgrind dev meetup the
last Friday of March 25th.

At the start of February we had a Virtual Valgrind Devroom at Fosdem:
https://fosdem.org/2022/schedule/track/valgrind/

There are slides and videos for the talks given:

- Upstreaming the FreeBSD Port, Paul Floyd
  https://fosdem.org/2022/schedule/event/valgrind_freebsd/
- Enable AVX-512 instructions in Valgrind, Tanya Volnina
  https://fosdem.org/2022/schedule/event/valgrind_avx512/
- Valgrind and debuginfo, Mark Wielaard
  https://fosdem.org/2022/schedule/event/valgrind_debuginfo/
- Valgrind on RISC-V, Petr Pavlu
  https://fosdem.org/2022/schedule/event/valgrind_riscv/
- Adding Power ISA 3.1 instruction support, Carl Love
  https://fosdem.org/2022/schedule/event/valgrind_isa31/

Unfortunately the last session called 20 years of Valgrind, wasn't
recorded because of audio/video problems, it was just a text chat.

At the last valgrind dev meetup (end of November) we said we would do
a new valgrind 3.19.0 release in April (6 months after 3.18.1). I
propose we do that Friday April 8th. 7 weeks from now.

To coordinate the release we will have a Valgrind dev meetup through
jitsi again the last Friday of March. That is 2 weeks before the
planned 3.19.0 release. The 25th of March at 1600 UTC / 1700 CET /
0900 PDT. https://meet.jit.si/ValgrindDevMeeting.

Cheers,

Mark

Re: [Valgrind-users] does Valgrind-3.19.0.GIT support Clang14 dwarf 5?

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

Thank you for your clarification.

It certainly seems the inlined function is not handled well, come to 
think of it.

I will look at the video you kindly referred to.

Thank you again.

Chiaki

On 2022/02/16 20:24, Mark Wielaard wrote:
> On Wed, Feb 16, 2022 at 12:46:32PM +0900, ISHIKAWA,chiaki wrote:
>> This is tangent to the original question, but this part:
>>
>>> with split-dwarf (which rnglistx and strx
>> form codes doesn't support yet)
>>
>> valgrind does support bulk of data generated by --split-dwarf (gcc),
>> doesn't it?
> No, it doesn't. valgrind won't read .dwo files/sections at all which
> split-dwarf uses.
>
>> The above refers to "doesn't support"  rnglistx and strx form codes?
> And addrx forms. These are normally only used (by gcc) for split-dwarf
> and involve an extra indirection through an index to reach the value
> of the attribute. These forms are technically valid in non-split-dwarf
> (with DWARF5) but not supported by valgrind.
>
>> I am asking this  because I have checked mozilla thunderbird code
>> which is compiled using --split-dwarf of GCC and valgrind reports
>> reasonably sane diagnosis so far.
> valgrind can report valid diagnostics with DWARF debuginfo, but it
> might be less accurate, for example it won't report on inlined
> functions.
>
> I happened to give a talk on that recently:
> https://fosdem.org/2022/schedule/event/valgrind_debuginfo/
> (That talk doesn't cover split-dwarf though)
>
> Cheers,
>
> Mark
>

Re: [Valgrind-users] does Valgrind-3.19.0.GIT support Clang14 dwarf 5?

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

On Wed, Feb 16, 2022 at 12:46:32PM +0900, ISHIKAWA,chiaki wrote:
> This is tangent to the original question, but this part:
> 
> > with split-dwarf (which rnglistx and strx
> form codes doesn't support yet)
>
> valgrind does support bulk of data generated by --split-dwarf (gcc),
> doesn't it?

No, it doesn't. valgrind won't read .dwo files/sections at all which
split-dwarf uses.

> The above refers to "doesn't support"  rnglistx and strx form codes?

And addrx forms. These are normally only used (by gcc) for split-dwarf
and involve an extra indirection through an index to reach the value
of the attribute. These forms are technically valid in non-split-dwarf
(with DWARF5) but not supported by valgrind.

> I am asking this  because I have checked mozilla thunderbird code
> which is compiled using --split-dwarf of GCC and valgrind reports
> reasonably sane diagnosis so far.

valgrind can report valid diagnostics with DWARF debuginfo, but it
might be less accurate, for example it won't report on inlined
functions.

I happened to give a talk on that recently:
https://fosdem.org/2022/schedule/event/valgrind_debuginfo/
(That talk doesn't cover split-dwarf though)

Cheers,

Mark

Re: [Valgrind-users] does Valgrind-3.19.0.GIT support Clang14 dwarf 5?

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

This is tangent to the original question, but this part:

> with split-dwarf (which rnglistx and strx
form codes doesn't support yet)

valgrind does support bulk of data generated by --split-dwarf (gcc), 
doesn't it?
The above refers to "doesn't support"  rnglistx and strx form codes?

I am asking this  because I have checked mozilla thunderbird code which 
is compiled using
--split-dwarf of GCC and
valgrind reports reasonably sane diagnosis so far.
Well, that is what I thought.
Maybe I was mistaken.

Will you kindly clarify the above?

TIA

Chiaki Ishikawa

On 2022/02/14 17:02, Mark Wielaard wrote:
> Hi Thomas,
>
> On Sun, Feb 13, 2022 at 08:18:48PM +0000, Thomas Wollenzin wrote:
>> This is a just a quick question. As I haven't found a sufficient answer in the archives.
>> Does Valgrind-3.19.0.GIT support Clang14's dwarf5 yet?
>>
>> Compiling my application with '-gfull -gdwarf-4 -gdwarf64' allows valgrind to function as expected.
>> When using `-gfull -gdwarf-5 -gdwarf64` I get this failure report.
>>
>> ==139537== Memcheck, a memory error detector
>> ==139537== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
>> ==139537== Using Valgrind-3.19.0.GIT and LibVEX; rerun with -h for copyright info
>> ==139537== Command: ./TheAppName
>> ==139537== Parent PID: 139504
>> ==139537==
>> ### unhandled dwarf2 abbrev form code 0x25
>> ### unhandled dwarf2 abbrev form code 0x25
>> ### unhandled dwarf2 abbrev form code 0x25
>> ### unhandled dwarf2 abbrev form code 0x23
>> ==139537== Valgrind: debuginfo reader: ensure_valid failed:
>> ==139537== Valgrind:   during call to ML_(img_get)
>> ==139537== Valgrind:   request for range [11350107, +4) exceeds
>> ==139537== Valgrind:   valid image size of 1584416 for image:
>> ==139537== Valgrind:   "/path/to/TheAppName"
>> ==139537==
>> ==139537== Valgrind: debuginfo reader: Possibly corrupted debuginfo file.
>> ==139537== Valgrind: I can't recover.  Giving up.  Sorry.
>> ==139537==
> As you can see above, valgrind doesn't. clang uses rnglistx and strx
> form codes, which are normally (by gcc) only used with split-dwarf
> (which valgrind doesn't support yet). Best is to simply use -gdwarf-4
> with clang.
>
> Cheers,
>
> Mark
>
>
>
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>

Re: [Valgrind-users] does Valgrind-3.19.0.GIT support Clang14 dwarf 5?

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

Hi Thomas,

On Sun, Feb 13, 2022 at 08:18:48PM +0000, Thomas Wollenzin wrote:
> This is a just a quick question. As I haven't found a sufficient answer in the archives.
> Does Valgrind-3.19.0.GIT support Clang14's dwarf5 yet?
> 
> Compiling my application with '-gfull -gdwarf-4 -gdwarf64' allows valgrind to function as expected.
> When using `-gfull -gdwarf-5 -gdwarf64` I get this failure report.
> 
> ==139537== Memcheck, a memory error detector
> ==139537== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
> ==139537== Using Valgrind-3.19.0.GIT and LibVEX; rerun with -h for copyright info
> ==139537== Command: ./TheAppName
> ==139537== Parent PID: 139504
> ==139537==
> ### unhandled dwarf2 abbrev form code 0x25
> ### unhandled dwarf2 abbrev form code 0x25
> ### unhandled dwarf2 abbrev form code 0x25
> ### unhandled dwarf2 abbrev form code 0x23
> ==139537== Valgrind: debuginfo reader: ensure_valid failed:
> ==139537== Valgrind:   during call to ML_(img_get)
> ==139537== Valgrind:   request for range [11350107, +4) exceeds
> ==139537== Valgrind:   valid image size of 1584416 for image:
> ==139537== Valgrind:   "/path/to/TheAppName"
> ==139537==
> ==139537== Valgrind: debuginfo reader: Possibly corrupted debuginfo file.
> ==139537== Valgrind: I can't recover.  Giving up.  Sorry.
> ==139537==

As you can see above, valgrind doesn't. clang uses rnglistx and strx
form codes, which are normally (by gcc) only used with split-dwarf
(which valgrind doesn't support yet). Best is to simply use -gdwarf-4
with clang.

Cheers,

Mark

[Valgrind-users] does Valgrind-3.19.0.GIT support Clang14 dwarf 5?

[Thomas W. <WOL...@ms...>]

Hi,

This is a just a quick question. As I haven't found a sufficient answer in the archives.
Does Valgrind-3.19.0.GIT support Clang14's dwarf5 yet?

Compiling my application with '-gfull -gdwarf-4 -gdwarf64' allows valgrind to function as expected.
When using `-gfull -gdwarf-5 -gdwarf64` I get this failure report.

==139537== Memcheck, a memory error detector
==139537== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==139537== Using Valgrind-3.19.0.GIT and LibVEX; rerun with -h for copyright info
==139537== Command: ./TheAppName
==139537== Parent PID: 139504
==139537==
### unhandled dwarf2 abbrev form code 0x25
### unhandled dwarf2 abbrev form code 0x25
### unhandled dwarf2 abbrev form code 0x25
### unhandled dwarf2 abbrev form code 0x23
==139537== Valgrind: debuginfo reader: ensure_valid failed:
==139537== Valgrind:   during call to ML_(img_get)
==139537== Valgrind:   request for range [11350107, +4) exceeds
==139537== Valgrind:   valid image size of 1584416 for image:
==139537== Valgrind:   "/path/to/TheAppName"
==139537==
==139537== Valgrind: debuginfo reader: Possibly corrupted debuginfo file.
==139537== Valgrind: I can't recover.  Giving up.  Sorry.
==139537==

Cheers
-Thomas

[Valgrind-users] MEMPOOL_FREE does not appear to work, leak check reports false negative

[John Z. H. <j-...@cs...>]

Hello,

I've been trying to use memcheck with my custom allocator, but I can't
seem to get it to track leaks properly. In particular, (1) it doesn't
appear to keep track of MEMPOOL_FREE requests, and (2) it doesn't even
appear to detect leaks.

This issue was previously reported years ago on KDE
(https://bugs.kde.org/show_bug.cgi?id=233298), and later asked about
on Stack Overflow
(https://stackoverflow.com/questions/30895018/custom-allocator-valgrind-shows-7-allocs-0-frees-no-leaks);
however I'm still able to reproduce this issue on the latest version
(3.19, compiled from latest source).

Consider the following, adapted from the example shown on Stack Overflow:

    /* no-leak.c */
    #include <valgrind/valgrind.h>
    #include <valgrind/memcheck.h>

    int main(int argc, char *argv[]) {
        char pool[100];

        VALGRIND_CREATE_MEMPOOL(pool, 0, 0);
        VALGRIND_MAKE_MEM_NOACCESS(pool, 100);
        VALGRIND_MEMPOOL_ALLOC(pool, pool, 8);
        VALGRIND_MEMPOOL_FREE(pool, pool); // commented out
        VALGRIND_DESTROY_MEMPOOL(pool);    // in leak.c
        return 0;
    }

The main difference is that I also mark pool as NOACCESS; I understand
that this is necessary so that pool is considered a superblock, from
which memory pools may allocate memory.

When I run this, it tells me I have 0 frees, yet it reports that there
aren't any leaks:

    $ ./vg-in-place --leak-check=full --show-leak-kinds=all ~/no-leak
    ==3234114== Memcheck, a memory error detector
    ==3234114== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
    ==3234114== Using Valgrind-3.19.0.GIT and LibVEX; rerun with -h
for copyright info
    ==3234114== Command: /home/j-hui/no-leak
    ==3234114==
    ==3234114==
    ==3234114== HEAP SUMMARY:
    ==3234114==     in use at exit: 0 bytes in 0 blocks
    ==3234114==   total heap usage: 1 allocs, 0 frees, 8 bytes allocated
    ==3234114==
    ==3234114== All heap blocks were freed -- no leaks are possible
    ==3234114==
    ==3234114== For lists of detected and suppressed errors, rerun with: -s
    ==3234114== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

Furthermore, when I comment out the VALGRIND_MEMPOOL_FREE and
VALGRIND_DESTROY_MEMPOOL calls, it reports the exact same thing:

    $ ./vg-in-place --leak-check=full --show-leak-kinds=all ~/leak
    ==3234075== Memcheck, a memory error detector
    ==3234075== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
    ==3234075== Using Valgrind-3.19.0.GIT and LibVEX; rerun with -h
for copyright info
    ==3234075== Command: /home/j-hui/leak
    ==3234075==
    ==3234075==
    ==3234075== HEAP SUMMARY:
    ==3234075==     in use at exit: 0 bytes in 0 blocks
    ==3234075==   total heap usage: 1 allocs, 0 frees, 8 bytes allocated
    ==3234075==
    ==3234075== All heap blocks were freed -- no leaks are possible
    ==3234075==
    ==3234075== For lists of detected and suppressed errors, rerun with: -s
    ==3234075== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

Am I using this API incorrectly? If so, may someone please point out
what I've done wrong? And if not, i.e., this is how the API should be
used, are there any recommended workarounds? (The patch suggested in
the KDE bug tracker, adding cmalloc_n_mallocs++ to various places,
does not seem to fix things for me.)

Thanks in advance!

- John

[Valgrind-users] Virtual Valgrind Fosdem Devroom, Sun 6 Feb

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

Hi valgrind hackers,

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

14:20-15:15 Upstreaming the FreeBSD Port, Paul Floyd
15:20-15:45 Enable AVX-512 instructions in Valgrind, Tanya Volnina
15:50-16:25 Valgrind and debuginfo, Mark Wielaard
16:30-16:55 Valgrind on RISC-V, Petr Pavlu
17:00-17:25 Adding Power ISA 3.1 instruction support, Carl Love
17:30-18:00 20 years of Valgrind, Celebration, Julian Seward

All times are as if the the conference was in Brussels (CET/UTC+1)

The last session, 20 years of Valgrind, Celebration, will not be a
presentation, but an oppertunity for everybody to share their
experiences with Valgrind these last 20 years and to discuss ideas for
the next 20 years.

Participation is free to anybody and registration is optional.
But you might want to read the pratical information beforehand:
https://fosdem.org/2022/practical/online/

See you next Sunday,

Mark

Re: [Valgrind-users] See the address of leaked memory

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

You can do that by using the interactive leak search available via valgrind + gdb + vgdb.

See e.g. https://valgrind.org/docs/manual/mc-manual.html#mc-manual.monitor-commands
in particular the "monitor block_list" command.


Philippe


On Thu, 2022-01-27 at 15:06 -0600, Corey Minyard wrote:
> 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
> 
> 
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users