git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Possibly solved invalid free() in git-remote-http from Git 1.7.2.1

From
Jeff King <peff@peff.net>
Date
Aug 1, 2011, 18:00 UTC
Message-ID
<20110801180018.GA10636@sigill.intra.peff.net>
In-Reply-To
<CACBZZX5N0DaSrU6rxW=PTMQ8b6c_sxMFJQHMaZy1L138eFFo6w@mail.gmail.com>
On Mon, Aug 01, 2011 at 05:42:54PM +0200, Ævar Arnfjörð Bjarmason wrote:
Show 40 quoted lines
> On Mon, Aug 1, 2011 at 17:39, Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:
> > On Mon, Aug 1, 2011 at 17:22, Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:
> >> In case anyone would like to look into this I had this undiagnosed
> >> free() error from git-remote-http in git version 1.7.2.1:
> >
> > Actually this is still an issue in master, CC-ing Tay who introduced
> > this error.
> >
> > This evil hack would get around it most of the time, but would
> > introduce another race condition:
> 
> *brainfart*. This would be better:
> 
>     diff --git a/http.c b/http.c
>     index a1ea3db..c5da23a 100644
>     --- a/http.c
>     +++ b/http.c
>     @@ -1298,7 +1298,7 @@ struct http_object_request
> *new_http_object_request(const char *base_url,
>                             if (ftruncate(freq->localfile, 0) < 0) {
>                                     error("Couldn't truncate temporary
> file %s: %s",
>                                               freq->tmpfile, strerror(errno));
>     -                               goto abort;
>     +                               goto abort_url;
>                             }
>                     }
>             }
>     @@ -1328,9 +1328,10 @@ struct http_object_request
> *new_http_object_request(const char *base_url,
> 
>             return freq;
> 
>     +abort_url:
>     +       free(freq->url);
>      abort:
>             free(filename);
>     -       free(freq->url);
>             free(freq);
>             return NULL;
Hmm. The memory management in the function seems weird to me.

Why do we free filename only on abort? Are we leaking it otherwise? Even weirder, AFAICT, filename can only ever point to the static buffer returned by sha1_file_name. So it should _never_ be freed. And I'm surprised glibc's free() checker isn't complaining about that. Am I reading it wrong?

With respect to freq->url, from your patch I expected that some code paths would allocate it on the heap, and some would not. But it looks like there is only one spot, and the problem is that freq is filled with uninitialized cruft. Wouldn't it be simpler to just s/xmalloc/xcalloc/, and then you know all of the pointers are initialized properly to NULL? You can also get rid of the memset-to-zero later in the function.

-Peff
Previous: Ævar Arnfjörð BjarmasonNext: Tay Ray Chuan
Message 4 of 7 in “Possibly solved invalid free() in git-remote-http from Git 1.7.2.1”
  1. Ævar Arnfjörð BjarmasonAug 1, 2011
  2. Ævar Arnfjörð BjarmasonAug 1, 2011
  3. Ævar Arnfjörð BjarmasonAug 1, 2011
  4. Jeff KingAug 1, 2011
  5. Tay Ray ChuanAug 2, 2011
  6. Jeff KingAug 2, 2011
  7. http.c: fix an invalid free()Tay Ray Chuan, Aug 3, 2011

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.