mirrors/git
1
0
Fork 0
mirror of https://github.com/git/git.git synced 2024-11-01 14:57:52 +01:00
Code Activity
git/t/t4254-am-corrupt.sh

38 lines
891 B
Bash
Raw Normal View History

fix "git apply --index ..." not to deref NULL I noticed this when "git am CORRUPTED" unexpectedly failed with an odd diagnostic, and even removed one of the files it was supposed to have patched. Reproduce with any valid old/new patch from which you have removed the "+++ b/FILE" line. You'll see a diagnostic like this fatal: unable to write file '(null)' mode 100644: Bad address and you'll find that FILE has been removed. The above is on glibc-based systems. On other systems, rather than getting "null", you may provoke a segfault as git tries to dereference the NULL file name. Signed-off-by: Jim Meyering <meyering@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-12 16:33:54 +02:00
#!/bin/sh
test_description='git am with corrupt input'
. ./test-lib.sh
test_expect_success setup '
t4254: modernize tests - Don't start tests with 'test $? = 0' to catch preparation done outside the test_expect_success block. - Move writing the bogus patch and the expected output into the appropriate test_expect_success blocks. - Use the test_must_fail helper instead of manually checking for non-zero exit code. - Use the debug-friendly test_path_is_file helper instead of 'test -f'. - No space after '>'. Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-16 14:27:16 +02:00
# Note the missing "+++" line:
cat >bad-patch.diff <<-\EOF &&
From: A U Thor <au.thor@example.com>
diff --git a/f b/f
index 7898192..6178079 100644
--- a/f
@@ -1 +1 @@
-a
+b
EOF
echo a >f &&
fix "git apply --index ..." not to deref NULL I noticed this when "git am CORRUPTED" unexpectedly failed with an odd diagnostic, and even removed one of the files it was supposed to have patched. Reproduce with any valid old/new patch from which you have removed the "+++ b/FILE" line. You'll see a diagnostic like this fatal: unable to write file '(null)' mode 100644: Bad address and you'll find that FILE has been removed. The above is on glibc-based systems. On other systems, rather than getting "null", you may provoke a segfault as git tries to dereference the NULL file name. Signed-off-by: Jim Meyering <meyering@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-12 16:33:54 +02:00
git add f &&
test_tick &&
git commit -m initial
'
# This used to fail before, too, but with a different diagnostic.
# fatal: unable to write file '(null)' mode 100644: Bad address
# Also, it had the unwanted side-effect of deleting f.
test_expect_success 'try to apply corrupted patch' '
am: move advice.amWorkDir parsing back to advice.c The only benefit from this move (apart from cleaner code) is that advice.amWorkDir should now show up in `git help --config`. There should be no regression since advice config is always read by the git_default_config(). While at there, use advise() like other code. We now get "hint: " prefix and the output is stderr instead of stdout (which is also the reason for the test update because stderr is checked in a following test and the extra advice can fail it). Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-26 15:55:27 +02:00
test_must_fail git -c advice.amWorkDir=false am bad-patch.diff 2>actual
fix "git apply --index ..." not to deref NULL I noticed this when "git am CORRUPTED" unexpectedly failed with an odd diagnostic, and even removed one of the files it was supposed to have patched. Reproduce with any valid old/new patch from which you have removed the "+++ b/FILE" line. You'll see a diagnostic like this fatal: unable to write file '(null)' mode 100644: Bad address and you'll find that FILE has been removed. The above is on glibc-based systems. On other systems, rather than getting "null", you may provoke a segfault as git tries to dereference the NULL file name. Signed-off-by: Jim Meyering <meyering@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-12 16:33:54 +02:00
'
test_expect_success 'compare diagnostic; ensure file is still here' '
builtin/apply: make find_header() return -128 instead of die()ing To libify `git apply` functionality we have to signal errors to the caller instead of die()ing. To do that in a compatible manner with the rest of the error handling in builtin/apply.c, let's make find_header() return -128 instead of calling die(). We could make it return -1, unfortunately find_header() already returns -1 when no header is found. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-08 23:03:02 +02:00
echo "error: git diff header lacks filename information (line 4)" >expected &&
t4254: modernize tests - Don't start tests with 'test $? = 0' to catch preparation done outside the test_expect_success block. - Move writing the bogus patch and the expected output into the appropriate test_expect_success blocks. - Use the test_must_fail helper instead of manually checking for non-zero exit code. - Use the debug-friendly test_path_is_file helper instead of 'test -f'. - No space after '>'. Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-16 14:27:16 +02:00
test_path_is_file f &&
i18n: apply: mark error message for translation Update test to reflect changes. Signed-off-by: Vasco Almeida <vascomalmeida@sapo.pt> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-17 15:15:26 +02:00
test_i18ncmp expected actual
fix "git apply --index ..." not to deref NULL I noticed this when "git am CORRUPTED" unexpectedly failed with an odd diagnostic, and even removed one of the files it was supposed to have patched. Reproduce with any valid old/new patch from which you have removed the "+++ b/FILE" line. You'll see a diagnostic like this fatal: unable to write file '(null)' mode 100644: Bad address and you'll find that FILE has been removed. The above is on glibc-based systems. On other systems, rather than getting "null", you may provoke a segfault as git tries to dereference the NULL file name. Signed-off-by: Jim Meyering <meyering@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-12 16:33:54 +02:00
'
test_done
Copy permalink