Re: Clean build on master

[John Darrington]

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'
     >