[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Clean build on master
From: |
John Darrington |
Subject: |
Re: Clean build on master |
Date: |
Sat, 11 Jul 2020 07:45:25 +0200 |
User-agent: |
Mutt/1.10.1 (2018-07-13) |
You are right. "definitely lost" is not good. I've pushed a fix for that
particular
problem. It is strange that valgrind picks up this error when sanitize=address
did
not.
I don't think there is any hard and fast rule to say when valgrind "passes".
Rather,
it's a tool which can flag issues which might be worthy of further
investigation.
J'
On Thu, Jul 09, 2020 at 01:41:50PM +0200, Friedrich Beckmann wrote:
Hi John,
i run ???make check-valgrind??? and I see on test 0530
530: EXAMINE -- Crash on unrepresentable graphs ok
the following in the valgrind log file
==492707== LEAK SUMMARY:
==492707== definitely lost: 56 bytes in 1 blocks
==492707== indirectly lost: 103,823 bytes in 4,525 blocks
==492707== possibly lost: 1,514 bytes in 21 blocks
==492707== still reachable: 640,055 bytes in 3,693 blocks
==492707== of which reachable via heuristic:
==492707== length64 : 80 bytes in 2
blocks
==492707== newarray : 1,568 bytes in 18
blocks
==492707== suppressed: 162,383 bytes in 3,703 blocks
==492707== Reachable blocks (those to which a pointer was found) are not
shown.
==492707== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==492707==
==492707== For lists of detected and suppressed errors, rerun with: -s
==492707== ERROR SUMMARY: 22 errors from 22 contexts (suppressed: 26 from
26)
I thought that ???definitely lost??? is maybe not a good message??? How do
you
interpret these ???lost??? messages? How do I decide that valgrind is pass?
Fritz
> Am 28.06.2020 um 13:27 schrieb John Darrington
<john@darrington.wattle.id.au>:
>
> As of commit d9c674e05188abe16dc9440a8c1597632982dd48, make check runs
cleanly when -fsanitize=address
> is in CFLAGS. There are no leaks, no buffer overflows, no
use-after-free errors etc. It would be
> great if we could try to keep it that way.
>
> The GUI is another matter however, I'm sure there are a lot of things
there which still need to be
> fixed.
>
> J'
>