valgrind-users — General discussion list for Valgrind users

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

[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