summaryrefslogtreecommitdiff
path: root/t/test-lib.sh
AgeCommit message (Collapse)AuthorFilesLines
2018-03-14Merge branch 'sg/test-x'Libravatar Junio C Hamano1-1/+18
Running test scripts under -x option of the shell is often not a useful way to debug them, because the error messages from the commands tests try to capture and inspect are contaminated by the tracing output by the shell. An earlier work done to make it more pleasant to run tests under -x with recent versions of bash is extended to cover posix shells that do not support BASH_XTRACEFD. * sg/test-x: travis-ci: run tests with '-x' tracing t/README: add a note about don't saving stderr of compound commands t1510-repo-setup: mark as untraceable with '-x' t9903-bash-prompt: don't check the stderr of __git_ps1() t5570-git-daemon: don't check the stderr of a subshell t5526: use $TRASH_DIRECTORY to specify the path of GIT_TRACE log file t5500-fetch-pack: don't check the stderr of a subshell t3030-merge-recursive: don't check the stderr of a subshell t1507-rev-parse-upstream: don't check the stderr of a shell function t: add means to disable '-x' tracing for individual test scripts t: prevent '-x' tracing from interfering with test helpers' stderr
2018-02-28Merge branch 'gs/test-unset-xdg-cache-home'Libravatar Junio C Hamano1-0/+1
Test update. * gs/test-unset-xdg-cache-home: test-lib.sh: unset XDG_CACHE_HOME
2018-02-27t: add means to disable '-x' tracing for individual test scriptsLibravatar SZEDER Gábor1-1/+18
The previous patch resolved most of the test failures caused by running our test suite with '-x' tracing and /bin/sh, and the following patches in this series will resolve almost all of the remaining failures. Unfortunately, not yet all. Add means to disable '-x' tracing for individual test scripts by setting the $test_untraceable variable to a non-empty value in the test script before sourcing 'test-lib.sh'. However, since '-x' tracing is not an issue with recent Bash versions supporting BASH_XTRACEFD, i.e. v4.1 and later, don't disable tracing when the test script is run with such a Bash version even when $test_untraceable is set. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-02-21Merge branch 'sg/test-i18ngrep'Libravatar Junio C Hamano1-26/+0
Test fixes. * sg/test-i18ngrep: t: make 'test_i18ngrep' more informative on failure t: validate 'test_i18ngrep's parameters t: move 'test_i18ncmp' and 'test_i18ngrep' to 'test-lib-functions.sh' t5536: let 'test_i18ngrep' read the file without redirection t5510: consolidate 'grep' and 'test_i18ngrep' patterns t4001: don't run 'git status' upstream of a pipe t6022: don't run 'git merge' upstream of a pipe t5812: add 'test_i18ngrep's missing filename parameter t5541: add 'test_i18ngrep's missing filename parameter
2018-02-16test-lib.sh: unset XDG_CACHE_HOMELibravatar Genki Sky1-0/+1
git respects XDG_CACHE_HOME for the credential cache. So, we should unset XDG_CACHE_HOME for the test environment, lest a user's custom one cause failure in the test. For example, t/t0301-credential-cache.sh expects a default directory to be used if it hasn't explicitly set XDG_CACHE_HOME. Signed-off-by: Genki Sky <sky@genki.is> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-02-15Merge branch 'ab/wildmatch-tests'Libravatar Junio C Hamano1-0/+4
More tests for wildmatch functions. * ab/wildmatch-tests: wildmatch test: mark test as EXPENSIVE_ON_WINDOWS test-lib: add an EXPENSIVE_ON_WINDOWS prerequisite wildmatch test: create & test files on disk in addition to in-memory wildmatch test: perform all tests under all wildmatch() modes wildmatch test: use test_must_fail, not ! for test-wildmatch wildmatch test: remove dead fnmatch() test code wildmatch test: use a paranoia pattern from nul_match() wildmatch test: don't try to vertically align our output wildmatch test: use more standard shell style wildmatch test: indent with tabs, not spaces
2018-02-13Merge branch 'ab/simplify-perl-makefile'Libravatar Junio C Hamano1-1/+1
The build procedure for perl/ part has been greatly simplified by weaning ourselves off of MakeMaker. * ab/simplify-perl-makefile: perl: treat PERLLIB_EXTRA as an extra path again perl: avoid *.pmc and fix Error.pm further Makefile: replace perl/Makefile.PL with simple make rules
2018-02-08t: move 'test_i18ncmp' and 'test_i18ngrep' to 'test-lib-functions.sh'Libravatar SZEDER Gábor1-26/+0
Both 'test_i18ncmp' and 'test_i18ngrep' helper functions are supposed to be called from our test scripts, so they should be in 'test-lib-functions.sh'. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-30test-lib: add an EXPENSIVE_ON_WINDOWS prerequisiteLibravatar Ævar Arnfjörð Bjarmason1-0/+4
Add an EXPENSIVE_ON_WINDOWS prerequisite to mark those tests which are very expensive to run on Windows, but cheap elsewhere. Certain tests that heavily stress the filesystem or run a lot of shell commands are disproportionately expensive on Windows, this prerequisite will later be used by a tests that runs in 4-8 seconds on a modern Linux system, but takes almost 10 minutes on Windows. There's no reason to skip such tests by default on other platforms, but Windows users shouldn't need to wait around while they finish. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-05Merge branch 'jk/test-suite-tracing'Libravatar Junio C Hamano1-13/+33
Assorted fixes around running tests with "-x" tracing option. * jk/test-suite-tracing: t/Makefile: introduce TEST_SHELL_PATH test-lib: make "-x" work with "--verbose-log" t5615: avoid re-using descriptor 4 test-lib: silence "-x" cleanup under bash
2017-12-11Makefile: replace perl/Makefile.PL with simple make rulesLibravatar Ævar Arnfjörð Bjarmason1-1/+1
Replace the perl/Makefile.PL and the fallback perl/Makefile used under NO_PERL_MAKEMAKER=NoThanks with a much simpler implementation heavily inspired by how the i18n infrastructure's build process works[1]. The reason for having the Makefile.PL in the first place is that it was initially[2] building a perl C binding to interface with libgit, this functionality, that was removed[3] before Git.pm ever made it to the master branch. We've since since started maintaining a fallback perl/Makefile, as MakeMaker wouldn't work on some platforms[4]. That's just the tip of the iceberg. We have the PM.stamp hack in the top-level Makefile[5] to detect whether we need to regenerate the perl/perl.mak, which I fixed just recently to deal with issues like the perl version changing from under us[6]. There is absolutely no reason for why this needs to be so complex anymore. All we're getting out of this elaborate Rube Goldberg machine was copying perl/* to perl/blib/* as we do a string-replacement on the *.pm files to hardcode @@LOCALEDIR@@ in the source, as well as pod2man-ing Git.pm & friends. So replace the whole thing with something that's pretty much a copy of how we generate po/build/**.mo from po/*.po, just with a small sed(1) command instead of msgfmt. As that's being done rename the files from *.pm to *.pmc just to indicate that they're generated (see "perldoc -f require"). While I'm at it, change the fallback for Error.pm from being something where we'll ship our own Error.pm if one doesn't exist at build time to one where we just use a Git::Error wrapper that'll always prefer the system-wide Error.pm, only falling back to our own copy if it really doesn't exist at runtime. It's now shipped as Git::FromCPAN::Error, making it easy to add other modules to Git::FromCPAN::* in the future if that's needed. Functional changes: * This will not always install into perl's idea of its global "installsitelib". This only potentially matters for packagers that need to expose Git.pm for non-git use, and as explained in the INSTALL file there's a trivial workaround. * The scripts themselves will 'use lib' the target directory, but if INSTLIBDIR is set it overrides it. It doesn't have to be this way, it could be set in addition to INSTLIBDIR, but my reading of [7] is that this is the desired behavior. * We don't build man pages for all of the perl modules as we used to, only Git(3pm). As discussed on-list[8] that we were building installed manpages for purely internal APIs like Git::I18N or private-Error.pm was always a bug anyway, and all the Git::SVN::* ones say they're internal APIs. There are apparently external users of Git.pm, but I don't expect there to be any of the others. As a side-effect of these general changes the perl documentation now only installed by install-{doc,man}, not a mere "install" as before. 1. 5e9637c629 ("i18n: add infrastructure for translating Git with gettext", 2011-11-18) 2. b1edc53d06 ("Introduce Git.pm (v4)", 2006-06-24) 3. 18b0fc1ce1 ("Git.pm: Kill Git.xs for now", 2006-09-23) 4. f848718a69 ("Make perl/ build procedure ActiveState friendly.", 2006-12-04) 5. ee9be06770 ("perl: detect new files in MakeMaker builds", 2012-07-27) 6. c59c4939c2 ("perl: regenerate perl.mak if perl -V changes", 2017-03-29) 7. 0386dd37b1 ("Makefile: add PERLLIB_EXTRA variable that adds to default perl path", 2013-11-15) 8. 87bmjjv1pu.fsf@evledraar.booking.com ("Re: [PATCH] Makefile: replace perl/Makefile.PL with simple make rules" Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-08t/Makefile: introduce TEST_SHELL_PATHLibravatar Jeff King1-1/+1
You may want to run the test suite with a different shell than you use to build Git. For instance, you may build with SHELL_PATH=/bin/sh (because it's faster, or it's what you expect to exist on systems where the build will be used) but want to run the test suite with bash (e.g., since that allows using "-x" reliably across the whole test suite). There's currently no good way to do this. You might think that doing two separate make invocations, like: make && make -C t SHELL_PATH=/bin/bash would work. And it _almost_ does. The second make will see our bash SHELL_PATH, and we'll use that to run the individual test scripts (or tell prove to use it to do so). So far so good. But this breaks down when "--tee" or "--verbose-log" is used. Those options cause the test script to actually re-exec itself using $SHELL_PATH. But wait, wouldn't our second make invocation have set SHELL_PATH correctly in the environment? Yes, but test-lib.sh sources GIT-BUILD-OPTIONS, which we built during the first "make". And that overrides the environment, giving us the original SHELL_PATH again. Let's introduce a new variable that lets you specify a specific shell to be run for the test scripts. Note that we have to touch both the main and t/ Makefiles, since we have to record it in GIT-BUILD-OPTIONS in one, and use it in the latter. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-08test-lib: make "-x" work with "--verbose-log"Libravatar Jeff King1-2/+8
The "-x" tracing option implies "--verbose". This is a problem when running under a TAP harness like "prove", where we need to use "--verbose-log" instead. Instead, let's handle this the same way we do for --valgrind, including the recent fix from 88c6e9d31c (test-lib: --valgrind should not override --verbose-log, 2017-09-05). Namely, let's enable --verbose only when we know there isn't a more specific verbosity option indicated. Note that we also have to tweak `want_trace` to turn it on (previously we just lumped $verbose_log in with $verbose, but now we don't necessarily auto-set the latter). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-08test-lib: silence "-x" cleanup under bashLibravatar Jeff King1-10/+24
When the test suite's "-x" option is used with bash, we end up seeing cleanup cruft in the output: $ bash t0001-init.sh -x [...] ++ diff -u expected actual + test_eval_ret_=0 + want_trace + test t = t + test t = t + set +x ok 42 - re-init from a linked worktree This ranges from mildly annoying (for a successful test) to downright confusing (when we say "last command exited with error", but it's really 5 commands back). We normally are able to suppress this cleanup. As the in-code comment explains, we can't convince the shell not to print it, but we can redirect its stderr elsewhere. But since d88785e424 (test-lib: set BASH_XTRACEFD automatically, 2016-05-11), that doesn't hold for bash. It sends the "set -x" output directly to descriptor 4, not to stderr. We can fix this by also redirecting descriptor 4, and paying close attention to which commands redirected and which are not (see the updated comment). Two alternatives I considered and rejected: - unsetting and setting BASH_XTRACEFD; doing so closes the descriptor, which we must avoid - we could keep everything in a single block as before, redirect 4>/dev/null there, but retain 5>&4 as a copy. And then selectively restore 4>&5 for commands which should be allowed to trace. This would work, but the descriptor swapping seems unnecessarily confusing. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-24test-lib: add LIBPCRE1 & LIBPCRE2 prerequisitesLibravatar Ævar Arnfjörð Bjarmason1-0/+2
Add LIBPCRE1 and LIBPCRE2 prerequisites which are true when git is compiled with USE_LIBPCRE1=YesPlease or USE_LIBPCRE2=YesPlease, respectively. The syntax of PCRE1 and PCRE2 isn't the same in all cases (see pcresyntax(3) and pcre2syntax(3)). If test are added that test for those they'll need to be guarded by these new prerequisites. The subsequent patch will make use of LIBPCRE2, so LIBPCRE1 isn't strictly needed for now, but let's add it for consistency and so that checking for it doesn't have to be done with the less obvious "PCRE, !LIBPCRE2", which while semantically the same is more confusing, and would lead to bugs if PCRE v3 is ever released as the tests would mean v1, not any non-v2 version. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-21Merge branch 'cb/t4201-robustify' into maintLibravatar Junio C Hamano1-3/+4
A test update. * cb/t4201-robustify: t4201: make use of abbreviation in the test more robust
2017-11-15Merge branch 'cb/t4201-robustify'Libravatar Junio C Hamano1-3/+4
A test update. * cb/t4201-robustify: t4201: make use of abbreviation in the test more robust
2017-11-13t4201: make use of abbreviation in the test more robustLibravatar Charles Bailey1-3/+4
The test for '--abbrev' in t4201-shortlog.sh assumes that the commits generated in the test can always be uniquely abbreviated to 5 hex digits but this is not always the case. If you were unlucky and happened to run the test at (say) Thu Jun 22 03:04:49 2017 +0000, you would find that the first commit generated would collide with a tree object created later in the same test. This can be simulated in the version of t4201-shortlog.sh prior to this commit by setting GIT_COMMITTER_DATE and GIT_AUTHOR_DATE to 1498100689 after sourcing test-lib.sh. Change the test to test --abbrev=35 instead of --abbrev=5 to almost completely avoid the possibility of a partial collision and add a call to test_tick in the setup to make the test repeatable (the latter alone is sufficient to make it robust enough). Signed-off-by: Charles Bailey <cbailey32@bloomberg.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-25Merge branch 'rj/test-ulimit-on-windows'Libravatar Junio C Hamano1-10/+10
On Cygwin, "ulimit -s" does not report failure but it does not work at all, which causes an unexpected success of some tests that expect failures under a limited stack situation. This has been fixed. * rj/test-ulimit-on-windows: t9010-*.sh: skip all tests if the PIPE prereq is missing test-lib: use more compact expression in PIPE prerequisite test-lib: don't use ulimit in test prerequisites on cygwin
2017-09-25Merge branch 'mg/name-rev-tests-with-short-stack'Libravatar Junio C Hamano1-0/+6
A handful of tests to demonstrates a recursive implementation of "name-rev" hurts. * mg/name-rev-tests-with-short-stack: t6120: test describe and name-rev with deep repos t6120: clean up state after breaking repo t6120: test name-rev --all and --stdin t7004: move limited stack prereq to test-lib
2017-09-19test-lib: use more compact expression in PIPE prerequisiteLibravatar Ramsay Jones1-8/+2
Signed-off-by: Ramsay Jones <ramsay@ramsayjones.plus.com> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-15test-lib: don't use ulimit in test prerequisites on cygwinLibravatar Ramsay Jones1-2/+8
On cygwin (and MinGW), the 'ulimit' built-in bash command does not have the desired effect of limiting the resources of new processes, at least for the stack and file descriptors. However, it always returns success and leads to several test prerequisites being erroneously set to true. Add a check for cygwin and MinGW to the prerequisite expressions, using a 'test_have_prereq !MINGW,!CYGWIN' clause, to guard against using ulimit. This affects the prerequisite expressions for the ULIMIT_STACK_SIZE, CMDLINE_LIMIT and ULIMIT_FILE_DESCRIPTORS prerequisites. Signed-off-by: Ramsay Jones <ramsay@ramsayjones.plus.com> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-08t7004: move limited stack prereq to test-libLibravatar Michael J Gruber1-0/+6
The lazy prerequisite ULIMIT_STACK_SIZE is used only in t7004 so far. Move it to test-lib.sh so that it can be used in other tests (which it will be in a follow-up commit). Signed-off-by: Michael J Gruber <git@grubix.eu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-06test-lib: set LSAN_OPTIONS to abort by defaultLibravatar Jeff King1-0/+5
We already set ASAN_OPTIONS to abort if it finds any errors. As we start to experiment with LSAN, the leak sanitizer, it's convenient if we give it the same treatment. Note that ASAN is actually a superset of LSAN and can do the leak detection itself. So this only has an effect if you specifically build with "make SANITIZE=leak" (leak detection but not the rest of ASAN). Building with just LSAN results in a build that runs much faster. That makes the build-test-fix cycle more pleasant. In the long run, once we've fixed or suppressed all the leaks, it will probably be worth turning leak-detection on for ASAN and just using that (to check both leaks _and_ memory errors in a single test run). But there's still a lot of work before we get there. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-06test-lib: --valgrind should not override --verbose-logLibravatar Jeff King1-1/+1
The --verbose test option cannot be used with test harnesses like "prove". Instead, you must use --verbose-log. Since the --valgrind option implies --verbose, that means that it cannot be used with prove. I.e., this does not work: prove t0000-basic.sh :: --valgrind You'd think it could be fixed by doing: prove t0000-basic.sh :: --valgrind --verbose-log but that doesn't work either, because the implied --verbose takes precedence over --verbose-log. If the user has given us a specific option, we should prefer that. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-08-23Merge branch 'rs/t1002-do-not-use-sum'Libravatar Junio C Hamano1-3/+0
Test simplification. * rs/t1002-do-not-use-sum: t1002: stop using sum(1)
2017-08-22Merge branch 'jk/drop-sha1-entry-pos'Libravatar Junio C Hamano1-1/+0
Code clean-up. * jk/drop-sha1-entry-pos: sha1_file: drop experimental GIT_USE_LOOKUP search
2017-08-15t1002: stop using sum(1)Libravatar René Scharfe1-3/+0
sum(1) is a command for calculating checksums of the contents of files. It was part of early editions of Unix ("Research Unix", 1972/1973, [1]). cksum(1) appeared in 4.4BSD (1993) as a replacement [2], and became part of POSIX.1-2008 [3]. OpenBSD 5.6 (2014) removed sum(1). We only use sum(1) in t1002 to check for changes in three files. On MinGW we use md5sum(1) instead. We could switch to the standard command cksum(1) for all platforms; MinGW comes with GNU coreutils now, which provides sum(1), cksum(1) and md5sum(1). Use our standard method for checking for file changes instead: test_cmp. It's more convenient because it shows differences nicely, it's faster on MinGW because we have a special implementation there based only on shell-internal commands, it's simpler as it allows us to avoid stripping out unnecessary entries from the checksum file using grep(1), and it's more consistent with the rest of the test suite. We already compare changed files with their expected new contents using diff(1), so we don't need to check with "test_must_fail test_cmp" if they differ from their original state. A later patch could convert the direct diff(1) calls to test_cmp as well. With all sum(1) calls gone, remove the MinGW-specific implementation from test-lib.sh as well. [1] http://minnie.tuhs.org/cgi-bin/utree.pl?file=V3/man/man1/sum.1 [2] http://minnie.tuhs.org/cgi-bin/utree.pl?file=4.4BSD/usr/share/man/cat1/cksum.0 [3] http://pubs.opengroup.org/onlinepubs/9699919799/utilities/cksum.html Signed-off-by: René Scharfe <l.s.r@web.de> Reviewed-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-08-09sha1_file: drop experimental GIT_USE_LOOKUP searchLibravatar Jeff King1-1/+0
Long ago in 628522ec14 (sha1-lookup: more memory efficient search in sorted list of SHA-1, 2007-12-29) we added sha1_entry_pos(), a binary search that uses the uniform distribution of sha1s to scale the selection of mid-points. As this was a performance experiment, we tied it to the GIT_USE_LOOKUP environment variable and never enabled it by default. This code was successful in reducing the number of steps in each search. But the overhead of the scaling ends up making it slower when the cache is warm. Here are best-of-five timings for running rev-list on linux.git, which will have to look up every object: $ time git rev-list --objects --all >/dev/null real 0m35.357s user 0m35.016s sys 0m0.340s $ time GIT_USE_LOOKUP=1 git rev-list --objects --all >/dev/null real 0m37.364s user 0m37.045s sys 0m0.316s The USE_LOOKUP version might have more benefit on a cold cache, as the time to fault in each page would dominate. But that would be for a single lookup. In practice, most operations tend to look up many objects, and the whole pack .idx will end up warm. It's possible that the code could be better optimized to compete with a naive binary search for the warm-cache case, and we could have the best of both worlds. But over the years nobody has done so, and this is largely dead code that is rarely run outside of the test suite. Let's drop it in the name of simplicity. This lets us remove sha1_entry_pos() entirely, as the .idx lookup code was the only caller. Note that sha1-lookup.c still contains sha1_pos(), which differs from sha1_entry_pos() in two ways: - it has a different interface; it uses a function pointer to access sha1 entries rather than a size/offset pair describing the table's memory layout - it only scales the initial selection of "mi", rather than each iteration of the search We can't get rid of this function, as it's called from several places. It may be that we could replace it with a simple binary search, but that's out of scope for this patch (and would need benchmarking). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-13Merge branch 'jk/build-with-asan'Libravatar Junio C Hamano1-3/+8
The build procedure has been improved to allow building and testing Git with address sanitizer more easily. * jk/build-with-asan: Makefile: disable unaligned loads with UBSan Makefile: turn off -fomit-frame-pointer with sanitizers Makefile: add helper for compiling with -fsanitize test-lib: turn on ASan abort_on_error by default test-lib: set ASAN_OPTIONS variable before we run git
2017-07-10test-lib: turn on ASan abort_on_error by defaultLibravatar Jeff King1-1/+1
By default, ASan will exit with code 1 when it sees an error. This means we'll notice a problem when we expected git to succeed, but not in a test_must_fail block. Let's ask it to actually raise SIGABRT instead. That will give us a signal death that test_must_fail will notice. As a bonus, it may also leave a coredump, which can be handy for digging into a failure. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-10test-lib: set ASAN_OPTIONS variable before we run gitLibravatar Jeff King1-3/+8
We turn off ASan's leak detection by default in the test suite because it's too noisy. But we don't do so until part-way through test-lib. This is before we've run any tests, but after we do our initial "./git" to see if the binary has even been built. When built with clang, this seems to work fine. However, using "gcc -fsanitize=address", the leak checker seems to complain more aggressively: $ ./git ... ==5352==ERROR: LeakSanitizer: detected memory leaks Direct leak of 2 byte(s) in 1 object(s) allocated from: #0 0x7f120e7afcf8 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.3+0xc1cf8) #1 0x559fc2a3ce41 in do_xmalloc /home/peff/compile/git/wrapper.c:60 #2 0x559fc2a3cf1a in do_xmallocz /home/peff/compile/git/wrapper.c:100 #3 0x559fc2a3d0ad in xmallocz /home/peff/compile/git/wrapper.c:108 #4 0x559fc2a3d0ad in xmemdupz /home/peff/compile/git/wrapper.c:124 #5 0x559fc2a3d0ad in xstrndup /home/peff/compile/git/wrapper.c:130 #6 0x559fc274535a in main /home/peff/compile/git/common-main.c:39 #7 0x7f120dabd2b0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202b0) This is a leak in the sense that we never free it, but it's in a global that is meant to last the whole program. So it's not really interesting or in need of fixing. And at any rate, mentioning leaks outside of the test_expect blocks is certainly unwelcome, as it pollutes stderr. Let's bump the setting of ASAN_OPTIONS higher in test-lib.sh to catch our initial "can we even run git?" test. While we're at it, we can add a comment to make it a bit less inscrutable. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-19Merge branch 'ab/pcre-v2'Libravatar Junio C Hamano1-1/+1
Update "perl-compatible regular expression" support to enable JIT and also allow linking with the newer PCRE v2 library. * ab/pcre-v2: grep: add support for PCRE v2 grep: un-break building with PCRE >= 8.32 without --enable-jit grep: un-break building with PCRE < 8.20 grep: un-break building with PCRE < 8.32 grep: add support for the PCRE v1 JIT API log: add -P as a synonym for --perl-regexp grep: skip pthreads overhead when using one thread grep: don't redundantly compile throwaway patterns under threading
2017-06-02Merge branch 'ab/grep-preparatory-cleanup'Libravatar Junio C Hamano1-1/+2
The internal implementation of "git grep" has seen some clean-up. * ab/grep-preparatory-cleanup: (31 commits) grep: assert that threading is enabled when calling grep_{lock,unlock} grep: given --threads with NO_PTHREADS=YesPlease, warn pack-objects: fix buggy warning about threads pack-objects & index-pack: add test for --threads warning test-lib: add a PTHREADS prerequisite grep: move is_fixed() earlier to avoid forward declaration grep: change internal *pcre* variable & function names to be *pcre1* grep: change the internal PCRE macro names to be PCRE1 grep: factor test for \0 in grep patterns into a function grep: remove redundant regflags assignments grep: catch a missing enum in switch statement perf: add a comparison test of log --grep regex engines with -F perf: add a comparison test of log --grep regex engines perf: add a comparison test of grep regex engines with -F perf: add a comparison test of grep regex engines perf: emit progress output when unpacking & building perf: add a GIT_PERF_MAKE_COMMAND for when *_MAKE_OPTS won't do grep: add tests to fix blind spots with \0 patterns grep: prepare for testing binary regexes containing rx metacharacters grep: add a test helper function for less verbose -f \0 tests ...
2017-06-02grep: add support for PCRE v2Libravatar Ævar Arnfjörð Bjarmason1-1/+1
Add support for v2 of the PCRE API. This is a new major version of PCRE that came out in early 2015[1]. The regular expression syntax is the same, but while the API is similar, pretty much every function is either renamed or takes different arguments. Thus using it via entirely new functions makes sense, as opposed to trying to e.g. have one compile_pcre_pattern() that would call either PCRE v1 or v2 functions. Git can now be compiled with either USE_LIBPCRE1=YesPlease or USE_LIBPCRE2=YesPlease, with USE_LIBPCRE=YesPlease currently being a synonym for the former. Providing both is a compile-time error. With earlier patches to enable JIT for PCRE v1 the performance of the release versions of both libraries is almost exactly the same, with PCRE v2 being around 1% slower. However after I reported this to the pcre-dev mailing list[2] I got a lot of help with the API use from Zoltán Herczeg, he subsequently optimized some of the JIT functionality in v2 of the library. Running the p7820-grep-engines.sh performance test against the latest Subversion trunk of both, with both them and git compiled as -O3, and the test run against linux.git, gives the following results. Just the /perl/ tests shown: $ GIT_PERF_REPEAT_COUNT=30 GIT_PERF_LARGE_REPO=~/g/linux GIT_PERF_MAKE_COMMAND='grep -q LIBPCRE2 Makefile && make -j8 USE_LIBPCRE2=YesPlease CC=~/perl5/installed/bin/gcc NO_R_TO_GCC_LINKER=YesPlease CFLAGS=-O3 LIBPCREDIR=/home/avar/g/pcre2/inst LDFLAGS=-Wl,-rpath,/home/avar/g/pcre2/inst/lib || make -j8 USE_LIBPCRE=YesPlease CC=~/perl5/installed/bin/gcc NO_R_TO_GCC_LINKER=YesPlease CFLAGS=-O3 LIBPCREDIR=/home/avar/g/pcre/inst LDFLAGS=-Wl,-rpath,/home/avar/g/pcre/inst/lib' ./run HEAD~5 HEAD~ HEAD p7820-grep-engines.sh [...] Test HEAD~5 HEAD~ HEAD ----------------------------------------------------------------------------------------------------------------- 7820.3: perl grep 'how.to' 0.31(1.10+0.48) 0.21(0.35+0.56) -32.3% 0.21(0.34+0.55) -32.3% 7820.7: perl grep '^how to' 0.56(2.70+0.40) 0.24(0.64+0.52) -57.1% 0.20(0.28+0.60) -64.3% 7820.11: perl grep '[how] to' 0.56(2.66+0.38) 0.29(0.95+0.45) -48.2% 0.23(0.45+0.54) -58.9% 7820.15: perl grep '(e.t[^ ]*|v.ry) rare' 1.02(5.77+0.42) 0.31(1.02+0.54) -69.6% 0.23(0.50+0.54) -77.5% 7820.19: perl grep 'm(ú|u)lt.b(æ|y)te' 0.38(1.57+0.42) 0.27(0.85+0.46) -28.9% 0.21(0.33+0.57) -44.7% See commit ("perf: add a comparison test of grep regex engines", 2017-04-19) for details on the machine the above test run was executed on. Here HEAD~2 is git with PCRE v1 without JIT, HEAD~ is PCRE v1 with JIT, and HEAD is PCRE v2 (also with JIT). See previous commits of mine mentioning p7820-grep-engines.sh for more details on the test setup. For ease of readability, a different run just of HEAD~ (PCRE v1 with JIT v.s. PCRE v2), again with just the /perl/ tests shown: [...] Test HEAD~ HEAD ---------------------------------------------------------------------------------------- 7820.3: perl grep 'how.to' 0.21(0.42+0.52) 0.21(0.31+0.58) +0.0% 7820.7: perl grep '^how to' 0.25(0.65+0.50) 0.20(0.31+0.57) -20.0% 7820.11: perl grep '[how] to' 0.30(0.90+0.50) 0.23(0.46+0.53) -23.3% 7820.15: perl grep '(e.t[^ ]*|v.ry) rare' 0.30(1.19+0.38) 0.23(0.51+0.51) -23.3% 7820.19: perl grep 'm(ú|u)lt.b(æ|y)te' 0.27(0.84+0.48) 0.21(0.34+0.57) -22.2% I.e. the two are either neck-to-neck, but PCRE v2 usually pulls ahead, when it does it's around 20% faster. A brief note on thread safety: As noted in pcre2api(3) & pcre2jit(3) the compiled pattern can be shared between threads, but not some of the JIT context, however the grep threading support does all pattern & JIT compilation in separate threads, so this code doesn't need to concern itself with thread safety. See commit 63e7e9d8b6 ("git-grep: Learn PCRE", 2011-05-09) for the initial addition of PCRE v1. This change follows some of the same patterns it did (and which were discussed on list at the time), e.g. mocking up types with typedef instead of ifdef-ing them out when USE_LIBPCRE2 isn't defined. This adds some trivial memory use to the program, but makes the code look nicer. 1. https://lists.exim.org/lurker/message/20150105.162835.0666407a.en.html 2. https://lists.exim.org/lurker/thread/20170419.172322.833ee099.en.html Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-30Merge branch 'jc/skip-test-in-the-middle'Libravatar Junio C Hamano1-8/+13
A recent update to t5545-push-options.sh started skipping all the tests in the script when a web server testing is disabled or unavailable, not just the ones that require a web server. Non HTTP tests have been salvaged to always run in this script. * jc/skip-test-in-the-middle: t5545: enhance test coverage when no http server is installed test: allow skipping the remainder
2017-05-26test-lib: add a PTHREADS prerequisiteLibravatar Ævar Arnfjörð Bjarmason1-0/+1
Add a PTHREADS prerequisite which is false when git is compiled with NO_PTHREADS=YesPlease. There's lots of custom code that runs when threading isn't available, but before this prerequisite there was no way to test it. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-26grep: change the internal PCRE macro names to be PCRE1Libravatar Ævar Arnfjörð Bjarmason1-1/+1
Change the internal USE_LIBPCRE define, & build options flag to use a naming convention ending in PCRE1, without changing the long-standing USE_LIBPCRE Makefile flag which enables this code. This is for preparation for libpcre2 support where having things like USE_LIBPCRE and USE_LIBPCRE2 in any more places than we absolutely need to for backwards compatibility with old Makefile arguments would be confusing. In some ways it would be better to change everything that now uses USE_LIBPCRE to use USE_LIBPCRE1, and to make specifying USE_LIBPCRE (or --with-pcre) an error. This would impose a one-time burden on packagers of git to s/USE_LIBPCRE/USE_LIBPCRE1/ in their build scripts. However I'd like to leave the door open to making USE_LIBPCRE=YesPlease eventually mean USE_LIBPCRE2=YesPlease, i.e. once PCRE v2 is ubiquitous enough that it makes sense to make it the default. This code and the USE_LIBPCRE Makefile argument was added in commit 63e7e9d8b6 ("git-grep: Learn PCRE", 2011-05-09). At the time there was no indication that the PCRE project would release an entirely new & incompatible API around 3 years later. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-21test-lib: rename the LIBPCRE prerequisite to PCRELibravatar Ævar Arnfjörð Bjarmason1-1/+1
Rename the LIBPCRE prerequisite to PCRE. This is for preparation for libpcre2 support, where having just "LIBPCRE" would be confusing as it implies v1 of the library. None of these tests are incompatible between versions 1 & 2 of libpcre, it's less confusing to give them a more general name to make it clear that they work on both library versions. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-18test: allow skipping the remainderLibravatar Junio C Hamano1-8/+13
Because TAP output does not like to see the remainder of the test getting skipped after running one or more tests, bf4b7219 ("test-lib.sh: Add check for invalid use of 'skip_all' facility", 2012-09-01) made sure that test_done errors out when this happens. Instead, loosen the check so that we only pretend that the rest of the test script did not exist in such a case. We'd lose a bit of information (i.e. TAP does not notice that we are skipping some tests), but not very much (i.e. TAP wasn't told how many tests are skipped anyway). This will allow inclusion of lib-httpd.sh in the middle of a test, which will skip the remainder of the test scripts when tests that involve web server are declined with GIT_TEST_HTTPD=false, for example. Acked-by: Ramsay Jones <ramsay@ramsayjones.plus.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-16Merge branch 'js/larger-timestamps'Libravatar Junio C Hamano1-0/+3
Some platforms have ulong that is smaller than time_t, and our historical use of ulong for timestamp would mean they cannot represent some timestamp that the platform allows. Invent a separate and dedicated timestamp_t (so that we can distingiuish timestamps and a vanilla ulongs, which along is already a good move), and then declare uintmax_t is the type to be used as the timestamp_t. * js/larger-timestamps: archive-tar: fix a sparse 'constant too large' warning use uintmax_t for timestamps date.c: abort if the system time cannot handle one of our timestamps timestamp_t: a new data type for timestamps PRItime: introduce a new "printf format" for timestamps parse_timestamp(): specify explicitly where we parse timestamps t0006 & t5000: skip "far in the future" test when time_t is too limited t0006 & t5000: prepare for 64-bit timestamps ref-filter: avoid using `unsigned long` for catch-all data type
2017-05-16Merge branch 'dt/gc-ignore-old-gc-logs'Libravatar Junio C Hamano1-4/+8
Attempt to allow us notice "fishy" situation where we fail to remove the temporary directory used during the test. * dt/gc-ignore-old-gc-logs: test-lib: retire $remove_trash variable test-lib.sh: do not barf under --debug at the end of the test test-lib: abort when can't remove trash directory
2017-04-24test-lib: retire $remove_trash variableLibravatar Junio C Hamano1-6/+4
The convention "$remove_trash is set to the trash directory that is used during the test, so that it will be removed at the end, but under --debug option we set the varilable to empty string to preserve the directory" made sense back when it was introduced, as there was no $TRASH_DIRECTORY variable. These days, since no tests looks at the variable, it is obscure and even risks that by mistake the variable gets used for something else (e.g. remove_trash=yes) and cause us misbehave. Worse yet, remove_trash was not initialized to an empty string at the beginning, so a stray environment variable the user has could have affected the logic when "--debug" is in use. Rewrite the clean-up sequence in test_done helper to explicitly check the $debug condition and remove the trash directory using the $TRASH_DIRECTORY variable. Note that "go to the directory one level above the trash and then remove it" is kept and this is deliverate; test_at_end_hook_ will keep running from the expected location, and also some platforms may not like a directory that is serving as the $cwd of a still-active process removed. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-04-24test-lib.sh: do not barf under --debug at the end of the testLibravatar Junio C Hamano1-5/+8
The original did "does $remove_trash exist? Then go one level above and remove it". There was no problem under "--debug", where the variable is left empty, as the first "test -d $remove_trash" would have said "No, it doesn't". With the check implemented in the previous step, we'd always get an error under "--debug". Noticed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-04-23test-lib: abort when can't remove trash directoryLibravatar SZEDER Gábor1-2/+5
We had two similar bugs in the tests sporadically triggering error messages during the removal of the trash directory, see commits bb05510e5 (t5510: run auto-gc in the foreground, 2016-05-01) and ef09036cf (t6500: wait for detached auto gc at the end of the test script, 2017-04-13). The test script succeeded nonetheless, because these errors are ignored during housekeeping in 'test_done'. However, such an error is a sign that something is fishy in the test script. Print an error message and abort the test script when the trash directory can't be removed successfully or is already removed, because that's unexpected and we would prefer somebody notice and figure out why. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-04-20t0006 & t5000: skip "far in the future" test when time_t is too limitedLibravatar Johannes Schindelin1-0/+1
Git's source code refers to timestamps as unsigned long, which is ill-defined, as there is no guarantee about the number of bits that data type has. In preparation of switching to another data type that is large enough to hold "far in the future" dates, we need to prepare the t0006-date.sh script for the case where we *still* cannot format those dates if the system library uses 32-bit time_t. Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-04-20t0006 & t5000: prepare for 64-bit timestampsLibravatar Johannes Schindelin1-0/+2
Git's source code refers to timestamps as unsigned longs. On 32-bit platforms, as well as on Windows, unsigned long is not large enough to capture dates that are "absurdly far in the future". It is perfectly valid by the C standard, of course, for the `long` data type to refer to 32-bit integers. That is why the `time_t` data type exists: so that it can be 64-bit even if `long` is 32-bit. Git's source code simply uses an incorrect data type for timestamps, is all. The earlier quick fix 6b9c38e14cd (t0006: skip "far in the future" test when unsigned long is not long enough, 2016-07-11) papered over this issue simply by skipping the respective test cases on platforms where they would fail due to the data type in use. This quick fix, however, tests for *long* to be 64-bit or not. What we need, though, is a test that says whether *whatever data type we use for timestamps* is 64-bit or not. The same quick fix was used to handle the similar problem where Git's source code uses `unsigned long` to represent size, instead of `size_t`, conflating the two issues. So let's just add another prerequisite to test specifically whether timestamps are represented by a 64-bit data type or not. Later, after we switch to a larger data type, we can flip that prerequisite to test `time_t` instead of `long`. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-27Merge branch 'jc/lint-runaway-here-doc'Libravatar Junio C Hamano1-3/+3
The test framework learned to detect unterminated here documents. * jc/lint-runaway-here-doc: tests: lint for run-away here-doc
2017-03-23tests: lint for run-away here-docLibravatar Junio C Hamano1-3/+3
We found a few run-away here documents that are started with an end-of-here-doc marker that is incorrectly spelled, e.g. git some command >actual && cat <<EOF >expect ... EOF && test_cmp expect actual which ends up slurping the entire remainder of the script as if it were the data. Often the command that gets misused like this exits without failure (e.g. "cat" in the above example), which makes the command appear to work, without ever executing the remainder of the test. Piggy-back on the test that catches &&-chain breakage to detect this case as well. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-18tests: create an interactive gdb session with the 'debug' helperLibravatar SZEDER Gábor1-0/+1
The 'debug' test helper is supposed to facilitate debugging by running a command of the test suite under gdb. Unfortunately, its usefulness is severely limited, because that gdb session is not interactive, since the test's, and thus gdb's standard input is redirected from /dev/null (for a good reason, see 781f76b15 (test-lib: redirect stdin of tests, 2011-12-15)). Redirect gdb's standard file descriptors from/to the test environment's stdin, stdout and stderr in the 'debug' helper, thus creating an interactive gdb session (even in non-verbose mode), which is much, much more useful. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>