Re: use MALLOC_PERTURB_ ... or lose

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

 



H. Guémar wrote:
>> This is useful enough that it is worth considering for inclusion
> in /etc/profile.
>
> during development cycle: +1
> for stable/production release: not so much (users would hate us for that)

It's definitely not suitable for everyone.
My suggestion was intended to be provocative ;-)

Eric Sandeen had a nice idea: enable it for rawhide,
say by testing for "Rawhide" in /etc/redhat-release.

I propose (seriously, now) to add this to /etc/profile,
or to some always-sourced file like /etc/profile.d/glibc.sh:

    # Enable glibc's malloc perturbing feature in Rawhide.
    # http://udrepper.livejournal.com/11429.html
    read _f _r _n _code_name < /etc/redhat-release &&
    case $_code_name in
        *Rawhide*) export MALLOC_PERTURB_=$((RANDOM % 255 + 1)) ;;
    esac

Alternatively, if we should handle the case of a missing
/etc/redhat-release, and want to avoid generating a diagnostic about it:

    if test -r /etc/redhat-release; then
        # Enable glibc's malloc perturbing feature in Rawhide.
        # http://udrepper.livejournal.com/11429.html
        read _f _r _n _code_name < /etc/redhat-release &&
        case $_code_name in
            *Rawhide*) export MALLOC_PERTURB_=$((RANDOM % 255 + 1)) ;;
        esac
    fi
-- 
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux