Re: monit ./CHANGES.txt ./configure.ac ./gc.c ./l.l...

[Jan-Henrik Haukeland]

Christian Hopp <address@hidden> writes:

> http://savannah.gnu.org/cgi-bin/viewcvs/monit/monit/l.l.diff?tr1=1.62&tr2=1.63&r1=text&r2=text
> http://savannah.gnu.org/cgi-bin/viewcvs/monit/monit/p.y.diff?tr1=1.135&tr2=1.136&r1=text&r2=text

==8846== 32 bytes in 1 blocks are definitely lost in loss record 85 of 144
==8846==    at 0x40027DDE: calloc (vg_replace_malloc.c:273)
==8846==    by 0x80568F4: xcalloc (xmalloc.c:93)
==8846==    by 0x805F323: addgeneric (p.y:1738)
==8846==    by 0x805DA1E: yyparse (p.y:716)
==8846==    by 0x805E673: parse (p.y:1091)
==8846==    by 0x804EB7F: do_init (monitor.c:199)
==8846== 
==8846== 
==8846== 78 bytes in 2 blocks are definitely lost in loss record 98 of 144
==8846==    at 0x40027904: malloc (vg_replace_malloc.c:153)
==8846==    by 0x80568A5: xmalloc (xmalloc.c:64)
==8846==    by 0x805696E: xstrdup (xmalloc.c:112)
==8846==    by 0x80614E6: handle_quoted_string (l.l:448)
==8846==    by 0x80607E1: yylex (l.l:283)
==8846==    by 0x805D163: yyparse (/usr/share/bison/bison.simple:573)
==8846== 
==8846== LEAK SUMMARY:
==8846==    definitely lost: 110 bytes in 3 blocks.
==8846==    possibly lost:   0 bytes in 0 blocks.
==8846==    still reachable: 39961 bytes in 1261 blocks.
==8846==         suppressed: 200 bytes in 1 blocks.
==8846== Reachable blocks (those to which a pointer was found) are not shown.
==8846== To see them, rerun with: --show-reachable=yes


Memory leak! I recommend or nearly insist that new code should be run
through valgrind without any leaks before it is checked in.

For instance add the following function to your .bashrc file and run:
vvalgrind ./monit -I

-----------8<----------------------------------------------------------------
vvalgrind() {

valgrind -v --leak-check=yes --leak-resolution=high --num-callers=6 
--freelist-vol=10000000 --partial-loads-ok=no --show-reachable=no  "$@"

}
-----------8<----------------------------------------------------------------


Ps. It's bedtime her, but I can look into this tomorrow if it's not
already fixed by then.

-- 
Jan-Henrik Haukeland