Re: [PATCH v2 00/94] libify apply and use lib in am
- From
Johannes Sixt <j6t@kdbg.org>
- Date
- Jun 10, 2016, 17:04 UTC
- Message-ID
- <575AF304.8070407@kdbg.org>
- In-Reply-To
- <alpine.DEB.2.20.1606101307080.3039@virtualbox>
Am 10.06.2016 um 13:11 schrieb Johannes Schindelin:
Show 19 quoted lines
> On Fri, 10 Jun 2016, Christian Couder wrote: >> On Fri, Jun 10, 2016 at 9:01 AM, Johannes Schindelin >> <Johannes.Schindelin@gmx.de> wrote: >>> I lost track in the meantime: were those issues with unclosed file handles >>> and unreleased memory in the error code paths addressed systematically? My >>> mail about that seems to have been left unanswered, almost as if my >>> concerns had been hand-waved away... >> >> Haven't I answered to your email in this thread: >> >> http://thread.gmane.org/gmane.comp.version-control.git/292403/ >> >> ? > > Not really. The reply (which I had not quite connected with my mail > because they were over a week apart) says this: > >> I fixed this by moving the "close(fd)" call just after the >> "apply_patch()" call.
This bug in v1 was discovered by the test suite and fixed in v2.
Show 12 quoted lines
> > and this: > >> I will have another look at the 2 other places where there are >> open()/close() or fopen()/fclose() calls. > > but nothing about a careful, systematic investigation of all error code > paths. As a consequence, I fully expect to encounter test failures as soon > as I test your patch series again, simply because resources are still in > use when they should no longer be used. In other words, my expectations > are now lower than they have been before, my concerns are not at all > addressed.
Do you trust the test suite to some degree? It passes after the above bug was fixed in v2. In addition, haven't found any problems so far during daily use.
Show 5 quoted lines
>> This is the newest iteration: >> >> https://github.com/chriscool/git/commits/libify-apply-use-in-am65 > > And that cute 65 in the name is the revision.
Yeah, that number is painful. I would appreciate an unversioned branch name, too.
-- Hannes