On Sun, Aug 27, 2017 at 10:04:55PM +0200, Lars Schneider wrote: > I did run all tests under valgrind using "make valgrind" and I found > the following files with potential issues: > > cat valgrind.out | perl -nE 'say /^==.+\((.+)\:.+\)$/' | sort | uniq -c > 7102 > 2 clone.c > 33 common-main.c > 6 connect.c > 64 git.c > 4 ls-remote.c > 126 run-command.c > 12 transport.c > 7 worktree.c I'm not sure where valgrind.out comes from. The individual test-results/*.out files may have valgrind output, but I don't think they usually contain leak output. Doing "valgrind ./git-upload-pack . </dev/null >/dev/null" mentions leaked memory but not the locations. Adding --leak-check=full shows that most of it comes from format_packet(). And applying Martin's patch drops the "definitely lost" category down to 0 bytes (there's still 550k in "still reachable", but those are in the "exit will free them for us" category). > No mention of "pkt-line.c". Did you run Git with valgrind on one of > your repositories to find it? I'm curious, too. I don't think the valgrind setup in our test suite is great for finding leaks right now. -Peff
