[PATCH 0/2] fast-import input string handling bugs

From: Jeff King <peff@peff.net>
Date: Aug 25, 2019, 08:06 UTC
Message-ID: <20190825080640.GA31453@sigill.intra.peff.net>
In-Reply-To: <20190825065747.GA23806@sigill.intra.peff.net>

On Sun, Aug 25, 2019 at 02:57:48AM -0400, Jeff King wrote:

> And I think this is actually a real bug in the current code! We keep a
> pointer to the encoding string, which survives because of the history.
> But that history is bounded, and we could have an indefinite number of
> changed files in the middle. If I modify t9300 like this:

Here are two patches. The first fixes the existing bug with "encoding", and the second uses the approach I suggested to fix the leak you noticed.

The second one does carry a greater risk of regression than your patch, but I think it's worth it for the fact that it makes any other bugs (like the "encoding" one) more obvious.

  [1/2]: fast-import: duplicate parsed encoding string
  [2/2]: fast-import: duplicate into history rather than passing ownership

 fast-import.c | 11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

-Peff