Re: [PATCH 2/2] apply: handle assertion failure gracefully
- From
René Scharfe <l.s.r@web.de>
- Date
- Jun 27, 2017, 17:03 UTC
- Message-ID
- <5128cdf1-39fc-59ca-5640-801777bac2fa@web.de>
- In-Reply-To
- <05fe5800-ebc0-76d7-579d-77f64a851fc1@web.de>
Am 28.02.2017 um 11:50 schrieb René Scharfe:
Show 62 quoted lines
> Am 27.02.2017 um 23:33 schrieb Junio C Hamano: >> René Scharfe <l.s.r@web.de> writes: >> >>> Am 27.02.2017 um 21:04 schrieb Junio C Hamano: >>>> René Scharfe <l.s.r@web.de> writes: >>>> >>>>>> diff --git a/apply.c b/apply.c >>>>>> index cbf7cc7f2..9219d2737 100644 >>>>>> --- a/apply.c >>>>>> +++ b/apply.c >>>>>> @@ -3652,7 +3652,6 @@ static int check_preimage(struct apply_state *state, >>>>>> if (!old_name) >>>>>> return 0; >>>>>> >>>>>> - assert(patch->is_new <= 0); >>>>> >>>>> 5c47f4c6 (builtin-apply: accept patch to an empty file) added that >>>>> line. Its intent was to handle diffs that contain an old name even for >>>>> a file that's created. Citing from its commit message: "When we >>>>> cannot be sure by parsing the patch that it is not a creation patch, >>>>> we shouldn't complain when if there is no such a file." Why not stop >>>>> complaining also in case we happen to know for sure that it's a >>>>> creation patch? I.e., why not replace the assert() with: >>>>> >>>>> if (patch->is_new == 1) >>>>> goto is_new; >>>>> >>>>>> previous = previous_patch(state, patch, &status); >>>> >>>> When the caller does know is_new is true, old_name must be made/left >>>> NULL. That is the invariant this assert is checking to catch an >>>> error in the calling code. >>> >>> There are some places in apply.c that set ->is_new to 1, but none of >>> them set ->old_name to NULL at the same time. >> >> I thought all of these are flipping ->is_new that used to be -1 >> (unknown) to (now we know it is new), and sets only new_name without >> doing anything to old_name, because they know originally both names >> are set to NULL. >> >>> Having to keep these two members in sync sounds iffy anyway. Perhaps >>> accessors can help, e.g. a setter which frees old_name when is_new is >>> set to 1, or a getter which returns NULL for old_name if is_new is 1. >> >> Definitely, the setter would make it harder to make the mistake. > > When I added setters, apply started to passed NULL to unlink(2) and > rmdir(2) in some of the new tests, which still failed. > > That's because three of the diffs trigger both gitdiff_delete(), which > sets is_delete and old_name, and gitdiff_newfile(), which sets is_new > and new_name. Create and delete equals move, right? Or should we > error out at this point already? > > The last new diff adds a new file that is copied. Sounds impossible. > How about something like this, which forbids combinations that make no > sense. Hope it's not too strict; at least all tests succeed. > > --- > apply.c | 79 ++++++++++++++++++++++++++++++++++++++++++++++++++--------------- > 1 file changed, 61 insertions(+), 18 deletions(-)
Thought a bit more about it, and as a result here's a simpler approach:
-- >8 -- Subject: [PATCH] apply: check git diffs for mutually exclusive header lines
A file can either be added, removed, copied, or renamed, but no two of these actions can be done by the same patch. Some of these combinations provoke error messages due to missing file names, and some are only caught by an assertion. Check git patches already as they are parsed and report conflicting lines on sight.
Found by Vegard Nossum using AFL.
Reported-by: Vegard Nossum <vegard.nossum@oracle.com> Signed-off-by: Rene Scharfe <l.s.r@web.de> --- apply.c | 14 ++++++++++++++ apply.h | 1 + t/t4136-apply-check.sh | 18 ++++++++++++++++++ 3 files changed, 33 insertions(+)
diff --git a/apply.c b/apply.c index 8cd6435c74..8a5e44c474 100644 --- a/apply.c +++ b/apply.c @@ -1312,6 +1312,18 @@ static char *git_header_name(struct apply_state *state, } } +static int check_header_line(struct apply_state *state, struct patch *patch) +{ + int extensions = (patch->is_delete == 1) + (patch->is_new == 1) + + (patch->is_rename == 1) + (patch->is_copy == 1); + if (extensions > 1) + return error(_("inconsistent header lines %d and %d"), + state->extension_linenr, state->linenr); + if (extensions && !state->extension_linenr) + state->extension_linenr = state->linenr; + return 0; +} + /* Verify that we recognize the lines following a git header */ static int parse_git_header(struct apply_state *state, const char *line, @@ -1378,6 +1390,8 @@ static int parse_git_header(struct apply_state *state, res = p->fn(state, line + oplen, patch); if (res < 0) return -1; + if (check_header_line(state, patch)) + return -1; if (res > 0) return offset; break; diff --git a/apply.h b/apply.h index b3d6783d55..b52078b486 100644 --- a/apply.h +++ b/apply.h @@ -79,6 +79,7 @@ struct apply_state { /* Various "current state" */ int linenr; /* current line number */ + int extension_linenr; /* first line specifying delete/new/rename/copy */ struct string_list symlink_changes; /* we have to track symlinks */ /* diff --git a/t/t4136-apply-check.sh b/t/t4136-apply-check.sh index 4b0a374b63..6d92872318 100755 --- a/t/t4136-apply-check.sh +++ b/t/t4136-apply-check.sh @@ -29,4 +29,22 @@ test_expect_success 'apply exits non-zero with no-op patch' ' test_must_fail git apply --check input ' +test_expect_success 'invalid combination: create and copy' ' + test_must_fail git apply --check - <<-\EOF + diff --git a/1 b/2 + new file mode 100644 + copy from 1 + copy to 2 + EOF +' + +test_expect_success 'invalid combination: create and rename' ' + test_must_fail git apply --check - <<-\EOF + diff --git a/1 b/2 + new file mode 100644 + rename from 1 + rename to 2 + EOF +' + test_done
-- 2.13.2