| Message ID | 6ff29e96-7f8d-c354-dced-b1b363e54467@gmail.com (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | abcac2e19faaa0c64693533c9ee368dd4fd581f4 |
| Headers | show |
| Series | ref-filter.c: fix a leak in get_head_description | expand |
On Sun, 25 Sept 2022 at 00:53, Rubén Justo <rjusto@gmail.com> wrote: > > In 2708ce62d2 (branch: sort detached HEAD based on a flag, 2021-01-07) a > call to wt_status_state_free_buffers, responsible of freeing the > resources that could be allocated in the local struct wt_status_state > state, was eliminated. > > The call to wt_status_state_free_buffers was introduced in 962dd7ebc3 > (wt-status: introduce wt_status_state_free_buffers(), 2020-09-27). This > commit brings back that call in get_head_description. > + wt_status_state_free_buffers(&state); > + > return strbuf_detach(&desc, NULL); > } Good catch, and excellent history digging. From the original submission [1] of the patch that dropped this call, I get the feeling that it was originally developed some time earlier. I suspect this call was then accidentally dropped in a rebase before submission. FWIW, this patch is Reviewed-by: Martin Ågren <martin.agren@gmail.com> [1] https://lore.kernel.org/git/20210106100139.14651-1-avarab@gmail.com/ Martin
On Sun, Sep 25 2022, Rubén Justo wrote: > In 2708ce62d2 (branch: sort detached HEAD based on a flag, 2021-01-07) a > call to wt_status_state_free_buffers, responsible of freeing the > resources that could be allocated in the local struct wt_status_state > state, was eliminated. > > The call to wt_status_state_free_buffers was introduced in 962dd7ebc3 > (wt-status: introduce wt_status_state_free_buffers(), 2020-09-27). This > commit brings back that call in get_head_description. > > Signed-off-by: Rubén Justo <rjusto@gmail.com> > > --- > ref-filter.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/ref-filter.c b/ref-filter.c > index fd1cb14b0f..914908fac5 100644 > --- a/ref-filter.c > +++ b/ref-filter.c > @@ -1722,6 +1722,8 @@ char *get_head_description(void) > } else > strbuf_addstr(&desc, _("(no branch)")); > > + wt_status_state_free_buffers(&state); > + > return strbuf_detach(&desc, NULL); > } Thanks, this looks good to me. FWIW I have a local (still unsubmitted) series of leak fixes across the tree which fixed this leak, that commit is presented below as a "I've already been running with this for a while" data point. Thanks! -- >8 -- Subject: [PATCH] wt-status API users: use wt_status_state_free_buffers(), fix leaks Fix a memory that was accidentally introduced in ref-filter.c in 2708ce62d21 (branch: sort detached HEAD based on a flag, 2021-01-07), and one that's been present in builtin/checkout.c since c45f0f525de (switch: reject if some operation is in progress, 2019-03-29). In both cases we should be using the wt_status_state_free_buffers() API introduced in 962dd7ebc3e (wt-status: introduce wt_status_state_free_buffers(), 2020-09-27). Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> --- builtin/checkout.c | 2 ++ ref-filter.c | 2 ++ 2 files changed, 4 insertions(+) diff --git a/builtin/checkout.c b/builtin/checkout.c index 54373424403..549c3d17a1a 100644 --- a/builtin/checkout.c +++ b/builtin/checkout.c @@ -1469,6 +1469,8 @@ static void die_if_some_operation_in_progress(void) "or \"git worktree add\".")); if (state.bisect_in_progress) warning(_("you are switching branch while bisecting")); + + wt_status_state_free_buffers(&state); } static int checkout_branch(struct checkout_opts *opts, diff --git a/ref-filter.c b/ref-filter.c index 45908d4bdfc..81278ec3cf7 100644 --- a/ref-filter.c +++ b/ref-filter.c @@ -1722,6 +1722,8 @@ char *get_head_description(void) } else strbuf_addstr(&desc, _("(no branch)")); + wt_status_state_free_buffers(&state); + return strbuf_detach(&desc, NULL); }
Martin Ågren <martin.agren@gmail.com> writes: > On Sun, 25 Sept 2022 at 00:53, Rubén Justo <rjusto@gmail.com> wrote: >> >> In 2708ce62d2 (branch: sort detached HEAD based on a flag, 2021-01-07) a >> call to wt_status_state_free_buffers, responsible of freeing the >> resources that could be allocated in the local struct wt_status_state >> state, was eliminated. >> >> The call to wt_status_state_free_buffers was introduced in 962dd7ebc3 >> (wt-status: introduce wt_status_state_free_buffers(), 2020-09-27). This >> commit brings back that call in get_head_description. > >> + wt_status_state_free_buffers(&state); >> + >> return strbuf_detach(&desc, NULL); >> } > > Good catch, and excellent history digging. From the original submission > [1] of the patch that dropped this call, I get the feeling that it was > originally developed some time earlier. I suspect this call was then > accidentally dropped in a rebase before submission. > > FWIW, this patch is > > Reviewed-by: Martin Ågren <martin.agren@gmail.com> > > [1] https://lore.kernel.org/git/20210106100139.14651-1-avarab@gmail.com/ > > Martin Thanks, all. Will queue lest I forget, but I presume this is not release critical?
On 26/9/22 10:14, Ævar Arnfjörð Bjarmason wrote: > > Thanks, this looks good to me. FWIW I have a local (still unsubmitted) > series of leak fixes across the tree which fixed this leak, that commit > is presented below as a "I've already been running with this for a > while" data point. That call in die_if_some_operation_in_progress is a good addition to this fix. I haven't found a happy path that leaks there yet, but it is calling for it anyway. And the commit message looks good to me too. So you can add to that patch, if you want: Reviewed-by: Rubén Justo <rjusto@gmail.com> Thanks Martin for your review! Un saludo. > > Thanks! > > -- >8 -- > Subject: [PATCH] wt-status API users: use wt_status_state_free_buffers(), fix > leaks > > Fix a memory that was accidentally introduced in ref-filter.c in > 2708ce62d21 (branch: sort detached HEAD based on a flag, 2021-01-07), > and one that's been present in builtin/checkout.c since > c45f0f525de (switch: reject if some operation is in progress, > 2019-03-29). > > In both cases we should be using the wt_status_state_free_buffers() > API introduced in 962dd7ebc3e (wt-status: introduce > wt_status_state_free_buffers(), 2020-09-27). > > Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> > --- > builtin/checkout.c | 2 ++ > ref-filter.c | 2 ++ > 2 files changed, 4 insertions(+) > > diff --git a/builtin/checkout.c b/builtin/checkout.c > index 54373424403..549c3d17a1a 100644 > --- a/builtin/checkout.c > +++ b/builtin/checkout.c > @@ -1469,6 +1469,8 @@ static void die_if_some_operation_in_progress(void) > "or \"git worktree add\".")); > if (state.bisect_in_progress) > warning(_("you are switching branch while bisecting")); > + > + wt_status_state_free_buffers(&state); > } > > static int checkout_branch(struct checkout_opts *opts, > diff --git a/ref-filter.c b/ref-filter.c > index 45908d4bdfc..81278ec3cf7 100644 > --- a/ref-filter.c > +++ b/ref-filter.c > @@ -1722,6 +1722,8 @@ char *get_head_description(void) > } else > strbuf_addstr(&desc, _("(no branch)")); > > + wt_status_state_free_buffers(&state); > + > return strbuf_detach(&desc, NULL); > } >
On Mon, 26 Sept 2022 at 21:12, Junio C Hamano <gitster@pobox.com> wrote: > > Thanks, all. Will queue lest I forget, but I presume this is not > release critical? Correct. This regressed already in v2.30.1 and v2.31.0 after the leak was originally plugged in v2.29.0. So almost all recentish releases have this minor leak. I'm not even sure it's possible for a single git process to hit this leak more than once today. Martin
In 2708ce62d2 (branch: sort detached HEAD based on a flag, 2021-01-07) a
call to wt_status_state_free_buffers, responsible of freeing the
resources that could be allocated in the local struct wt_status_state
state, was eliminated.
That introduced a leak that occurs with "branch list" in a detached HEAD
state. The number of leaks depends on the references to "refname" in
--sort and --format. With defaults, 3 are leaked: default sort is by
"refname" and default format needs two references of "refname":
%(refname:lstrip=2) and %(refname:rstrip-2).
This doesn't leak:
$ git branch --sort objectname --format '%(objectname)'
This leak once:
$ git branch --sort refname --format '%(refname)'
This leak twice:
$ git branch --sort refname --format '%(refname:lstrip=2)'
Note that each different "atom" is only resolved once (see ref-filter.c).
The call to wt_status_state_free_buffers was introduced in 962dd7ebc3
(wt-status: introduce wt_status_state_free_buffers(), 2020-09-27).
Bring back that call in get_head_description.
Ævar Arnfjörð pointed out [1] that a similar leak is present in
builtin/checkout.c:die_if_some_operation_in_progress(void), since
c45f0f525de (switch: reject if some operation is in progress,
2019-03-29). The leak occurs once with "switch" while bisecting.
Lets call to wc_status_state_free_buffers() there too.
[1] 220926.86bkr24kjw.gmgdl@evledraar.gmail.com
Signed-off-by: Rubén Justo <rjusto@gmail.com>
---
Changes since v1:
- Add details about the leak
- Fix the leak in builtin/checkout.c
Range-diff:
1: 86b7803955 ! 1: 3fa1ddbb30 ref-filter.c: fix a leak in get_head_description
@@ Commit message
resources that could be allocated in the local struct wt_status_state
state, was eliminated.
+ That introduced a leak that occurs with "branch list" in a detached HEAD
+ state. The number of leaks depends on the references to "refname" in
+ --sort and --format. With defaults, 3 are leaked: default sort is by
+ "refname" and default format needs two references of "refname",
+ %(refname:lstrip=2) and %(refname:rstrip-2).
+
+ This doesn't leak:
+ $ git branch --sort objectname --format '%(objectname)'
+
+ This leak once:
+ $ git branch --sort refname --format '%(refname)'
+
+ This leak twice:
+ $ git branch --sort refname --format '%(refname:lstrip=2)'
+
+ Note that each different "atom" is only resolved once (see ref-filter.c).
+
The call to wt_status_state_free_buffers was introduced in 962dd7ebc3
- (wt-status: introduce wt_status_state_free_buffers(), 2020-09-27). This
- commit brings back that call in get_head_description.
+ (wt-status: introduce wt_status_state_free_buffers(), 2020-09-27).
+ Bring back that call in get_head_description.
+
+ Ævar Arnfjörð pointed out [1] that a similar leak is present in
+ builtin/checkout.c:die_if_some_operation_in_progress(void), since
+ c45f0f525de (switch: reject if some operation is in progress,
+ 2019-03-29). The leak ocurrs once with checkout while bisecting.
+
+ Lets call to wc_status_state_free_buffers() there too.
+
+ [1] 220926.86bkr24kjw.gmgdl@evledraar.gmail.com
Signed-off-by: Rubén Justo <rjusto@gmail.com>
+ ## builtin/checkout.c ##
+@@ builtin/checkout.c: static void die_if_some_operation_in_progress(void)
+ "or \"git worktree add\"."));
+ if (state.bisect_in_progress)
+ warning(_("you are switching branch while bisecting"));
++
++ wt_status_state_free_buffers(&state);
+ }
+
+ static int checkout_branch(struct checkout_opts *opts,
+
## ref-filter.c ##
@@ ref-filter.c: char *get_head_description(void)
} else
builtin/checkout.c | 2 ++
ref-filter.c | 2 ++
2 files changed, 4 insertions(+)
diff --git a/builtin/checkout.c b/builtin/checkout.c
index 2a132392fb..659dd5c430 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -1470,6 +1470,8 @@ static void die_if_some_operation_in_progress(void)
"or \"git worktree add\"."));
if (state.bisect_in_progress)
warning(_("you are switching branch while bisecting"));
+
+ wt_status_state_free_buffers(&state);
}
static int checkout_branch(struct checkout_opts *opts,
diff --git a/ref-filter.c b/ref-filter.c
index fd1cb14b0f..914908fac5 100644
--- a/ref-filter.c
+++ b/ref-filter.c
@@ -1722,6 +1722,8 @@ char *get_head_description(void)
} else
strbuf_addstr(&desc, _("(no branch)"));
+ wt_status_state_free_buffers(&state);
+
return strbuf_detach(&desc, NULL);
}
diff --git a/ref-filter.c b/ref-filter.c index fd1cb14b0f..914908fac5 100644 --- a/ref-filter.c +++ b/ref-filter.c @@ -1722,6 +1722,8 @@ char *get_head_description(void) } else strbuf_addstr(&desc, _("(no branch)")); + wt_status_state_free_buffers(&state); + return strbuf_detach(&desc, NULL); }
In 2708ce62d2 (branch: sort detached HEAD based on a flag, 2021-01-07) a call to wt_status_state_free_buffers, responsible of freeing the resources that could be allocated in the local struct wt_status_state state, was eliminated. The call to wt_status_state_free_buffers was introduced in 962dd7ebc3 (wt-status: introduce wt_status_state_free_buffers(), 2020-09-27). This commit brings back that call in get_head_description. Signed-off-by: Rubén Justo <rjusto@gmail.com> --- ref-filter.c | 2 ++ 1 file changed, 2 insertions(+)