MALLOC_PERTURB_: everyone should set this envvar

[Jim Meyering]

I posted about MALLOC_PERTURB_ about a year ago,

    http://thread.gmane.org/gmane.linux.redhat.fedora.devel/132690

but it is clear that not everyone is setting the variable, so for those
who didn't take the time last year, or who are new to the subject,
do yourself a favor and set MALLOC_PERTURB_ to a value in 1..255
everywhere.

For those who can't be bothered to click the link, here's that post:

    ------------
    If you are into development on glibc-based systems
    and do not set MALLOC_PERTURB_ to a nonzero value, then you
    are missing an easy opportunity to detect subtle bugs early.

    Sure, you can use valgrind, and it will detect whatever a
    MALLOC_PERTURB_ setting would have caught, and more, but it's
    far more expensive and takes some effort, however minimal.

    If you use zsh or bash, put this in one of your startup files:

        # http://udrepper.livejournal.com/11429.html
        export MALLOC_PERTURB_=$(($RANDOM % 255 + 1))

    and remember that when you find surprising bugs, that others
    who are also running tests (but without MALLOC_PERTURB_)
    will not see the same failures.

    This is useful enough that it is worth considering for inclusion
    in /etc/profile.
    ------------

Why do I insist?

Here's a nice example: a month or so ago I was investigating
a build problem in libvirt and as part of that, ran "make check"
from the cloned source tree.  Imagine my surprise when one of
the tests failed.  Obviously, while it was failing for me, it
was not failing for the many people who build libvirt regularly,
so what was different here?  I had MALLOC_PERTURB_ set in my
environment and they did not.

The bug I uncovered was a heap corruptor that dated back to
libvirt-0.9.5:

    http://thread.gmane.org/gmane.comp.emulators.libvirt/56605

TL;DR: Add these lines to your ~/.bash_profile or ~/.zshenv:

    # http://udrepper.livejournal.com/11429.html
    export MALLOC_PERTURB_=$(($RANDOM % 255 + 1))

One caveat: this does induce a small performance penalty (usually
negligible), so when you're measuring performance, you may want
to turn it off.