Re: Test failures in t4034

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Brian Gernhardt <brian@xxxxxxxxxxxxxxxxxxxxx> writes:

> I've been getting a couple of test failures and finally had the time to track them down.
>
> t4034-diff-words fails tests "22 diff driver 'bibtex'" and "26
> diff driver 'html'".  Bisecting shows that the file started giving
> me errors in commit 8d96e72 "t4034: bulk verify builtin word regex
> sanity", which appears to introduce those tests.  I don't see
> anything obviously wrong with the tests and I'm not familiar with
> the diff-words code, so I'm not sure what's wrong.
>
> I am running on OS X 10.8, with Xcode 4.4.1 (llvm-gcc 4.2.1).
>
> Test results follow:
>
> ---------- 8< ----------
>
> expecting success: 
> 		cp "$TEST_DIRECTORY/t4034/bibtex/pre" \
> 			"$TEST_DIRECTORY/t4034/bibtex/post" \
> 			"$TEST_DIRECTORY/t4034/bibtex/expect" . &&
> 		echo "* diff=bibtex" >.gitattributes &&
> 		word_diff --color-words
> 	
> --- expect	2012-08-18 05:54:29.000000000 +0000
> +++ output.decrypted	2012-08-18 05:54:29.000000000 +0000
> @@ -8,8 +8,8 @@
>    author={Aldous, <RED>D.<RESET><GREEN>David<RESET>},
>    journal={Information Theory, IEEE Transactions on},<RESET>
>    volume={<RED>33<RESET><GREEN>Bogus.<RESET>},
> -  number={<RED>2<RESET><GREEN>4<RESET>},
> +  number={4},
>    pages={219--223},<RESET>
> -  year=<GREEN>1987,<RESET>
> -<GREEN>  note={This is in fact a rather funny read since ethernet works well in practice. The<RESET> {<RED>1987<RESET><GREEN>\em pre} reference is the right one, however.<RESET>}<RED>,<RESET>
> +  year=<RED>{1987},<RESET><GREEN>1987,<RESET>
> +  note={This is in fact a rather funny read since ethernet works well in practice. The {\em pre} reference is the right one, however.}
>  }<RESET>
> not ok - 22 diff driver 'bibtex'

Thanks for a report.  Off the top of my head, there may be three
possibilities.

 (1) The compiled binary of Git is broken on your platform and not
     formatting the escape sequence correctly.  I somehow think it
     is very unlikely, as the code to do so is pretty much platform
     agonistic (color.c does not use anything fancy from system
     libraries).

 (2) The test script, the part that converts the escape sequence to
     human readable form, is broken---not written in a portable awk.

 (3) The implementation of awk on your platform was broken by your
     supplier, with the same infinite wisdom they broke the UTF-8
     pathnames on their filesystem implementation with ;-)

Can you help isolating the issue first to see if it is (1) or one of
the other two?

Run "cd t && sh t4034-diff-words -i" to force stop the test upon the
first breakage, and inspect the "output" before the awk script
test_decode_color munges it.  Does it show a red number 2 and green
number 4 on the line that begins with "number=" (or if you have an
access to a box on which this test passes, grab the raw output from
it by running this test, and make byte-for-byte comparison)?  
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]