[Top][All Lists]

[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 
problem.  It is strange that valgrind picks up this error when sanitize=address 

I don't think there is any hard and fast rule to say when valgrind "passes".  
it's a tool which can flag issues which might be worthy of further 


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 
     ==492707==                         newarray           : 1,568 bytes in 18 
     ==492707==         suppressed: 162,383 bytes in 3,703 blocks
     ==492707== Reachable blocks (those to which a pointer was found) are not 
     ==492707== To see them, rerun with: --leak-check=full --show-leak-kinds=all
     ==492707== For lists of detected and suppressed errors, rerun with: -s
     ==492707== ERROR SUMMARY: 22 errors from 22 contexts (suppressed: 26 from 
     I thought that ???definitely lost??? is maybe not a good message??? How do 
     interpret these ???lost??? messages? How do I decide that valgrind is pass?
     > Am 28.06.2020 um 13:27 schrieb John Darrington 
     > 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'

reply via email to

[Prev in Thread] Current Thread [Next in Thread]