git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
* revision.c alters commit object state ; also no cleanup
@ 2019-08-26  8:58 Mike Hommey
  2019-08-26 18:14 ` Junio C Hamano
  0 siblings, 1 reply; 3+ messages in thread
From: Mike Hommey @ 2019-08-26  8:58 UTC (permalink / raw)
  To: git

Hi,

First, a little context: As you may have noticed, I've recently found a
small bunch of memory leaks in different parts of the code base. The
reason I did is that git-cinnabar[1] uses libgit.a, and I very recently
upgraded its CI to use a slightly more recent version of GCC, which
either enabled leak detection by default in ASAN or detect more leaks
than before. Anyways, my CI was busted because of leaks detected after
the upgrade, which made me look around.

git-cinnabar does make some specific uses of libgit.a that git itself
doesn't, and this is where things kind of fall apart:

First, revision.c doesn't come with a function to clear a struct
rev_info. I did create a function that does enough cleanup for my own
use (which turned out to be not enough), but I'm wondering if git
shouldn't itself have one in revision.c (and seeing that there's now
e.g. repo_clear, which didn't exist when I started git-cinnabar, I think
the answer would be that it should).

Then, revision.c kind of does nasty things to commit objects:
- remove_duplicate_parents alters commit->parents to skip duplicates[2]
- try_to_simplify_commit removes all parents but one[3] or all of them
  [4] in some cases

That's for the case that I did encounter. Maybe there's more.

One problem this causes is that it leaks the commit_list items that used
to contain the removed parents.

Another problem is that if something else uses the commits afterwards,
those commits parents don't match what you'd get before revision
walking. And I don't know how this should be addressed.

Ideas welcome.

Relatedly, the subthread that started at
<xmqqlfvlne3k.fsf@gitster-ct.c.googlers.com> is kind of relevant. There
are two main reasons I'm using libgit.a: one is that I'm doing things
low-level enough that I don't know any other library that would work for
my use case. Another is that I was hoping that in the long term, it
could be merged into git.git. I guess the more time passes, the less
likely the latter is to happen. Which is fine, but it's good to know.

Mike


1. https://github.com/glandium/git-cinnabar/
2. https://github.com/git/git/blob/745f6812895b31c02b29bdfe4ae8e5498f776c26/revision.c#L2742
3. https://github.com/git/git/blob/745f6812895b31c02b29bdfe4ae8e5498f776c26/revision.c#L869
4. https://github.com/git/git/blob/745f6812895b31c02b29bdfe4ae8e5498f776c26/revision.c#L888

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: revision.c alters commit object state ; also no cleanup
  2019-08-26  8:58 revision.c alters commit object state ; also no cleanup Mike Hommey
@ 2019-08-26 18:14 ` Junio C Hamano
  2019-08-27 23:21   ` Mike Hommey
  0 siblings, 1 reply; 3+ messages in thread
From: Junio C Hamano @ 2019-08-26 18:14 UTC (permalink / raw)
  To: Mike Hommey; +Cc: git

Mike Hommey <mh@glandium.org> writes:

> First, revision.c doesn't come with a function to clear a struct
> rev_info....
> Then, revision.c kind of does nasty things to commit objects...

Yeah, these two stem from the "run once and let exit() clean things
up" design the oldest part of the system shares.  Regarding the
latter, i.e. parent rewriting, I recall that there is a codepath
that saves the original true parents away in a second field when we
know we would want to show it (and avoid the overhead of copying
when we do not have to), so you should be able to extend it to keep
the original parent list.


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: revision.c alters commit object state ; also no cleanup
  2019-08-26 18:14 ` Junio C Hamano
@ 2019-08-27 23:21   ` Mike Hommey
  0 siblings, 0 replies; 3+ messages in thread
From: Mike Hommey @ 2019-08-27 23:21 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

On Mon, Aug 26, 2019 at 11:14:13AM -0700, Junio C Hamano wrote:
> Mike Hommey <mh@glandium.org> writes:
> 
> > First, revision.c doesn't come with a function to clear a struct
> > rev_info....
> > Then, revision.c kind of does nasty things to commit objects...
> 
> Yeah, these two stem from the "run once and let exit() clean things
> up" design the oldest part of the system shares.  Regarding the
> latter, i.e. parent rewriting, I recall that there is a codepath
> that saves the original true parents away in a second field when we
> know we would want to show it (and avoid the overhead of copying
> when we do not have to), so you should be able to extend it to keep
> the original parent list.

I guess you're refering to save_parents/get_saved_parents? Would it make
sense for things to be reversed, as in, make revision.c keep the
simplified parents separately, and traverse through that?

Mike

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2019-08-27 23:21 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-08-26  8:58 revision.c alters commit object state ; also no cleanup Mike Hommey
2019-08-26 18:14 ` Junio C Hamano
2019-08-27 23:21   ` Mike Hommey

Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).