Without this strbuf_release, it yields a double free later, the command is
in fact stashed, and this is not a memory leak.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
---
On Fri, Oct 26, 2007 at 06:53:01AM +0000, Shawn O. Pearce wrote:
> cpettitt <cpettitt@gmail.com> wrote:
> > I'm seeing the following errors when I run git-fast-import (on Intel
> > OSX) with some data from a git-p4 import:
> ....
> > I believe these errors started showing up in commit
> > b449f4cfc972929b638b90d375b8960c37790618. I did a bisect on
> > fast-import.c and this was the first commit for that file that
> > exhibits this bug with the input.
> >=20
> > I thought I would check with the list to see if this is a known issue
> > before I spend time trying to dig into it.
>=20
> It is a known issue. Someone else has reported the same thing,
> and bisecting pointed at the same commit. But they weren't able
> to supply their input data for debugging by Pierre or myself as it
> was a private project and they haven't had a chance to attempt to
> debug it on their own.
>=20
> Any light you can shed on the problem would be most appreciated.
Wait, I believe I found the problem thanks to the "free" that fails.
Could you please try that patch ? looking at the diff again, and
knowing the issue is with an rc->buf (which are old command_buf
stashed buffers) it looks like I migrated cmd_data improperly.
--=20
=C2=B7O=C2=B7 Pierre Habouzit
=C2=B7=C2=B7O madcoder@debia=
n.org
OOO http://www.madism.org
fast-import.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/fast-import.c b/fast-import.c
index 6f888f6..f93d7d6 100644
--- a/fast-import.c
+++ b/fast-import.c
@@ -1616,6 +1616,7 @@ static void cmd_data(struct strbuf *sb)
char *term =3D xstrdup(command_buf.buf + 5 + 2);
size_t term_len =3D command_buf.len - 5 - 2;
=20
+ strbuf_detach(&command_buf, NULL);
for (;;) {
if (strbuf_getline(&command_buf, stdin, '\n') =3D=3D EOF)
die("EOF in data (terminator '%s' not found)", term);
--=20
1.5.3.4.1358.gfae55-dirty
