October 2012 - openldap-bugs

Re: (ITS#7415) Add MALLOC_CHECK_ and MALLOC_PERTURB_ libc env to the test suite for detecting heap corruption

by hyc＠symas.com

Kurt(a)OpenLDAP.org wrote: > 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. > > 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. I think you've already covered the points. I have plenty of checks like this in my local source tree, but I see no reason to embed OS and platform-specific stuff into the distributed source. I believe it would lend a false sense of security, particularly when you're on a platform that ignores these variables, but you aren't aware of the fact. It is always the developers' responsibility to know how their own development environment works, and to tweak it to suit their development efforts. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

10 years, 11 months

1
0
0 / 0

Re: (ITS#7415) Add MALLOC_CHECK_ and MALLOC_PERTURB_ libc env to the test suite for detecting heap corruption

by gitter.spiros＠gmail.com

2012/10/12 Kurt Zeilenga <Kurt(a)openldap.org>: > > On Oct 12, 2012, at 8:38 AM, Elia Pinto <gitter.spiros(a)gmail.com> wrote: > >> 2012/10/12 Kurt Zeilenga <Kurt(a)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). 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 >>> >

10 years, 11 months

1
0
0 / 0

Re: (ITS#7415) Add MALLOC_CHECK_ and MALLOC_PERTURB_ libc env to the test suite for detecting heap corruption

by Kurt＠OpenLDAP.org

On Oct 12, 2012, at 8:38 AM, Elia Pinto <gitter.spiros(a)gmail.com> wrote: > 2012/10/12 Kurt Zeilenga <Kurt(a)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). -- 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 >>

10 years, 11 months

1
0
0 / 0

Re: (ITS#7415) Add MALLOC_CHECK_ and MALLOC_PERTURB_ libc env to the test suite for detecting heap corruption

by gitter.spiros＠gmail.com

2012/10/12 Kurt Zeilenga <Kurt(a)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? 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 >

10 years, 11 months

1
0
0 / 0

Re: (ITS#7415) Add MALLOC_CHECK_ and MALLOC_PERTURB_ libc env to the test suite for detecting heap corruption

by 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. 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

10 years, 11 months

1
0
0 / 0

Re: (ITS#7415) Add MALLOC_CHECK_ and MALLOC_PERTURB_ libc env to the test suite for detecting heap corruption

by gitter.spiros＠gmail.com

2012/10/11 Kurt Zeilenga <Kurt(a)openldap.org>: > I note that these environment variables are specific to Linux, and then only certain Linux systems. If we add these, then we should also add similar environment variables for FreeBSD malloc(3), MacOS/X malloc(3), and various alternative malloc(3) libraries. And then we might get into cases where variables for one set of environmental variables conflict with another. As these can be set by the developer as desired in their development environment, there's little reason to get into setting all the malloc(3) environmental variables that might be useful... and we shouldn't play favors and only set variables for Linux. Sorry for the delay, problems to the my $DAYWORK Ok. First of all, elibc (debian/ubuntu recently) and glibc cover probably 95% of the Linux distributions, and they are compatible, in particular for the MALLOC_CHECK http://lwn.net/Articles/333755/ - i have also checked the source. A considerable part of the remaining operating systems are like BSD - FreeBSD for example - and MacOSX, FreeBSD based. In fact, these latter two have different malloc library and it may be necessary to activate different controls for different systems (see the first reference) http://permalink.gmane.org/gmane.network.openvswitch.devel/14838 http://www.unix.com/man-page/freebsd/5/malloc.conf/ But the benefits of automating these tests is to do a better AUTOQA for the buildsystem. It is also not true, as experience shows, that all developers know everything. Beeing expert in LDAP and C programming, for example, does not mean necessarily be an expert in everything: this can certainly be true for the OPENLDAP developers but it is not always the case. Here some examples: http://lists.fedoraproject.org/pipermail/devel/2010-May/135683.html (this check had found many bug that the upstream developer haven't catched) or this, from my mantainer, http://lists.gnupg.org/pipermail/gcrypt-devel/2010-June/001605.html I saw that you have closed the case(WANTFIX i think), however, I have to tell you better my opinion. If, as can happen, you decide that my reasons make sense, i can reroll my patch for Linux, macos and freebsd. Let me know. Thanks anyway for your reply > > -- Kurt >

10 years, 11 months

1
0
0 / 0

Re: (ITS#7414) rwm: ldapmodify, slapd segmentation fault

by jvcelak＠redhat.com

> > The slapd daemon will crash, here is the full backtrace: > > Thanks for the detailed report. Fixed now in master. > Thank you for the very fast resolution. Jan

10 years, 11 months

1
0
0 / 0

Re: (ITS#7415) Add MALLOC_CHECK_ and MALLOC_PERTURB_ libc env to the test suite for detecting heap corruption

by kurt＠OpenLDAP.org

On Oct 11, 2012, at 1:44 PM, h.b.furuseth(a)usit.uio.no wrote: > We can describe these and other variables in tests/README. There's lots of malloc variables one could describe. Better off to simply say that one might want to read the documentation for whatever malloc they are using, and use, if they want, any environmental variables they might want to use. This avoids duplicating detail better left to the malloc documentation. > > Yeah I know, people don't read documentation. The testing > announcements could mention the file though. Wrong audience, me thinks, especially if those announcements are posted to openldap-techncial. We don't need openldap users reporting malloc use issues in non-OpenLDAP programs. Use of such variables should be limited to developers. -- Kurt > >

10 years, 11 months

1
0
0 / 0

(ITS#7416) entryCSN index errors when changing olcDbEnvFlags with back-mdb

by quanah＠OpenLDAP.org

Full_Name: Quanah Gibson-Mount Version: 2.4.33 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (74.196.25.250) I found that if I modify the olcDbEnvFlags on a back-mdb database to have: olcDbEnvFlags: writemap olcDbEnvFlags: nometasync Then modifications in the primary database will throw the following error until slapd is restarted: Oct 11 14:38:01 zre-ldap002 slapd[22940]: conn=1001 fd=11 ACCEPT from PATH=/opt/zimbra/openldap-2.4.33.2z/var/run/ldapi (PATH=/opt/zimbra/openldap-2.4.33.2z/var/run/ldapi) Oct 11 14:38:01 zre-ldap002 slapd[22940]: conn=1001 op=0 BIND dn="cn=config" method=128 Oct 11 14:38:01 zre-ldap002 slapd[22940]: conn=1001 op=0 BIND dn="cn=config" mech=SIMPLE ssf=0 Oct 11 14:38:01 zre-ldap002 slapd[22940]: conn=1001 op=0 RESULT tag=97 err=0 text= Oct 11 14:38:01 zre-ldap002 slapd[22940]: conn=1001 op=1 SRCH base="cn=accesslog" scope=0 deref=2 filter="(objectClass=*)" Oct 11 14:38:01 zre-ldap002 slapd[22940]: conn=1001 op=1 SRCH attr=1.1 Oct 11 14:38:01 zre-ldap002 slapd[22940]: conn=1001 op=1 SEARCH RESULT tag=101 err=32 nentries=0 text= Oct 11 14:38:01 zre-ldap002 slapd[22940]: conn=1001 op=2 SRCH base="olcDatabase={2}mdb,cn=config" scope=0 deref=2 filter="(objectClass=*)" Oct 11 14:38:01 zre-ldap002 slapd[22940]: conn=1001 op=2 SRCH attr=olcDbEnvFlags Oct 11 14:38:01 zre-ldap002 slapd[22940]: conn=1001 op=2 SEARCH RESULT tag=101 err=0 nentries=1 text= Oct 11 14:38:01 zre-ldap002 slapd[22940]: conn=1001 op=3 MOD dn="olcDatabase={2}mdb,cn=config" Oct 11 14:38:01 zre-ldap002 slapd[22940]: conn=1001 op=3 MOD attr=olcDbEnvFlags Oct 11 14:38:01 zre-ldap002 slapd[22940]: slap_queue_csn: queing 0x7f88c17fc3f0 20121011213801.832254Z#000000#000#000000 Oct 11 14:38:01 zre-ldap002 slapd[22940]: conn=1001 op=3 RESULT tag=103 err=0 text= Oct 11 14:38:01 zre-ldap002 slapd[22940]: slap_graduate_commit_csn: removing 0x41d4690 20121011213801.832254Z#000000#000#000000 Oct 11 14:38:01 zre-ldap002 slapd[22940]: conn=1001 op=4 MOD dn="uid=zmpostfix,cn=appaccts,cn=zimbra" Oct 11 14:38:01 zre-ldap002 slapd[22940]: conn=1001 op=4 MOD attr=zimbraId Oct 11 14:38:01 zre-ldap002 slapd[22940]: slap_queue_csn: queing 0x7f88c17fd1a0 20121011213801.864697Z#000000#000#000000 Oct 11 14:38:01 zre-ldap002 slapd[22940]: conn=1001 op=4: attribute "entryCSN" index delete failure Oct 11 14:38:01 zre-ldap002 slapd[22940]: conn=1001 op=4 RESULT tag=103 err=80 text= Oct 11 14:38:01 zre-ldap002 slapd[22940]: slap_graduate_commit_csn: removing 0x41d4690 20121011213801.864697Z#000000#000#000000 Oct 11 14:38:01 zre-ldap002 slapd[22940]: conn=1001 fd=11 closed (connection lost) Oct 11 14:38:06 zre-ldap002 slapd[22940]: conn=1004 fd=14 closed (connection lost) Oct 11 14:38:09 zre-ldap002 slapd[22940]: conn=1005 fd=11 ACCEPT from IP=10.137.242.52:47811 (IP=10.137.242.52:389) Oct 11 14:38:09 zre-ldap002 slapd[22940]: conn=1005 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Oct 11 14:38:09 zre-ldap002 slapd[22940]: conn=1005 op=0 STARTTLS Oct 11 14:38:09 zre-ldap002 slapd[22940]: conn=1005 op=0 RESULT oid= err=0 text= Oct 11 14:38:09 zre-ldap002 slapd[22940]: conn=1005 fd=11 TLS established tls_ssf=256 ssf=256 Oct 11 14:38:09 zre-ldap002 slapd[22940]: conn=1005 op=1 BIND dn="uid=zimbra,cn=admins,cn=zimbra" method=128 Oct 11 14:38:09 zre-ldap002 slapd[22940]: conn=1005 op=1 BIND dn="uid=zimbra,cn=admins,cn=zimbra" mech=SIMPLE ssf=0 Oct 11 14:38:09 zre-ldap002 slapd[22940]: conn=1005 op=1 RESULT tag=97 err=0 text= Oct 11 14:38:09 zre-ldap002 slapd[22940]: conn=1005 op=2 SRCH base="cn=zre-ldap002.eng.vmware.com,cn=servers,cn=zimbra" scope=0 deref=0 filter="(objectClass=*)" Oct 11 14:38:09 zre-ldap002 slapd[22940]: conn=1005 op=2 SEARCH RESULT tag=101 err=0 nentries=1 text= Oct 11 14:38:09 zre-ldap002 slapd[22940]: conn=1005 op=3 SRCH base="cn=config,cn=zimbra" scope=0 deref=0 filter="(objectClass=*)" Oct 11 14:38:09 zre-ldap002 slapd[22940]: conn=1005 op=3 SEARCH RESULT tag=101 err=0 nentries=1 text= Oct 11 14:38:10 zre-ldap002 slapd[22940]: conn=1005 op=4 MOD dn="cn=zre-ldap002.eng.vmware.com,cn=servers,cn=zimbra" Oct 11 14:38:10 zre-ldap002 slapd[22940]: conn=1005 op=4 MOD attr=zimbraMtaSmtpdMilters Oct 11 14:38:10 zre-ldap002 slapd[22940]: slap_queue_csn: queing 0x7f88c17fd1a0 20121011213810.017749Z#000000#000#000000 Oct 11 14:38:10 zre-ldap002 slapd[22940]: conn=1005 op=4: attribute "entryCSN" index delete failure Oct 11 14:38:10 zre-ldap002 slapd[22940]: conn=1005 op=4 RESULT tag=103 err=80 text= Oct 11 14:38:10 zre-ldap002 slapd[22940]: slap_graduate_commit_csn: removing 0x41d5110 20121011213810.017749Z#000000#000#000000 Oct 11 14:38:10 zre-ldap002 slapd[22940]: conn=1005 fd=11 closed (connection lost)

10 years, 11 months

1
0
0 / 0

Re: (ITS#7415) Add MALLOC_CHECK_ and MALLOC_PERTURB_ libc env to the test suite for detecting heap corruption

by h.b.furuseth＠usit.uio.no

We can describe these and other variables in tests/README. Yeah I know, people don't read documentation. The testing announcements could mention the file though.

10 years, 11 months

1
0
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs October 2012