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@xxxxxxxxxx> --- On Fri, Oct 26, 2007 at 06:53:01AM +0000, Shawn O. Pearce wrote: > cpettitt <cpettitt@xxxxxxxxx> 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. > > > > 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. > > 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. > > 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. -- ·O· Pierre Habouzit ··O madcoder@xxxxxxxxxx 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 = xstrdup(command_buf.buf + 5 + 2); size_t term_len = command_buf.len - 5 - 2; + strbuf_detach(&command_buf, NULL); for (;;) { if (strbuf_getline(&command_buf, stdin, '\n') == EOF) die("EOF in data (terminator '%s' not found)", term); -- 1.5.3.4.1358.gfae55-dirty
Attachment:
pgpp5XUwpKY7A.pgp
Description: PGP signature
