On Mon, Nov 28, 2022 at 10:57:02PM +0100, René Scharfe wrote: > >> diff --git a/revision.c b/revision.c > >> index 439e34a7c5..6a51ef9418 100644 > >> --- a/revision.c > >> +++ b/revision.c > >> @@ -3055,6 +3055,7 @@ void release_revisions(struct rev_info *revs) > >> release_revisions_mailmap(revs->mailmap); > >> free_grep_patterns(&revs->grep_filter); > >> /* TODO (need to handle "no_free"): diff_free(&revs->diffopt) */ > >> + FREE_AND_NULL(revs->diffopt.parseopts); > >> diff_free(&revs->pruning); > >> reflog_walk_info_release(revs->reflog_info); > >> release_revisions_topo_walk_info(revs->topo_walk_info); > > > > At this point I'm unclear on what & why this is needed? I.e. once we > > narrowly fix the >1 "--filter" options what still fails? > > As I wrote: A call to an initialization function followed by a call to a > cleanup function and nothing else shouldn't leak. There are examples of > repo_init_revisions()+release_revisions() without setup_revisions() or > diff_setup_done() beyond pack-objects. I mentioned prune, but there are > more, e.g. in sequencer.c. I tend to agree with you; an init+release combo should release all memory. We _can_ work around it in the caller here, but I think we are better to correct the root cause. I do think what Ævar is saying is: once we have fixed the bug, why are more changes needed? I.e., why would we get rid of the lazy-init. IMHO the answer is that the lazy-init is a more complex pattern, and requires more boilerplate code (which can lead to more bugs, as we saw). So once the bug is fixed, this is purely about cleanup/simplification (if one ignores the C-standard issues), but I tend to think it is one worth doing. (Apologies to Ævar if I'm mis-stating your position). > > But in general: I don't really think this sort of thing is worth > > it. Here we're reaching into a member of "revs->diffopt" behind its back > > rather than calling diff_free(). I think we should just focus on being > > able to do do that safely. > > Sure, but the FREE_AND_NULL call is simple and safe, while diff_free() > is complicated and calling it one time too many can hurt. Again, I'd agree with you here. In the long run, yes, we want diff_free(). But if that is not ready yet, the FREE_AND_NULL() is a stepping stone that takes us in the right direction and which we can do immediately. > > WIP patches I have in that direction, partially based on your previous > > "is_dead" suggestion: > > > > https://github.com/avar/git/commit/e02a15f6206 > > https://github.com/avar/git/commit/c718f36566a > > Copy-typed the interesting parts of the first patch like a medieval monk > because there doesn't seem to be a download option. :-| This is the actual reason I responded to your message. ;) Try: https://github.com/avar/git/commit/e02a15f6206.patch etc. I don't think there's a "raw patch" link or similar in the interface, though. You have to just know about it. -Peff
