2012/10/12 Kurt Zeilenga <[email protected]>:
>
> On Oct 12, 2012, at 8:38 AM, Elia Pinto <[email protected]> wrote:
>
>> 2012/10/12 Kurt Zeilenga <[email protected]>:
>>> You miss the fact that we encourage deployers of OpenLDAP Software, who we 
>>> recommend build OpenLDAP Software from source, run 'make test' before they 
>>> 'make install'.   We don't want these deployers to have false positives, 
>>> such as would be likely caused if we added such environmental variables.
>>
>> It is your own opinion, right? Have experiences in this regard?
>
> Yes and Yes.  I use to run with such environmental variables set in my 
> .login.  Not anymore, too many odd crashes.  So sometimes I do something like:
>         env MallocScribble=yes MallocErrorAbort=yes make test
>
> but I've that crash above and below the run script, but not in OpenLDAP 
> Software itself.  So now, because I tend to run stuff I'm working on in a 
> debugger, I now mostly rely on my debugger to turn malloc debugging on.  And 
> I tend to use other tools for leak detection (like leaks(1) on MacOS/X).

HeHe, i suspect was ONLY a MacOS/X crap. Good to know.
>
> -- Kurt
>
>
>> I do
>> not. I personally run make test on openldap with Ubuntu 4.12, Fedora
>> 17 and RHEL6 and my patch without any problem (good for openldap :=)
>> ). And many other projects, for example,  git hat has a very extensive
>> test suite, use MALLOC_CHECK as in my patch, integrated in a test
>> suite.
>>
>> However, I will not insist further on a trivial patch. Also because
>> this discussion gave me the opportunity to investigate better the
>> issue, and I'll just patch for FreeBSD my software. So, thank you
>> anyway for the useful observations.
>>
>> Regards
>>>
>>> For those doing automated checks, such as those who do construct packages, 
>>> they can have local patches to their hearts content.  Likewise for 
>>> developers.
>>>
>>> So, if it was up to me, I would reject your patch as, IMO, it's in 
>>> appropriate for our source distributions.  I suspect Howard will chime in 
>>> sooner or later.
>>>
>>> -- Kurt
>>>
>


Reply via email to