valgrind-users — General discussion list for Valgrind users

[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

[Valgrind-users] pthread_mutex_destroy with invalid argument

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

Hello,

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

The invocation is:

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

The errors are:

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

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

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

Thank you.

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

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

Hi John



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


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


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


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


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


That's the one.


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


For instance (tests done with GCC 9.4 on FreeBSD)


cd memcheck/tests

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


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

[SNIP other candidates and 2nd error]


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


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


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


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


A+

Paul

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

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

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

Hi

That's for me.

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

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


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


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

SNIP

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

SNIP

#if __cpp_sized_deallocation

this is the one we want

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


Does yours look similar?


Does the following change help


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

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

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

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

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


A+

Paul

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

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

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

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

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

Re: [Valgrind-users] Info message

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

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

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

Re: [Valgrind-users] Info message

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

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

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

Re: [Valgrind-users] Info message

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

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

Hi

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

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

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

Run

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

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

Then run

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

A+
Paul

[Valgrind-users] Info message

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

Hi ,

I'm getting this message when I run :

valgrind --leak-check=full ./MyProg

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

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

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

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

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