From: Elia Pinto <gitter.spiros@gmail.com>
Date: Tue, 18 Sep 2012 04:22:01 GMT
Subject: Re: [PATCH] Add MALLOC_CHECK_ and MALLOC_PERTURB_ libc env to the test suite for detecting heap corruption
Message-ID: <CA+EOSBmapjFxKkfPVAxg8q=J9gkiz8Hg0B4=pxfRi0RGQ_kEwA@mail.gmail.com>
In-Reply-To: <7vzk4otmwb.fsf@alter.siamese.dyndns.org>

Ok.

Please use the patch that you have already queued in the ep integration branch.

Thank you

2012/9/17, Junio C Hamano <gitster@pobox.com>:
> Elia Pinto <gitter.spiros@gmail.com> writes:
>
>>>  - That "165" thing I mentioned earlier.
>>
>> Thank you so much for the comments, that's fine. A single
>> consideration for  MALLOC_PERTURB.
>>
>> You can use any value between 1..255 for MALLOC_PERTURB_
>> That chooses the byte that glibc will use to memset all freed buffers.
>> In general it is defined as
>>
>>     export MALLOC_PERTURB_=$(($RANDOM % 255 + 1))
>>
>> (as drepper pointed out http://udrepper.livejournal.com/11429.html)
>
> Drepper never recommends RANDOM there.
>
>> Using a random value is slightly better than using a fixed one
>> in case your fixed value is someday just the right/wrong value to mask
>> a problem.
>
> Quite the contrary.  When you use a fixed pattern, it is easy which
> other pieces of memory has uninitailized contents.  When you use a
> random value, you sometimes get an error and sometimes the test
> mysteriously pass, which does not help debugging.
>
> openSUSE folks seem to use a fixed value for this exact reason of
> repeatability of tests.
>
> http://jaegerandi.blogspot.com/2012/01/finding-subtile-malloc-bugs.html
>
>> So OK per the original expression?
>
> No.
>
> I am not convinced 165 is the perfect value, but I am fairly certain
> any fixed value is better than using a random to deliberately worsen
> repeatability of the tests.
>

-- 
Inviato dal mio dispositivo mobile