On 2022/09/06 12:11:16 +0200, Omar Polo <op@omarpolo.com> wrote:
> played again a bit with gotwebd under valgrind and found some other
> leaks.  two are in gotwebd and the others in lib/.
> 
> some of the got_repo_get_* functions allocate a string that we forget
> to free.  I did a round of checking and fixed the ones that were
> (possibly) leaking memory.  Should we consider to rename some of this
> functions to avoid the ambiguity?  (some of the got_repo_get_* returns
> const char *, other don't.)

I forgot one thing.  Valgrind now is mostly happy with gotwebd, it
only complains about some strings allocated by yacc or config_* that
are not free'd but I didn't bother trying to fix them because they're
not real interesting leaks.

Valgrind however reports also this one that is interesting:

==5901== 3,301 (864 direct, 2,437 indirect) bytes in 9 blocks are definitely lost in loss record 43 of 50
==5901==    at 0x48A6BEE: calloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==5901==    by 0x14C213: got_object_commit_alloc_partial (in /home/op/w/got-portable/gotwebd/gotwebd)
==5901==    by 0x15A0DD: get_commit_from_imsg (in /home/op/w/got-portable/gotwebd/gotwebd)
==5901==    by 0x15A574: got_privsep_recv_commit (in /home/op/w/got-portable/gotwebd/gotwebd)
==5901==    by 0x1440AE: request_packed_commit (in /home/op/w/got-portable/gotwebd/gotwebd)
==5901==    by 0x144124: read_packed_commit_privsep (in /home/op/w/got-portable/gotwebd/gotwebd)
==5901==    by 0x1444D7: open_commit (in /home/op/w/got-portable/gotwebd/gotwebd)
==5901==    by 0x1445F6: got_object_open_as_commit (in /home/op/w/got-portable/gotwebd/gotwebd)
==5901==    by 0x12760B: add_branch_tip (in /home/op/w/got-portable/gotwebd/gotwebd)
==5901==    by 0x14B943: got_object_idset_for_each (in /home/op/w/got-portable/gotwebd/gotwebd)
==5901==    by 0x127804: fetch_commits_from_open_branches (in /home/op/w/got-portable/gotwebd/gotwebd)
==5901==    by 0x127C7F: got_commit_graph_iter_next (in /home/op/w/got-portable/gotwebd/gotwebd)

and suggests that we're no free'ing the memory for the objects opened
in add_branch_tip in the commit_graph.c; by reading the code however i
don't see how it happens.