[Date Prev][Date Next]
Re: (ITS#7415) Add MALLOC_CHECK_ and MALLOC_PERTURB_ libc env to the test suite for detecting heap corruption
- To: openldap-its@OpenLDAP.org
- Subject: Re: (ITS#7415) Add MALLOC_CHECK_ and MALLOC_PERTURB_ libc env to the test suite for detecting heap corruption
- From: Kurt@OpenLDAP.org
- Date: Fri, 12 Oct 2012 15:55:37 GMT
- Auto-submitted: auto-generated (OpenLDAP-ITS)
On Oct 12, 2012, at 8:38 AM, Elia Pinto <email@example.com> wrote:
> 2012/10/12 Kurt Zeilenga <Kurt@openldap.org>:
>> 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).
> 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
> 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.
>> 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