{"thread":{"id":"31533","subject":"[PATCH] Add MALLOC_CHECK_ and MALLOC_PERTURB_ libc env to the test suite for detecting heap corruption","startedAt":"2012-09-14T16:54:22Z","lastAt":"2012-09-27T06:39:17Z","messageCount":8,"participants":["Elia Pinto","Junio C Hamano","René Scharfe"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"199043","messageId":"1347641662-3596-1-git-send-email-gitter.spiros@gmail.com","threadId":"31533","inReplyTo":null,"subject":"[PATCH] Add MALLOC_CHECK_ and MALLOC_PERTURB_ libc env to the test suite for detecting heap corruption","fromName":"Elia Pinto","fromEmail":"gitter.spiros@gmail.com","sentAt":"2012-09-14T16:54:22Z","receivedAt":"2012-09-14T16:54:22Z","isPatch":true,"sender":{"key":"gitter.spiros@gmail.com","avatar":"https://avatars.githubusercontent.com/u/158490?v=4"},"body":"Recent versions of Linux libc (later than 5.4.23) and glibc (2.x)\ninclude a malloc() implementation which is tunable via environment\nvariables. When MALLOC_CHECK_ is set, a special (less efficient)\nimplementation is used which is designed to be tolerant against\nsimple errors, such as double calls of free() with the same argument,\nor overruns of a single byte (off-by-one bugs). When MALLOC_CHECK_\nis set to 3, a diagnostic message is printed on stderr\nand the program is aborted.\n\nSetting the MALLOC_PERTURB_ environment variable causes the malloc\nfunctions in libc to return memory which has been wiped and clear\nmemory when it is returned.\nOf course this does not affect calloc which always does clear the memory.\n\nThe reason for this exercise is, of course, to find code which uses\nmemory returned by malloc without initializing it and code which uses\ncode after it is freed. valgrind can do this but it's costly to run.\nThe MALLOC_PERTURB_ exchanges the ability to detect problems in 100%\nof the cases with speed.\n\nThe byte value used to initialize values returned by malloc is the byte\nvalue of the environment value. The value used to clear memory is the\nbitwise inverse. Setting MALLOC_PERTURB_ to zero disables the feature.\n\nThis technique can find hard to detect bugs.\nIt is therefore suggested to always use this flag (at least temporarily)\nwhen testing out code or a new distribution.\n\nBut the test suite can use also valgrind(memcheck) via 'make valgrind'\nor 'make GIT_TEST_OPTS=\"--valgrind\"'.\n\nMemcheck wraps client calls to malloc(), and puts a \"red zone\" on\neach end of each block in order to detect access overruns.\nMemcheck already detects double free() (up to the limit of the buffer\nwhich remembers pending free()). Thus memcheck subsumes all the\ndocumented coverage of MALLOC_CHECK_.\n\nIf MALLOC_CHECK_ is set non-zero when running memcheck, then the\noverruns that might be detected by MALLOC_CHECK_ would be overruns\non the wrapped blocks which include the red zones.  Thus MALLOC_CHECK_\nwould be checking memcheck, and not the client.  This is not useful,\nand actually is wasteful.  The only possible [documented] advantage\nof using MALLOC_CHECK_ and memcheck together, would be if MALLOC_CHECK_\ndetected duplicate free() in more cases than memcheck because memcheck's\nbuffer is too small.\n\nTherefore we don't use MALLOC_CHECK_ and valgrind(memcheck) at the\nsame time.\n\nSigned-off-by: Elia Pinto <gitter.spiros@gmail.com>\n---\nThis the third reroll of the original patch.\n\nI redid the patch correcting the export command in a more portable\nway thanks to the Junio observation and not setting MALLOC_CHECK_\nat the same time we are using valgrind. Added in the commit the reason,\nnot so simple to find. Hope the better :=)\n\n\n t/test-lib.sh |    9 +++++++++\n 1 file changed, 9 insertions(+)\n\ndiff --git a/t/test-lib.sh b/t/test-lib.sh\nindex 78c4286..f34b861 100644\n--- a/t/test-lib.sh\n+++ b/t/test-lib.sh\n@@ -93,6 +93,15 @@ export GIT_AUTHOR_EMAIL GIT_AUTHOR_NAME\n export GIT_COMMITTER_EMAIL GIT_COMMITTER_NAME\n export EDITOR\n \n+# Add libc MALLOC and MALLOC_PERTURB test \n+# only if we are not executing the test with valgrind\n+expr \"$GIT_TEST_OPTS\" : \".*\\(--valgrind\\)\" >/dev/null || {\n+\tMALLOC_CHECK_=3\n+\texport MALLOC_CHECK_\n+\tMALLOC_PERTURB_=\"$( expr \\( $$ % 255 \\) + 1)\"\n+\texport MALLOC_PERTURB_\n+}\n+\n # Protect ourselves from common misconfiguration to export\n # CDPATH into the environment\n unset CDPATH\n-- \n1.7.10.4\n"},{"id":"199059","messageId":"7v392k5w7u.fsf@alter.siamese.dyndns.org","threadId":"31533","inReplyTo":"1347641662-3596-1-git-send-email-gitter.spiros@gmail.com","subject":"Re: [PATCH] Add MALLOC_CHECK_ and MALLOC_PERTURB_ libc env to the test suite for detecting heap corruption","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-09-14T17:51:33Z","receivedAt":"2012-09-14T17:51:33Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Elia Pinto <gitter.spiros@gmail.com> writes:\n\n> Recent versions of Linux libc (later than 5.4.23) and glibc (2.x)\n> include a malloc() implementation which is tunable via environment\n> variables. When MALLOC_CHECK_ is set, a special (less efficient)\n> implementation is used which is designed to be tolerant against\n> simple errors, such as double calls of free() with the same argument,\n> or overruns of a single byte (off-by-one bugs). When MALLOC_CHECK_\n> is set to 3, a diagnostic message is printed on stderr\n> and the program is aborted.\n> ...\n> Signed-off-by: Elia Pinto <gitter.spiros@gmail.com>\n> ---\n> This the third reroll of the original patch.\n\nWell written.  I have one suggestion and a question, though.\n\n>  t/test-lib.sh |    9 +++++++++\n>  1 file changed, 9 insertions(+)\n>\n> diff --git a/t/test-lib.sh b/t/test-lib.sh\n> index 78c4286..f34b861 100644\n> --- a/t/test-lib.sh\n> +++ b/t/test-lib.sh\n> @@ -93,6 +93,15 @@ export GIT_AUTHOR_EMAIL GIT_AUTHOR_NAME\n>  export GIT_COMMITTER_EMAIL GIT_COMMITTER_NAME\n>  export EDITOR\n>  \n> +# Add libc MALLOC and MALLOC_PERTURB test \n> +# only if we are not executing the test with valgrind\n> +expr \"$GIT_TEST_OPTS\" : \".*\\(--valgrind\\)\" >/dev/null || {\n\nI would write this like\n\n\tif ! expr \" $GIT_TEST_OPTS \" : \".* --valgrind \" >/dev/null\n\tthen\n\t\t...\n\tfi\n\n> +\tMALLOC_CHECK_=3\n> +\texport MALLOC_CHECK_\n> +\tMALLOC_PERTURB_=\"$( expr \\( $$ % 255 \\) + 1)\"\n\nHow was this expression chosen?  The only effect I can think of to\nuse a randomly picked value here is to make it impossible to make\nthe test repeatable and reproducible, so you must have had some\nbenefit that outweighs the downside, but I cannot think of any.\nWouldn't MALLOC_PERTURB_=165 (i.e. 0xA5, half of the bits in the\nbyte is set, including the MSB, and is an odd number) be equally a\ngood choice without repeatability downside, for example?\n\nAlso, doesn't the above give 256 sometimes, which would not fit in a\nbyte?\n\n> +\texport MALLOC_PERTURB_\n> +}\n> +\n>  # Protect ourselves from common misconfiguration to export\n>  # CDPATH into the environment\n>  unset CDPATH\n"},{"id":"199083","messageId":"7vligc19d1.fsf@alter.siamese.dyndns.org","threadId":"31533","inReplyTo":"7v392k5w7u.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] Add MALLOC_CHECK_ and MALLOC_PERTURB_ libc env to the test suite for detecting heap corruption","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-09-14T23:18:50Z","receivedAt":"2012-09-14T23:18:50Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> Elia Pinto <gitter.spiros@gmail.com> writes:\n>\n>> Recent versions of Linux libc (later than 5.4.23) and glibc (2.x)\n>> include a malloc() implementation which is tunable via environment\n>> variables. When MALLOC_CHECK_ is set, a special (less efficient)\n>> implementation is used which is designed to be tolerant against\n>> simple errors, such as double calls of free() with the same argument,\n>> or overruns of a single byte (off-by-one bugs). When MALLOC_CHECK_\n>> is set to 3, a diagnostic message is printed on stderr\n>> and the program is aborted.\n>> ...\n>> Signed-off-by: Elia Pinto <gitter.spiros@gmail.com>\n>> ---\n>> This the third reroll of the original patch.\n>\n> Well written.  I have one suggestion and a question, though.\n\nAfter looking at it a bit more, there are a few more things I would\nsuggest, in the form of an squashable patch on top.\n\nPoints to note:\n\n - When test-lib.sh is used from perf-lib, we would not want to be\n   affected with MALLOC_CHECK_; we would want to run as vanilla as\n   possible in that case.\n\n - We are interested in checking \"git\" and whatever we test using\n   the test harness, i.e. what comes inside test_expect_success.\n   Setting MALLOC_CHECK_ at the beginning will cover a lot more than\n   what we want to test.\n\n - That \"165\" thing I mentioned earlier.\n\n - Update the \"expr\" expression to make sure the --valgrind we catch\n   is indeed an option, not a substring of something else.  Also\n   there is no need to capture the substring.\n\n t/perf/perf-lib.sh |  1 +\n t/test-lib.sh      | 26 ++++++++++++++++++++------\n 2 files changed, 21 insertions(+), 6 deletions(-)\n\ndiff --git i/t/perf/perf-lib.sh w/t/perf/perf-lib.sh\nindex a1361e5..1d0bb9d 100644\n--- i/t/perf/perf-lib.sh\n+++ w/t/perf/perf-lib.sh\n@@ -42,6 +42,7 @@ else\n fi\n \n TEST_NO_CREATE_REPO=t\n+TEST_NO_MALLOC_=t\n \n . ../test-lib.sh\n \ndiff --git i/t/test-lib.sh w/t/test-lib.sh\nindex b0c0c84..aad4606 100644\n--- i/t/test-lib.sh\n+++ w/t/test-lib.sh\n@@ -95,12 +95,24 @@ export EDITOR\n \n # Add libc MALLOC and MALLOC_PERTURB test\n # only if we are not executing the test with valgrind\n-expr \"$GIT_TEST_OPTS\" : \".*\\(--valgrind\\)\" >/dev/null || {\n-\tMALLOC_CHECK_=3\n-\texport MALLOC_CHECK_\n-\tMALLOC_PERTURB_=\"$( expr \\( $$ % 255 \\) + 1)\"\n-\texport MALLOC_PERTURB_\n-}\n+if expr \" $GIT_TEST_OPTS \" : \".* --valgrind \" >/dev/null ||\n+   test -n \"TEST_NO_MALLOC_\"\n+then\n+\tsetup_malloc_check () {\n+\t\t: nothing\n+\t}\n+\tteardown_malloc_check () {\n+\t\t: nothing\n+\t}\n+else\n+\tsetup_malloc_check () {\n+\t\tMALLOC_CHECK_=3\tMALLOC_PERTURB_=165\n+\t\texport MALLOC_CHECK_ MALLOC_PERTURB_\n+\t}\n+\tteardown_malloc_check () {\n+\t\tunset MALLOC_CHECK_ MALLOC_PERTURB_\n+\t}\n+fi\n \n # Protect ourselves from common misconfiguration to export\n # CDPATH into the environment\n@@ -311,7 +323,9 @@ test_run_ () {\n \n \tif test -z \"$immediate\" || test $eval_ret = 0 || test -n \"$expecting_failure\"\n \tthen\n+\t\tsetup_malloc_check\n \t\ttest_eval_ \"$test_cleanup\"\n+\t\tteardown_malloc_check\n \tfi\n \tif test \"$verbose\" = \"t\" && test -n \"$HARNESS_ACTIVE\"\n \tthen\n"},{"id":"199219","messageId":"CA+EOSBk0hN+v+PK8jzCCZgG0Ko7SsHOSB=cM7nnaSsrUOaJ-7Q@mail.gmail.com","threadId":"31533","inReplyTo":"7vligc19d1.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] Add MALLOC_CHECK_ and MALLOC_PERTURB_ libc env to the test suite for detecting heap corruption","fromName":"Elia Pinto","fromEmail":"gitter.spiros@gmail.com","sentAt":"2012-09-17T12:17:15Z","receivedAt":"2012-09-17T12:17:15Z","isPatch":true,"sender":{"key":"gitter.spiros@gmail.com","avatar":"https://avatars.githubusercontent.com/u/158490?v=4"},"body":"2012/9/15 Junio C Hamano <gitster@pobox.com>:\n> Junio C Hamano <gitster@pobox.com> writes:\n>\n>> Elia Pinto <gitter.spiros@gmail.com> writes:\n>>\n>>> Recent versions of Linux libc (later than 5.4.23) and glibc (2.x)\n>>> include a malloc() implementation which is tunable via environment\n>>> variables. When MALLOC_CHECK_ is set, a special (less efficient)\n>>> implementation is used which is designed to be tolerant against\n>>> simple errors, such as double calls of free() with the same argument,\n>>> or overruns of a single byte (off-by-one bugs). When MALLOC_CHECK_\n>>> is set to 3, a diagnostic message is printed on stderr\n>>> and the program is aborted.\n>>> ...\n>>> Signed-off-by: Elia Pinto <gitter.spiros@gmail.com>\n>>> ---\n>>> This the third reroll of the original patch.\n>>\n>> Well written.  I have one suggestion and a question, though.\n>\n> After looking at it a bit more, there are a few more things I would\n> suggest, in the form of an squashable patch on top.\n>\n> Points to note:\n>\n>  - When test-lib.sh is used from perf-lib, we would not want to be\n>    affected with MALLOC_CHECK_; we would want to run as vanilla as\n>    possible in that case.\n>\n>  - We are interested in checking \"git\" and whatever we test using\n>    the test harness, i.e. what comes inside test_expect_success.\n>    Setting MALLOC_CHECK_ at the beginning will cover a lot more than\n>    what we want to test.\n>\n>  - That \"165\" thing I mentioned earlier.\n\nThank you so much for the comments, that's fine. A single\nconsideration for  MALLOC_PERTURB.\n\nYou can use any value between 1..255 for MALLOC_PERTURB_\nThat chooses the byte that glibc will use to memset all freed buffers.\nIn general it is defined as\n\n    export MALLOC_PERTURB_=$(($RANDOM % 255 + 1))\n\n(as drepper pointed out http://udrepper.livejournal.com/11429.html)\n\nI don't use RANDOM because it is not portable but $$ is sufficient for\nthe bias. I use this in popt\n(http://rpm5.org/community/rpm-devel/5311.html but the site is down\nnow)\n\nUsing a random value is slightly better than using a fixed one\nin case your fixed value is someday just the right/wrong value to mask\na problem.  At least with a random value, if you rerun\nthe test in a different shell, the odds are good you won't use\nthe unfortunate setting again. % is the module operation so the above\nexpression returns a value between 1 and 255 always (for the euclidean\ndivision\nproperty :=).\n\nSo OK per the original expression ? I prefer a perfect commit for git,\nbut no problem to follow your advice and reroll the patch.\n\nOpinions ?\n\nBest Regards\n"},{"id":"199279","messageId":"7vzk4otmwb.fsf@alter.siamese.dyndns.org","threadId":"31533","inReplyTo":"CA+EOSBk0hN+v+PK8jzCCZgG0Ko7SsHOSB=cM7nnaSsrUOaJ-7Q@mail.gmail.com","subject":"Re: [PATCH] Add MALLOC_CHECK_ and MALLOC_PERTURB_ libc env to the test suite for detecting heap corruption","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-09-17T20:28:04Z","receivedAt":"2012-09-17T20:28:04Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Elia Pinto <gitter.spiros@gmail.com> writes:\n\n>>  - That \"165\" thing I mentioned earlier.\n>\n> Thank you so much for the comments, that's fine. A single\n> consideration for  MALLOC_PERTURB.\n>\n> You can use any value between 1..255 for MALLOC_PERTURB_\n> That chooses the byte that glibc will use to memset all freed buffers.\n> In general it is defined as\n>\n>     export MALLOC_PERTURB_=$(($RANDOM % 255 + 1))\n>\n> (as drepper pointed out http://udrepper.livejournal.com/11429.html)\n\nDrepper never recommends RANDOM there.\n\n> Using a random value is slightly better than using a fixed one\n> in case your fixed value is someday just the right/wrong value to mask\n> a problem.\n\nQuite the contrary.  When you use a fixed pattern, it is easy which\nother pieces of memory has uninitailized contents.  When you use a\nrandom value, you sometimes get an error and sometimes the test\nmysteriously pass, which does not help debugging.\n\nopenSUSE folks seem to use a fixed value for this exact reason of\nrepeatability of tests.\n\nhttp://jaegerandi.blogspot.com/2012/01/finding-subtile-malloc-bugs.html\n\n> So OK per the original expression?\n\nNo.\n\nI am not convinced 165 is the perfect value, but I am fairly certain\nany fixed value is better than using a random to deliberately worsen\nrepeatability of the tests.\n"},{"id":"199327","messageId":"CA+EOSBmapjFxKkfPVAxg8q=J9gkiz8Hg0B4=pxfRi0RGQ_kEwA@mail.gmail.com","threadId":"31533","inReplyTo":"7vzk4otmwb.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] Add MALLOC_CHECK_ and MALLOC_PERTURB_ libc env to the test suite for detecting heap corruption","fromName":"Elia Pinto","fromEmail":"gitter.spiros@gmail.com","sentAt":"2012-09-18T04:22:01Z","receivedAt":"2012-09-18T04:22:01Z","isPatch":true,"sender":{"key":"gitter.spiros@gmail.com","avatar":"https://avatars.githubusercontent.com/u/158490?v=4"},"body":"Ok.\n\nPlease use the patch that you have already queued in the ep integration branch.\n\nThank you\n\n2012/9/17, Junio C Hamano <gitster@pobox.com>:\n> Elia Pinto <gitter.spiros@gmail.com> writes:\n>\n>>>  - That \"165\" thing I mentioned earlier.\n>>\n>> Thank you so much for the comments, that's fine. A single\n>> consideration for  MALLOC_PERTURB.\n>>\n>> You can use any value between 1..255 for MALLOC_PERTURB_\n>> That chooses the byte that glibc will use to memset all freed buffers.\n>> In general it is defined as\n>>\n>>     export MALLOC_PERTURB_=$(($RANDOM % 255 + 1))\n>>\n>> (as drepper pointed out http://udrepper.livejournal.com/11429.html)\n>\n> Drepper never recommends RANDOM there.\n>\n>> Using a random value is slightly better than using a fixed one\n>> in case your fixed value is someday just the right/wrong value to mask\n>> a problem.\n>\n> Quite the contrary.  When you use a fixed pattern, it is easy which\n> other pieces of memory has uninitailized contents.  When you use a\n> random value, you sometimes get an error and sometimes the test\n> mysteriously pass, which does not help debugging.\n>\n> openSUSE folks seem to use a fixed value for this exact reason of\n> repeatability of tests.\n>\n> http://jaegerandi.blogspot.com/2012/01/finding-subtile-malloc-bugs.html\n>\n>> So OK per the original expression?\n>\n> No.\n>\n> I am not convinced 165 is the perfect value, but I am fairly certain\n> any fixed value is better than using a random to deliberately worsen\n> repeatability of the tests.\n>\n\n-- \nInviato dal mio dispositivo mobile\n"},{"id":"199973","messageId":"506362A7.5090108@lsrfire.ath.cx","threadId":"31533","inReplyTo":"7vligc19d1.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] Add MALLOC_CHECK_ and MALLOC_PERTURB_ libc env to the test suite for detecting heap corruption","fromName":"René Scharfe","fromEmail":"rene.scharfe@lsrfire.ath.cx","sentAt":"2012-09-26T20:16:39Z","receivedAt":"2012-09-26T20:16:39Z","isPatch":true,"sender":{"key":"l.s.r@web.de","avatar":"https://avatars.githubusercontent.com/u/26122331?v=4"},"body":"Sorry for being late.  Just wanted to try out this new feature and\nended up reading this old thread.\n\nAm 15.09.2012 01:18, schrieb Junio C Hamano:\n>   t/perf/perf-lib.sh |  1 +\n>   t/test-lib.sh      | 26 ++++++++++++++++++++------\n>   2 files changed, 21 insertions(+), 6 deletions(-)\n> \n> diff --git i/t/perf/perf-lib.sh w/t/perf/perf-lib.sh\n> index a1361e5..1d0bb9d 100644\n> --- i/t/perf/perf-lib.sh\n> +++ w/t/perf/perf-lib.sh\n> @@ -42,6 +42,7 @@ else\n>  fi\n>   \n>  TEST_NO_CREATE_REPO=t\n> +TEST_NO_MALLOC_=t\n\nWhy the trailing underscore?  Perhaps add \"CHECK\" before the equal sign?\n\n>   . ../test-lib.sh\n>   \n> diff --git i/t/test-lib.sh w/t/test-lib.sh\n> index b0c0c84..aad4606 100644\n> --- i/t/test-lib.sh\n> +++ w/t/test-lib.sh\n> @@ -95,12 +95,24 @@ export EDITOR\n>  \n>  # Add libc MALLOC and MALLOC_PERTURB test\n>  # only if we are not executing the test with valgrind\n> -expr \"$GIT_TEST_OPTS\" : \".*\\(--valgrind\\)\" >/dev/null || {\n> -\tMALLOC_CHECK_=3\n> -\texport MALLOC_CHECK_\n> -\tMALLOC_PERTURB_=\"$( expr \\( $$ % 255 \\) + 1)\"\n> -\texport MALLOC_PERTURB_\n> -}\n> +if expr \" $GIT_TEST_OPTS \" : \".* --valgrind \" >/dev/null ||\n> +   test -n \"TEST_NO_MALLOC_\"\n\nWithout a $, you'll get nothing. ;-)\n\n('test -n \"string\"' is always true, unlike 'test -n \"$variable\"'.)\n\n> +then\n> +\tsetup_malloc_check () {\n> +\t\t: nothing\n> +\t}\n> +\tteardown_malloc_check () {\n> +\t\t: nothing\n> +\t}\n> +else\n> +\tsetup_malloc_check () {\n> +\t\tMALLOC_CHECK_=3\tMALLOC_PERTURB_=165\n> +\t\texport MALLOC_CHECK_ MALLOC_PERTURB_\n> +\t}\n> +\tteardown_malloc_check () {\n> +\t\tunset MALLOC_CHECK_ MALLOC_PERTURB_\n> +\t}\n\nWould it make sense to restore the previous values?  Hrm, can't think of a use case.\n\n> +fi\n>   \n>  # Protect ourselves from common misconfiguration to export\n>  # CDPATH into the environment\n> @@ -311,7 +323,9 @@ test_run_ () {\n>  \n>  \tif test -z \"$immediate\" || test $eval_ret = 0 || test -n \"$expecting_failure\"\n>  \tthen\n> +\t\tsetup_malloc_check\n>  \t\ttest_eval_ \"$test_cleanup\"\n> +\t\tteardown_malloc_check\n>  \tfi\n>  \tif test \"$verbose\" = \"t\" && test -n \"$HARNESS_ACTIVE\"\n>  \tthen\n\n-- >8 --\nSubject: [PATCH] MALLOC_CHECK: enable it, unless disabled explicitly\n\nThe malloc checks in tests are currently disabled.  Actually evaluate\nthe variable for turning them off and enable them if it's unset.\n\nAlso use this opportunity to give it the more descriptive and\nconsistent name TEST_NO_MALLOC_CHECK.\n\nSigned-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>\n---\n t/perf/perf-lib.sh | 2 +-\n t/test-lib.sh      | 2 +-\n 2 files changed, 2 insertions(+), 2 deletions(-)\n\ndiff --git a/t/perf/perf-lib.sh b/t/perf/perf-lib.sh\nindex 1d0bb9d..a816fbc 100644\n--- a/t/perf/perf-lib.sh\n+++ b/t/perf/perf-lib.sh\n@@ -42,7 +42,7 @@ else\n fi\n \n TEST_NO_CREATE_REPO=t\n-TEST_NO_MALLOC_=t\n+TEST_NO_MALLOC_CHECK=t\n \n . ../test-lib.sh\n \ndiff --git a/t/test-lib.sh b/t/test-lib.sh\nindex bff3d75..617d831 100644\n--- a/t/test-lib.sh\n+++ b/t/test-lib.sh\n@@ -105,7 +105,7 @@ export EDITOR\n # Add libc MALLOC and MALLOC_PERTURB test\n # only if we are not executing the test with valgrind\n if expr \" $GIT_TEST_OPTS \" : \".* --valgrind \" >/dev/null ||\n-   test -n \"TEST_NO_MALLOC_\"\n+   test -n \"$TEST_NO_MALLOC_CHECK\"\n then\n \tsetup_malloc_check () {\n \t\t: nothing\n-- \n1.7.12\n"},{"id":"199995","messageId":"7vk3vgrmui.fsf@alter.siamese.dyndns.org","threadId":"31533","inReplyTo":"506362A7.5090108@lsrfire.ath.cx","subject":"Re: [PATCH] Add MALLOC_CHECK_ and MALLOC_PERTURB_ libc env to the test suite for detecting heap corruption","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-09-27T06:39:17Z","receivedAt":"2012-09-27T06:39:17Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Thanks.\n"}]}