git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: git@vger.kernel.org
Subject: [PATCH] t: support clang/gcc AddressSanitizer
Date: Mon, 8 Dec 2014 02:47:06 -0500	[thread overview]
Message-ID: <20141208074706.GA19037@peff.net> (raw)

When git is compiled with "-fsanitize=address" (using clang
or gcc >= 4.8), all invocations of git will check for buffer
overflows. This is similar to running with valgrind, except
that it is more thorough (because of the compiler support,
function-local buffers can be checked, too) and runs much
faster (making it much less painful to run the whole test
suite with the checks turned on).

Unlike valgrind, the magic happens at compile-time, so we
don't need the same infrastructure in the test suite that we
did to support --valgrind. But there are two things we can
help with:

  1. On some platforms, the leak-detector is on by default,
     and causes every invocation of "git init" (and thus
     every test script) to fail. Since running git with
     the leak detector is pointless, let's shut it off
     automatically in the tests, unless the user has already
     configured it.

  2. When apache runs a CGI, it clears the environment of
     unknown variables. This means that the $ASAN_OPTIONS
     config doesn't make it to git-http-backend, and it
     dies due to the leak detector. Let's mark the variable
     as OK for apache to pass.

With these two changes, running

    make CC=clang CFLAGS=-fsanitize=address test

works out of the box.

Signed-off-by: Jeff King <peff@peff.net>
---
This is actually how I found the fsck bug I posted a few hours ago, but
I followed up with "./t5032-* --valgrind-only=32" because valgrind seems
to produce better output.

We could get fancier with $ASAN_OPTIONS, like appending "detect_leaks=0"
if it is already set. But I figured that people who are setting
$ASAN_OPTIONS already know what they are doing, and they can deal with
configuring the leak detector themselves.

We could also provide a "make sanitize-test" target, but given how
simple the make command above is, I don't see much point.

 t/lib-httpd/apache.conf | 1 +
 t/test-lib.sh           | 3 +++
 2 files changed, 4 insertions(+)

diff --git a/t/lib-httpd/apache.conf b/t/lib-httpd/apache.conf
index 7713dd2..03a4c2e 100644
--- a/t/lib-httpd/apache.conf
+++ b/t/lib-httpd/apache.conf
@@ -69,6 +69,7 @@ LockFile accept.lock
 PassEnv GIT_VALGRIND
 PassEnv GIT_VALGRIND_OPTIONS
 PassEnv GNUPGHOME
+PassEnv ASAN_OPTIONS
 
 Alias /dumb/ www/
 Alias /auth/dumb/ www/auth/dumb/
diff --git a/t/test-lib.sh b/t/test-lib.sh
index cf19339..3177298 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -140,6 +140,9 @@ else
 	}
 fi
 
+: ${ASAN_OPTIONS=detect_leaks=0}
+export ASAN_OPTIONS
+
 # Protect ourselves from common misconfiguration to export
 # CDPATH into the environment
 unset CDPATH
-- 
2.2.0.390.gf60752d

                 reply	other threads:[~2014-12-08  7:47 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20141208074706.GA19037@peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).