- openldap-bugs - openldap.org

Re: (ITS#7332) Patch to build using Microsoft Visual Studio
by hyc＠symas.com 23 Jul '12

23 Jul '12

Thanks for the patch, applied to git master. mbooth(a)apache.org wrote: > Full_Name: Mat Booth > Version: 2.4.31 > OS: Windows XP > URL: http://people.apache.org/~mbooth/0001-Changes-required-to-build-with-Micros… > Submission from: (NULL) (77.86.30.139) > > > The provided patch makes three changes that were necessary for me to build > liblber and libldap on Windows using Microsoft Visual Studio. > > > * include/ac/socket.h > The type socklen_t is defined in ws2tcpip.h on the Windows platform, so include > this header when including winsock2.h > > * libraries/libldap/ldap-int.h > The struct timeval is defined in winsock.h or winsock2.h on the Windows platform > so include ac/socket.h when _WIN32 is defined (The comment in winsock2.h > literary says "taken from the BSD file sys/time.h") > > * libraries/libldap/util-int.c > The error code EAI_SYSTEM is not defined at all on the Windows platform, so only > use it if it's defined. > > > > The attached patch file is derived from OpenLDAP Software. All of the > modifications to OpenLDAP Software represented in the following patch(es) were > developed by Mat Booth <mbooth(a)apache.org>. I have not assigned rights and/or > interest in this work to any party. > > I, Mat Booth, hereby place the following modifications to OpenLDAP Software (and > only these modifications) into the public domain. Hence, these modifications may > be freely used and/or redistributed for any purpose with or without attribution > and/or other notice. > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#7332) Patch to build using Microsoft Visual Studio
by mbooth＠apache.org 23 Jul '12

23 Jul '12

Full_Name: Mat Booth Version: 2.4.31 OS: Windows XP URL: http://people.apache.org/~mbooth/0001-Changes-required-to-build-with-Micros… Submission from: (NULL) (77.86.30.139) The provided patch makes three changes that were necessary for me to build liblber and libldap on Windows using Microsoft Visual Studio. * include/ac/socket.h The type socklen_t is defined in ws2tcpip.h on the Windows platform, so include this header when including winsock2.h * libraries/libldap/ldap-int.h The struct timeval is defined in winsock.h or winsock2.h on the Windows platform so include ac/socket.h when _WIN32 is defined (The comment in winsock2.h literary says "taken from the BSD file sys/time.h") * libraries/libldap/util-int.c The error code EAI_SYSTEM is not defined at all on the Windows platform, so only use it if it's defined. The attached patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Mat Booth <mbooth(a)apache.org>. I have not assigned rights and/or interest in this work to any party. I, Mat Booth, hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

Re: (ITS#7331) [PATCH] MozNSS: ignore untrusted issuer error when verifying server certificate
by jvcelak＠redhat.com 21 Jul '12

21 Jul '12

I forgot to add: The patch deals only with a local certificate validation. It does not have any effect on a remote peer's certificate verification.

1 0

(ITS#7331) [PATCH] MozNSS: ignore untrusted issuer error when verifying server certificate
by jvcelak＠redhat.com 21 Jul '12

21 Jul '12

Full_Name: Jan Vcelak Version: git master OS: Linux URL: ftp://ftp.openldap.org/incoming/jvcelak-20120721-moznss-ignore-untrusted-is… Submission from: (NULL) (193.165.79.10) If a self-issued certificate in PEM format is used as a server certificate, the TLS context initialization can fail with SEC_ERROR_UNTRUSTED_ISSUER error. Unfortunately we cannot set trust flags of the server certificate loaded by MozNSS PEM module. This patch allows to ignore this error code. The attached file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Red Hat. Red Hat has not assigned rights and/or interest in this work to any party. I, Jan Vcelak am authorized by Red Hat, my employer, to release this work under the following terms. Red Hat hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

Re: (ITS#7330) slapd mmr failure due to tls cert name mismatch
by openldap＠stormcloud9.net 21 Jul '12

21 Jul '12

I've come up with a few more critical details while trying to solve the issue. 1) If the other master is started first, when the local slapd starts, syncrepl connects and works fine. It only fails if the other master is started after the local slapd is running. 2) If I delete the specific olcSyncrepl attribute for one that is failing, and then add it back, syncrepl starts working fine. 3) After deleting and re-adding the olcSyncrepl attribute to make syncrepl work, if I stop and start the other master slapd, syncrepl starts failing again.

1 0

(ITS#7330) slapd mmr failure due to tls cert name mismatch
by openldap＠stormcloud9.net 21 Jul '12

21 Jul '12

Full_Name: Patrick Hemmer Version: 2.4.31 OS: RHEL 6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (74.238.31.70) I have 2 servers (version 2.4.31) in multi-master-replication behind a single IP. Whenever replication tries to start, it fails because the cert name does not match the hostname. ---- TLS: hostname (per5-unity-ldap02.mbox.net) does not match common name in certificate (unity-ldap.mbox.net). 5009c52e slap_client_connect: URI=ldap://per5-unity-ldap02.mbox.net Error, ldap_start_tls failed (-11) 5009c52e do_syncrepl: rid=523 rc -11 retrying (5 retries left) ---- However in the slapd configuration, I have the olcSyncrepl tls_reqcert parameter set to 'never' ---- dn: olcDatabase={3}hdb,cn=config olcSyncrepl: {0}rid=513 provider="ldap://per5-unity-ldap01.mbox.net" network-timeout=2 retry="1 10 10 60 60 +" keepalive="60:3:60" starttls=critical tls_reqcert=never bindmethod=simple timeout=2 binddn="uid=foo,cn=bar" credentials="baz" type=refreshAndPersist searchbase="dc=my,dc=domain" olcSyncrepl: {1}rid=523 provider="ldap://per5-unity-ldap02.mbox.net" network-timeout=2 retry="1 10 10 60 60 +" keepalive="60:3:60" starttls=critical tls_reqcert=never bindmethod=simple timeout=2 binddn="uid=foo,cn=bar" credentials="baz" type=refreshAndPersist searchbase="dc=my,dc=domain" ---- I have also tried tls_reqcert=allow with the same result. And in a desperate attempt, I also tried setting tls_cacert=/dev/null in the hope that if it couldn't verify the cert it wouldnt check the hostname against the cert subject, but this failed as well.

1 0

(ITS#7329) Bottleneck adding a single value to indexed multi-valued attribute
by mhardin＠symas.com 20 Jul '12

20 Jul '12

Full_Name: Matthew Hardin Version: 2.4.31 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (69.43.206.100) Opening at Howard Chu's request: When adding a single value to a multi-valued attribute that is indexed, slapd re-adds index entries for every value in the attribute. This is a bottleneck and the code to do this (per Howard) should be reworked.

1 0

(ITS#7328) slapcat fails silently with back-hdb/bdb
by quanah＠OpenLDAP.org 19 Jul '12

19 Jul '12

Full_Name: Quanah Gibson-Mount Version: 2.4 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.108.184.39) As reported in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=673038, putting slapcat into a loop shows that it periodically fails to correctly dump an active database in full. We have also seen this at customer sites, when nightly backups are run. At the least, slapcat should return an error, so that failure can be caught and a new slapcat run.

1 0

(ITS#7327) [PATCH] smbk5pwd: error if crypto backend unsupported
by jvcelak＠redhat.com 19 Jul '12

19 Jul '12

Full_Name: Jan Vcelak Version: git master OS: Linux URL: ftp://ftp.openldap.org/incoming/jvcelak-20120719-smbk5pwd-error-if-crypto-b… Submission from: (NULL) (209.132.186.34) smbk5pwd overlay source code does not expect crypto backend other than OpenSSL or GnuTLS. When OpenLDAP si compiled with Mozilla NSS, Samba password hashes are not computed and the overlay returns uninitialized memory as the hash. This simple patch does not allow the smbk5pwd overlay to be compiled without OpenSSL or GnuTLS. Unfortunately we cannot add support for MozNSS, because MozNSS does not (and will not) implement MD4. The attached file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Red Hat. Red Hat has not assigned rights and/or interest in this work to any party. I, Jan Vcelak am authorized by Red Hat, my employer, to release this work under the following terms. Red Hat hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

Re: (ITS#7325) Panic issue with slapd-perl
by aescanero＠gmail.com 19 Jul '12

19 Jul '12

If I reverse the commit f6b8103b789ae40234b0cb7574c1a9da4e5a1b21 only in add.c then the module runs perfecty. Thanks. 2012/7/19 Alejandro <aescanero(a)gmail.com>: > More information: > Test Module is: > package replicadorTEST; > > use strict; > use warnings; > use POSIX; > > sub new { > my $class = shift; > > my $this = {}; > bless $this, $class; > return $this; > } > > sub bind { > return 0; > } > > sub init { > return 0; > } > > sub search { > return 0; > } > > sub compare { > return 0; > } > > sub modify { > return 0; > } > > sub add { > return 0; > > } > > sub modrdn { > return 0; > } > > sub delete { > return 0; > } > > sub config { > return 0; > } > > 1; > > Try to add this (The problem only appear when try to add a DN): > dn: uid=test,o=XXXX,o=XXXX,c=XX > mailLocalAddress: test(a)test.es > objectClass: top > objectClass: person > objectClass: organizationalPerson > objectClass: inetOrgPerson > objectClass: inetLocalMailRecipient > objectClass: posixAccount > uid: test > mail: test(a)test.es > uidNumber: 600 > o: ceic > gidNumber: 600 > displayName: TEST > sn: TEST > cn: TEST > homeDirectory: /home/test > > And then I get: > 5007ee79 >>> dnPrettyNormal: <uid=test,o=XXXX,o=XXXX,c=XX> > => ldap_bv2dn(uid=test,o=XXXX,o=XXXX,c=XX,0) > <= ldap_bv2dn(uid=test,o=XXXX,o=XXXX,c=XX)=0 > => ldap_dn2bv(272) > <= ldap_dn2bv(uid=test,o=XXXX,o=XXXX,c=XX)=0 > => ldap_dn2bv(272) > <= ldap_dn2bv(uid=test,o=XXXX,o=XXXX,c=XX)=0 > 5007ee79 <<< dnPrettyNormal: <uid=test,o=XXXX,o=XXXX,c=XX>, > <uid=test,o=XXXX,o=XXXX,c=XX> > 5007ee79 conn=1000 op=1 ADD dn="uid=test,o=XXXX,o=XXXX,c=XX" > panic: sv_setpvn called with negative strlen. > > Thanks > > 2012/7/19 Alejandro <aescanero(a)gmail.com>: >> My main problem now is: >> How I can check the bad line of code if perl-slapd don't give me any >> usable error in 2.4.31 release? >> >> Thanks >> >> 2012/7/19 Howard Chu <hyc(a)symas.com>: >>> aescanero(a)gmail.com wrote: >>>> The problem was in the perl module with a uninitialized value, in >>>> 2.4.21 give the error Use of uninitialized value in concatenation (.) >>>> or string at /etc/openldap24/replicador.pm line 109, <DATA> line 275 >>>> but in 2.4.31 give me a panic. >>> >>> Sounds like a bug in your module then, and not an OpenLDAP software issue. >>> >>> -- >>> -- Howard Chu >>> CTO, Symas Corp. http://www.symas.com >>> Director, Highland Sun http://highlandsun.com/hyc/ >>> Chief Architect, OpenLDAP http://www.openldap.org/project/ >> >> >> >> -- >> Alejandro Escanero Blanco >> Consultor de sistemas basados en fuentes abiertas >> Desarrollador de FusionDirectory (http://www.fusiondirectory.org) >> Blog: http://www.disasterproject.com >> Jabber: blainett(a)jabberes.com > > > > -- > Alejandro Escanero Blanco > Consultor de sistemas basados en fuentes abiertas > Desarrollador de FusionDirectory (http://www.fusiondirectory.org) > Blog: http://www.disasterproject.com > Jabber: blainett(a)jabberes.com -- Alejandro Escanero Blanco Consultor de sistemas basados en fuentes abiertas Desarrollador de FusionDirectory (http://www.fusiondirectory.org) Blog: http://www.disasterproject.com Jabber: blainett(a)jabberes.com

1 0

Re: (ITS#7325) Panic issue with slapd-perl
by aescanero＠gmail.com 19 Jul '12

19 Jul '12

More information: Test Module is: package replicadorTEST; use strict; use warnings; use POSIX; sub new { my $class = shift; my $this = {}; bless $this, $class; return $this; } sub bind { return 0; } sub init { return 0; } sub search { return 0; } sub compare { return 0; } sub modify { return 0; } sub add { return 0; } sub modrdn { return 0; } sub delete { return 0; } sub config { return 0; } 1; Try to add this (The problem only appear when try to add a DN): dn: uid=test,o=XXXX,o=XXXX,c=XX mailLocalAddress: test(a)test.es objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: inetLocalMailRecipient objectClass: posixAccount uid: test mail: test(a)test.es uidNumber: 600 o: ceic gidNumber: 600 displayName: TEST sn: TEST cn: TEST homeDirectory: /home/test And then I get: 5007ee79 >>> dnPrettyNormal: <uid=test,o=XXXX,o=XXXX,c=XX> => ldap_bv2dn(uid=test,o=XXXX,o=XXXX,c=XX,0) <= ldap_bv2dn(uid=test,o=XXXX,o=XXXX,c=XX)=0 => ldap_dn2bv(272) <= ldap_dn2bv(uid=test,o=XXXX,o=XXXX,c=XX)=0 => ldap_dn2bv(272) <= ldap_dn2bv(uid=test,o=XXXX,o=XXXX,c=XX)=0 5007ee79 <<< dnPrettyNormal: <uid=test,o=XXXX,o=XXXX,c=XX>, <uid=test,o=XXXX,o=XXXX,c=XX> 5007ee79 conn=1000 op=1 ADD dn="uid=test,o=XXXX,o=XXXX,c=XX" panic: sv_setpvn called with negative strlen. Thanks 2012/7/19 Alejandro <aescanero(a)gmail.com>: > My main problem now is: > How I can check the bad line of code if perl-slapd don't give me any > usable error in 2.4.31 release? > > Thanks > > 2012/7/19 Howard Chu <hyc(a)symas.com>: >> aescanero(a)gmail.com wrote: >>> The problem was in the perl module with a uninitialized value, in >>> 2.4.21 give the error Use of uninitialized value in concatenation (.) >>> or string at /etc/openldap24/replicador.pm line 109, <DATA> line 275 >>> but in 2.4.31 give me a panic. >> >> Sounds like a bug in your module then, and not an OpenLDAP software issue. >> >> -- >> -- Howard Chu >> CTO, Symas Corp. http://www.symas.com >> Director, Highland Sun http://highlandsun.com/hyc/ >> Chief Architect, OpenLDAP http://www.openldap.org/project/ > > > > -- > Alejandro Escanero Blanco > Consultor de sistemas basados en fuentes abiertas > Desarrollador de FusionDirectory (http://www.fusiondirectory.org) > Blog: http://www.disasterproject.com > Jabber: blainett(a)jabberes.com -- Alejandro Escanero Blanco Consultor de sistemas basados en fuentes abiertas Desarrollador de FusionDirectory (http://www.fusiondirectory.org) Blog: http://www.disasterproject.com Jabber: blainett(a)jabberes.com

1 0

Re: (ITS#7325) Panic issue with slapd-perl
by aescanero＠gmail.com 19 Jul '12

19 Jul '12

My main problem now is: How I can check the bad line of code if perl-slapd don't give me any usable error in 2.4.31 release? Thanks 2012/7/19 Howard Chu <hyc(a)symas.com>: > aescanero(a)gmail.com wrote: >> The problem was in the perl module with a uninitialized value, in >> 2.4.21 give the error Use of uninitialized value in concatenation (.) >> or string at /etc/openldap24/replicador.pm line 109, <DATA> line 275 >> but in 2.4.31 give me a panic. > > Sounds like a bug in your module then, and not an OpenLDAP software issue. > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ -- Alejandro Escanero Blanco Consultor de sistemas basados en fuentes abiertas Desarrollador de FusionDirectory (http://www.fusiondirectory.org) Blog: http://www.disasterproject.com Jabber: blainett(a)jabberes.com

1 0

Re: (ITS#7325) Panic issue with slapd-perl
by hyc＠symas.com 19 Jul '12

19 Jul '12

aescanero(a)gmail.com wrote: > The problem was in the perl module with a uninitialized value, in > 2.4.21 give the error Use of uninitialized value in concatenation (.) > or string at /etc/openldap24/replicador.pm line 109, <DATA> line 275 > but in 2.4.31 give me a panic. Sounds like a bug in your module then, and not an OpenLDAP software issue. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#7326) [PATCH] use AI_ADDRCONFIG if defined in the environment
by jvcelak＠redhat.com 19 Jul '12

19 Jul '12

Full_Name: Jan Vcelak Version: git master OS: Linux URL: ftp://ftp.openldap.org/incoming/jvcelak-20120719-use-ai-addrconfig-if-defin… Submission from: (NULL) (209.132.186.34) Use AI_ADDRCONFIG flag with getaddrinfo() if the symbol is defined. I think that no configure macro is needed for this. The symbol should be present on the systems which support it. And I believe we can enforce this flag if available. The attached file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Red Hat. Red Hat has not assigned rights and/or interest in this work to any party. I, Jan Vcelak am authorized by Red Hat, my employer, to release this work under the following terms. Red Hat hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

Re: (ITS#7325) Panic issue with slapd-perl
by hyc＠symas.com 19 Jul '12

19 Jul '12

aescanero(a)gmail.com wrote: > Full_Name: Alejandro Escanero Blanco > Version: 2.4.31 > OS: RHEL 5.1 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (217.12.24.133) > > > After upgrade Openldap 2.4.21 to 2.4.31 the slapd-perl fail to run add function > in the perl module with this error: > panic: sv_setpvn called with negative strlen, <DATA> line 275 > > Back to 2.4.21 and perl module is running ok. > > A fix is now in git master, please test and report back. Revision 348d43e. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#7325) Panic issue with slapd-perl
by aescanero＠gmail.com 19 Jul '12

19 Jul '12

The problem was in the perl module with a uninitialized value, in 2.4.21 give the error Use of uninitialized value in concatenation (.) or string at /etc/openldap24/replicador.pm line 109, <DATA> line 275 but in 2.4.31 give me a panic. -- Alejandro Escanero Blanco Consultor de sistemas basados en fuentes abiertas Desarrollador de FusionDirectory (http://www.fusiondirectory.org) Blog: http://www.disasterproject.com Jabber: blainett(a)jabberes.com

1 0

(ITS#7325) Panic issue with slapd-perl
by aescanero＠gmail.com 19 Jul '12

19 Jul '12

Full_Name: Alejandro Escanero Blanco Version: 2.4.31 OS: RHEL 5.1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (217.12.24.133) After upgrade Openldap 2.4.21 to 2.4.31 the slapd-perl fail to run add function in the perl module with this error: panic: sv_setpvn called with negative strlen, <DATA> line 275 Back to 2.4.21 and perl module is running ok.

1 0

(ITS#7324) [PATCH] autoconf: use pkg-config to detect Mozilla NSS library
by jvcelak＠redhat.com 18 Jul '12

18 Jul '12

Full_Name: Jan Vcelak Version: git master OS: Linux URL: ftp://ftp.openldap.org/incoming/jvcelak-20120718-configure-use-pkg-config-f… Submission from: (NULL) (209.132.186.34) Hello, this patch is just a proposal. It enables pkg-config to detect correct compilation flags for Mozilla NSS crypto backend. I believe this should be adapted also for other dependencies (which support it) instead of hardcoding the flags into the configure script. We might get rid of problems caused by differences between the individual environments (and distributions in case of Linux). Jan The attached file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Red Hat. Red Hat has not assigned rights and/or interest in this work to any party. I, Jan Vcelak am authorized by Red Hat, my employer, to release this work under the following terms. Red Hat hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

Re: (ITS#7172) SEGFAULT in openldap-2.4.28 & 2.4.29
by david.coutadeur＠linagora.com 18 Jul '12

18 Jul '12

Hi, I had some difficulties to reproduce it, but I have finally succeeded : [Switching to Thread 0x431e4940 (LWP 11061)] 0x000000000054211c in sp_avl_cmp (c1=<value optimized out>, c2=0xbfb5a60) at syncprov.c:378 378 rc = m1->mt_op->o_req_ndn.bv_len - m2->mt_op->o_req_ndn.bv_len; Thank you for the help, David Coutadeur Le 17/07/2012 19:59, Quanah Gibson-Mount a écrit : > --On Tuesday, July 17, 2012 7:47 AM +0000 david.coutadeur(a)linagora.com > wrote: > >> >> Hi everybody, >> >> Does anybody have some news about this ticket ? Is it still valid, or >> maybe is it already solved as a side effect ? >> >> Thanks for any reply, > > Can you reproduce it with current RE24 code from git? > > --Quanah > > -- > > Quanah Gibson-Mount > Sr. Member of Technical Staff > Zimbra, Inc > A Division of VMware, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6339) ldapsearch -V doesn't exist after version info
by Gavin Henry 18 Jul '12

18 Jul '12

Do we want to document this or change behavior?

1 0

Re: (ITS#7172) SEGFAULT in openldap-2.4.28 & 2.4.29
by quanah＠zimbra.com 17 Jul '12

17 Jul '12

--On Tuesday, July 17, 2012 7:47 AM +0000 david.coutadeur(a)linagora.com wrote: > > Hi everybody, > > Does anybody have some news about this ticket ? Is it still valid, or > maybe is it already solved as a side effect ? > > Thanks for any reply, Can you reproduce it with current RE24 code from git? --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7172) SEGFAULT in openldap-2.4.28 & 2.4.29
by david.coutadeur＠linagora.com 17 Jul '12

17 Jul '12

Hi everybody, Does anybody have some news about this ticket ? Is it still valid, or maybe is it already solved as a side effect ? Thanks for any reply, D.C. Le 16/03/2012 19:40, David Coutadeur a écrit : > > Hi, > > I finally had the opportunity to get a valgrind analysis of my problem. > You can find it below. Thank you for any help. > > D. > > > > ==19496== 12 bytes in 1 blocks are definitely lost in loss record 16 of 52 > ==19496== at 0x4005B83: malloc (vg_replace_malloc.c:195) > ==19496== by 0x4056977: ber_memalloc_x (memory.c:228) > ==19496== by 0x8095D39: ch_malloc (ch_malloc.c:54) > ==19496== by 0x80E0297: do_syncrepl (syncrepl.c:706) > ==19496== by 0x4016A23: ldap_int_thread_pool_wrapper (tpool.c:688) > ==19496== by 0x821831: start_thread (in /lib/libpthread-2.5.so) > ==19496== by 0x76146D: clone (in /lib/libc-2.5.so) > ==19496== > ==19496== 155 (32 direct, 123 indirect) bytes in 1 blocks are definitely > lost in loss record 47 of 52 > ==19496== at 0x4005B83: malloc (vg_replace_malloc.c:195) > ==19496== by 0x4056977: ber_memalloc_x (memory.c:228) > ==19496== by 0x4057054: ber_bvarray_dup_x (memory.c:756) > ==19496== by 0x80E0212: do_syncrepl (syncrepl.c:699) > ==19496== by 0x4016A23: ldap_int_thread_pool_wrapper (tpool.c:688) > ==19496== by 0x821831: start_thread (in /lib/libpthread-2.5.so) > ==19496== by 0x76146D: clone (in /lib/libc-2.5.so) > ==19496== > ==19496== 270 (228 direct, 42 indirect) bytes in 3 blocks are definitely > lost in loss record 49 of 52 > ==19496== at 0x4005B83: malloc (vg_replace_malloc.c:195) > ==19496== by 0x4056977: ber_memalloc_x (memory.c:228) > ==19496== by 0x8095D39: ch_malloc (ch_malloc.c:54) > ==19496== by 0x8195E91: syncprov_op_search (syncprov.c:2473) > ==19496== by 0x80E3333: overlay_op_walk (backover.c:661) > ==19496== by 0x80E3A09: over_op_func (backover.c:723) > ==19496== by 0x807BE85: fe_op_search (search.c:402) > ==19496== by 0x807C772: do_search (search.c:247) > ==19496== by 0x807988B: connection_operation (connection.c:1150) > ==19496== by 0x807A0FC: connection_read_thread (connection.c:1286) > ==19496== by 0x4016A23: ldap_int_thread_pool_wrapper (tpool.c:688) > ==19496== by 0x821831: start_thread (in /lib/libpthread-2.5.so) > > > > > > Le 20/02/2012 10:32, David Coutadeur a écrit : >> >> Hi, >> >> Concerning the cpu : >> model name : Intel(R) Xeon(R) CPU L5640 @ 2.27GHz >> However, OpenLDAP is used in a virtual machine, with only one dedicated >> core. This is 32 bits version of OpenLDAP, on a 32 bits OS. >> Linux OS : >> Red Hat Enterprise Linux Server release 5.7 (Tikanga) >> kernel : >> 2 2.6.18-274.3.1.el5 >> >> You can get the server configuration below. >> >> Concerning the client, you can find the source code here : >> http://loadtesting.sourceforge.net/index.php?lang=en >> >> >> >> # >> ---------------------------------------------------------------------------- >> # Global section >> # >> ---------------------------------------------------------------------------- >> >> sizelimit 15000 >> >> allow bind_v2 >> password-hash {SSHA} >> threads 8 >> loglevel 256 >> >> serverID 2 >> >> include /opt/openldap/etc/openldap/inc_shemas/slapd-schemas.conf >> >> pidfile /opt/openldap/var/run/slapd.pid >> argsfile /opt/openldap/var/run/slapd.args >> >> # ACLs definition (cutted here) >> >> ####################################################################### >> # SSL definitions >> ####################################################################### >> # Definition of cert files >> # --------------------------------- >> TLSCipherSuite HIGH:MEDIUM:+SSLv2 >> >> TLSCACertificateFile /usr/local/openldap/etc/certs/ca.cert >> TLSCertificateFile /usr/local/openldap/etc/certs/ldap-master-2.cert >> TLSCertificateKeyFile /usr/local/openldap/etc/certs/ldap-master-2.key >> >> TLSVerifyClient never >> >> >> >> ####################################################################### >> # BDB database definitions >> ####################################################################### >> database monitor >> >> ####################################################################### >> # suffix dc=example,dc=com >> # -------------------- >> ####################################################################### >> database bdb >> directory /opt/openldap/var/openldap-data >> # some indexes >> >> # >> ---------------------------------------------------------------------------- >> # root suffix >> # >> ---------------------------------------------------------------------------- >> suffix "dc=example,dc=com" >> checkpoint 512 10 >> >> # >> ---------------------------------------------------------------------------- >> # cache settings >> # >> ---------------------------------------------------------------------------- >> >> cachesize 60000 >> dncachesize 60000 >> idlcachesize 60000 >> cachefree 100 >> >> rootdn "cn=Manager,dc=example,dc=com" >> rootpw secret >> >> # Password policy : hash the clear passwords >> overlay ppolicy >> ppolicy_hash_cleartext >> >> >> # >> ---------------------------------------------------------------------------- >> # REPLICATION definitions >> # >> ---------------------------------------------------------------------------- >> ####################################################################### >> >> # I am a master (provider) >> # ------------------------------------------ >> overlay syncprov >> syncprov-checkpoint 100 10 >> syncprov-sessionlog 100 >> >> # syncrepl directive (consummer infos) >> # ------------------------------------------ >> syncrepl rid=001 >> provider=ldap://ldap-master-1.example.com >> bindmethod=simple >> binddn="uid=ReplicationMaster,ou=Replication,ou=Special >> Users,dc=example,dc=com" >> credentials=secret >> searchbase="dc=example,dc=com" >> schemachecking=on >> type=refreshAndPersist >> retry="60 +" >> >> mirrormode on >> >> >> # >> ---------------------------------------------------------------------------- >> # limits >> # >> ---------------------------------------------------------------------------- >> >> limits dn.exact="uid=ReplicationMaster,ou=Replication,ou=Special >> Users,dc=example,dc=com" size=unlimited time=unlimited >> limits dn.exact="uid=ReplicationHub,ou=Replication,ou=Special >> Users,dc=example,dc=com" size=unlimited time=unlimited >> limits dn.exact="uid=ReplicationLSC,ou=Replication,ou=Special >> Users,dc=example,dc=com" size=unlimited time=unlimited >> >> >> ####################################################################### >> # suffix o=edition >> # ---------------- >> ####################################################################### >> database bdb >> >> directory /opt/openldap/var/openldap-data-edition >> # some indexes >> >> >> # >> ---------------------------------------------------------------------------- >> # root suffix >> # >> ---------------------------------------------------------------------------- >> suffix "o=edition" >> checkpoint 512 10 >> >> # >> ---------------------------------------------------------------------------- >> # cache settings >> # >> ---------------------------------------------------------------------------- >> >> cachesize 50000 >> dncachesize 50000 >> idlcachesize 50000 >> cachefree 100 >> >> >> >> # >> ---------------------------------------------------------------------------- >> # rootdn >> # >> ---------------------------------------------------------------------------- >> # Cleartext passwords, especially for the rootdn, should >> # be avoid. See slappasswd(8) and slapd.conf(5) for details. >> # Use of strong authentication encouraged. >> rootdn "cn=Manager,o=edition" >> rootpw secret >> >> # Password policy : hash the clear passwords >> overlay ppolicy >> ppolicy_hash_cleartext >> >> >> ####################################################################### >> # REPLICATION definitions >> ####################################################################### >> >> # I am a master (provider) >> # ------------------------------------------ >> overlay syncprov >> syncprov-checkpoint 100 10 >> syncprov-sessionlog 100 >> >> # syncrepl directive (consummer infos) >> # ------------------------------------------ >> syncrepl rid=002 >> provider=ldap://vspar-ldap-master-1.example.com >> bindmethod=simple >> binddn="uid=ReplicationMaster,ou=Replication,ou=Special >> Users,dc=example,dc=com" >> credentials=secret >> searchbase="o=edition" >> schemachecking=on >> type=refreshAndPersist >> retry="60 +" >> >> mirrormode on >> >> # >> ---------------------------------------------------------------------------- >> # Limits for current BDB >> # >> ---------------------------------------------------------------------------- >> >> limits dn.exact="uid=ReplicationMaster,ou=Replication,ou=Special >> Users,dc=example,dc=com" size=unlimited time=unlimited >> limits dn.exact="uid=ReplicationHub,ou=Replication,ou=Special >> Users,dc=example,dc=com" size=unlimited time=unlimited >> limits dn.exact="uid=ReplicationLSC,ou=Replication,ou=Special >> Users,dc=example,dc=com" size=unlimited time=unlimited >> >> >> >> >> >> Le 17/02/2012 19:00, Howard Chu a écrit : >>> dcoutadeur(a)linagora.com wrote: >>>> Full_Name: dcoutadeur >>>> Version: 2.4.28 >>>> OS: Red Hat Enterprise Linux Server release 5.7 (Tikanga) >>>> URL: ftp://ftp.openldap.org/incoming/ >>>> Submission from: (NULL) (109.197.176.10) >>>> >>>> >>>> >>>> Hello, >>>> >>>> >>>> I had a segfault in the last git version of OpenLDAP, after 10 to 15 >>>> tests, each >>>> interrupted by Ctrl+C. (see what's a test below) >>>> The segfault is also reproduced in version 2.4.28. >>>> >>>> I think I won't be able to reproduce the bug with Valgrind. >>> >>> If you expect us to try to reproduce the bug, you'll have to provide >>> more information. Since this crash is in syncprov there's obviously at >>> least two servers involved; what are their configurations? What hardware >>> are they running on (in particular, how many CPU cores per server)? >>> Since you're using a custom client, can you provide the client source code? >>>> >>>> Thank you in advance for any help. >>>> >>>> D. >>>> >>>> >>>> Note : A test is 100 times 100 threads, each doing a bind, an add, a >>>> modify, a >>>> delete, and a logout. >>>> >>>> >>>> >>>> >>>> >>>> (gdb) bt full >>>> #0 sp_avl_cmp (c1=0x8b4004c8, c2=0xa37cf28) at syncprov.c:366 >>>> rc =<value optimized out> >>>> #1 0x081afe3e in avl_delete (root=0xa255648, data=0x8b4004c8, >>>> fcmp=0x81948a0<sp_avl_cmp>) at avl.c:197 >>>> p =<value optimized out> >>>> q =<value optimized out> >>>> r =<value optimized out> >>>> top =<value optimized out> >>>> side =<value optimized out> >>>> side_bf =<value optimized out> >>>> shorter =<value optimized out> >>>> nside =<value optimized out> >>>> pptr = {0x89908, 0x0, 0x0, 0x0, 0xe8043c, 0x0, 0xfdc, >>>> 0x8d994858, 0xe7b95c, 0xfdc, 0xa372570, 0x0, 0xa288350, >>>> 0xe8043c, 0xa372570, 0x8d994878, 0xe7c324, 0xfdc, 0xa372570, >>>> 0x0, 0xe7af2c, 0x8cb9136e, 0x81b3634, 0x0, 0xe8043c, >>>> 0xe, 0xa3d3a40, 0x8d9948b8, 0xe7d081, 0xa3e3618, 0x8cb91358, >>>> 0x823c27} >>>> pdir = >>>> "\000\000\000\000lI\231\215\064\066\033\bn>\000\000\244\345t\000\310\004@\213\b\346\067\n\310H\231\215" >>>> >>>> depth = 0 >>>> #2 0x08199f7f in syncprov_op_cleanup (op=0xa37e608, rs=0x8d995108) at >>>> syncprov.c:1401 >>>> cb = 0x8cb91258 >>>> opc = 0x8cb91268 >>>> si = 0xa255610 >>>> sm = 0xa255688 >>>> snext =<value optimized out> >>>> mt = 0x8b4004c8 >>>> #3 0x08089654 in slap_cleanup_play (op=0xa37e608, rs=0x8d995108) at >>>> result.c:541 >>>> sc_next = 0x8d994dec >>>> sc = 0x8cb91258 >>>> scp = 0x8d994928 >>>> #4 0x0808a150 in send_ldap_response (op=0xa37e608, rs=0x8d995108) at >>>> result.c:733 >>>> berbuf = { >>>> buffer = "\000\000\001\000\000\001\000\000\377\377\377\377", >>>> '\000'<repeats 12 times>, >>>> "f\023\271\214\064#\271\214\000\000\000\000f\023\271\214p%7\n\000\000\000\000\314I\231\215\001\000\000\000\000\000\000\000\314mK\236x\271\347\000\001\000\000\000`+@\213D`K\236\230\063\066\n\250<6\n\000\000\000\000\000\000\000\000\005\000\000\000P7@\213`\343\070\n\000\000\000\000\n\000\000\000(\234\200\330\000\000\000\000\000\000\000\000@4\"\000\000\000\000\000(\234\200\330\210J\231\215\270\214 >>>> >>>> \000\230\063\066\n`+@\213\314mK\236\r\000\000\000\001\000\000\000\021\217;O(\234\200\330\000\000\000\000`&%\n`&%\n8J\231\215b\f\"\000\224mK\236\230\063\066\n(\234\200أ\347\022\b\a", >>>> >>>> '\000'<repeats 31 times>, "D'%\n\224mK\236\000\000\000", >>>> ialign = 65536, lalign = 65536, falign = 9.18354962e-41, >>>> dalign = 5.4323095486619588e-312, >>>> palign = 0x10000<Address 0x10000 out of bounds>} >>>> ber =<value optimized out> >>>> rc = 32768 >>>> bytes = 14 >>>> __PRETTY_FUNCTION__ = "send_ldap_response" >>>> #5 0x0808af1f in slap_send_ldap_result (op=0xa37e608, rs=0x8d995108) at >>>> result.c:860 >>>> tmp = 0x0 >>>> otext = 0x0 >>>> oref = 0x0 >>>> __PRETTY_FUNCTION__ = "slap_send_ldap_result" >>>> #6 0x0812bde5 in bdb_add (op=0xa37e608, rs=0x8d995108) at add.c:511 >>>> pdn = {bv_len = 23, bv_val = 0x8b40372f >>>> "ou=people,dc=afp,dc=com"} >>>> p = 0x8fc4c0fc >>>> oe = 0x8fc4c804 >>>> ei = 0xa37d1c8 >>>> textbuf = "\000\000\000\000\320O\"\n", '\000'<repeats 48 >>>> times>, "\001", '\000'<repeats 198 times> >>>> children = 0xa223b20 >>>> entry = 0xa223980 >>>> ltid = 0x0 >>>> lt2 = 0x8b402bf0 >>>> eid = 57976 >>>> opinfo = {boi_oe = {oe_next = {sle_next = 0x8d99509c}, oe_key = >>>> 0x0}, boi_txn = 0x8b402b60, boi_locks = 0x0, >>>> boi_err = 0, boi_acl_cache = 0 '\000', boi_flag = 0 '\000'} >>>> lock = {off = 133260, ndx = 772, gen = 2004, mode = >>>> DB_LOCK_READ} >>>> num_retries = 0 >>>> success = 0 >>>> postread_ctrl = 0x0 >>>> ctrls = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0} >>>> num_ctrls = 0 >>>> #7 0x080e33a1 in overlay_op_walk (op=0xa37e608, rs=0x8d995108, >>>> which=op_add, oi=0xa254ff0, on=0xa255508) at backover.c:671 >>>> rc = 32768 >>>> #8 0x080e3a0a in over_op_func (op=0xa37e608, rs=0x8d995108, >>>> which=op_add) at backover.c:723 >>>> oi = 0xa254ff0 >>>> on = 0xa255508 >>>> be = 0xa252560 >>>> db = {bd_info = 0x821d41c, bd_self = 0xa252560, >>>> be_ctrls = >>>> "\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001\001\000\000\000\000\001\000\001\000\000\000\000\000\000\000\000\000\001", >>>> >>>> be_flags = 563464, be_restrictops = 0, be_requires = 0, be_ssf_set = >>>> {sss_ssf = 0, >>>> sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf >>>> = 0, sss_update_transport = 0, sss_update_tls = 0, >>>> sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = >>>> 0xa288350, be_nsuffix = 0xa288368, be_schemadn = { >>>> bv_len = 0, bv_val = 0x0}, be_schemandn = {bv_len = 0, >>>> bv_val = 0x0}, be_rootdn = {bv_len = 24, >>>> bv_val = 0xa287648 "cn=Manager,dc=afp,dc=com"}, be_rootndn = >>>> {bv_len = 24, >>>> bv_val = 0xa2876d0 "cn=manager,dc=afp,dc=com"}, be_rootpw = >>>> {bv_len = 38, >>>> bv_val = 0xa2876f0 >>>> "{SSHA}rEmMhg3MU5xkQX5Ng92tH4WzGMlA+nGU"}, be_max_deref_depth = 15, >>>> be_def_limit = { >>>> lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 15000, >>>> lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, >>>> lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = >>>> 0xa255748, be_acl = 0x0, be_dfltaccess = ACL_READ, >>>> be_extra_anlist = 0x0, be_update_ndn = {bv_len = 0, bv_val = >>>> 0x0}, be_update_refs = 0x0, >>>> be_pending_csn_list = 0xa363388, be_pcl_mutex = {__data = >>>> {__lock = 0, __count = 0, __owner = 0, __kind = 0, >>>> __nusers = 0, {__spins = 0, __list = {__next = 0x0}}}, >>>> __size = '\000'<repeats 23 times>, __align = 0}, >>>> be_syncinfo = 0xa28aec8, be_pb = 0x0, be_cf_ocs = 0x821f840, >>>> be_private = 0xa252660, be_next = { >>>> stqe_next = 0xa288538}} >>>> cb = {sc_next = 0x0, sc_response = 0x80e30e0 >>>> <over_back_response>, sc_cleanup = 0, sc_private = 0xa254ff0} >>>> sc =<value optimized out> >>>> rc =<value optimized out> >>>> __PRETTY_FUNCTION__ = "over_op_func" >>>> #9 0x08081129 in fe_op_add (op=0xa37e608, rs=0x8d995108) at add.c:334 >>>> repl_user = 0 >>>> rc =<value optimized out> >>>> bd = 0x82234c0 >>>> textbuf = >>>> "\000\000\000\000\000\000\000\000\060[\231\215\000\000\000\000\035\000\000\000\020\070@\213\001\000\000\000xN\231\215\270\026@\213(I\"\n\002\000\000\000\250N\231\215\255\214\v\b\270\026@\213\224N\231\215\001\000\000\000\000\000\000\000x9@\213\000\000\000\000\n\000\000\000\001\000\000\000\340\067@\213\n\000\000\000\060\070@\213\320\026@\213(I\"\n\270\026@\213\370N\231\215oc\t\b\002\000\000\000X( >>>> >>>> \n\370N\231\215\321_\t\bh\234!\n\240\066@\213'<\202\000\000\000\000\000\f\000\000\000W.@\213n>\000\000\244\345t\000\320O\"\n\320O\"\n\370N\231\215\035\205q\000 >>>> >>>> .\"\b\314h\032\216\030O\231\215\245\063\b\b >>>> .\"\b\240\066@\213\000\000\000\000\270\026@\213\244i\032\216\000\000\000\000HO\231\215\267\r\b\b\320O\"\n\320O\"\n\001\000\000\000HO\231\215\020\000\000\000\340h\032\216\377\377\377\377" >>>> >>>> __PRETTY_FUNCTION__ = "fe_op_add" >>>> #10 0x08081a13 in do_add (op=0xa37e608, rs=0x8d995108) at add.c:194 >>>> ber =<value optimized out> >>>> last = 0x8b402e71 "" >>>> dn = {bv_len = 38, bv_val = 0x8b402d98 >>>> "uid=dcoutadeur,ou=People,dc=afp,dc=com"} >>>> len = 28 >>>> tag =<value optimized out> >>>> modlist = 0x8b4015f0 >>>> modtail = 0x8b403694 >>>> tmp = {sml_mod = {sm_desc = 0x80ce5ca, sm_values = 0x8b4036a0, >>>> sm_nvalues = 0x0, sm_numvals = 2375635128, >>>> sm_op = 0, sm_flags = 0, sm_type = {bv_len = 12, bv_val = >>>> 0x8b402e57 "userPassword"}}, sml_next = 0x823c27} >>>> textbuf = >>>> "\025\000\000\000\310\031@\213\b\026@\213\006\340(\000\220[\231\215\000\000\000\000\000\000\000\000\020\000@\213\025\000\000\000\310\031@\213\310+@\213\005\070/\000\200O@\213T\245(\000\000\000\000\000\020\000@\213\364\237\067\000\220[\231\215\000\000\000\000\233\071@\213@:=\n\370O\231\215T\213\202\000b\213\202\000;\334\347\000\"\000\000\000\233\071@\213\b\000\000\000\201\354(\000\fP\231\215<\004\350\000\270P\231\215\312\315\347\000\370\326\070\n\233\071@\213\b\000\000\000\001\200\255\373\b\347\067\n@\000\000\000\243P\231\215@\000@\213\026\347\067\n@\000@\213\b\347\067\n@\261\067\000,\000\000\000\020\000@\213", >>>> >>>> '\000'<repeats 20 times>, >>>> "5\000\000\000@\000@\213\000\000\000\000\340\021@\213\000\000\000\000\000\000\000\000\260+@\213\000\000\000\000\001\000\000\000\004\000\020\000\350Q\231\215\310P\231\215" >>>> >>>> rc =<value optimized out> >>>> freevals =<value optimized out> >>>> oex = {oe = {oe_next = {sle_next = 0x0}, oe_key = 0x8081330}, >>>> oe_db = 0x0} >>>> #11 0x0807988c in connection_operation (ctx=0x8d9951e8, arg_v=0xa37e608) >>>> at connection.c:1150 >>>> rc =<value optimized out> >>>> cancel =<value optimized out> >>>> rs = {sr_type = REP_RESULT, sr_tag = 105, sr_msgid = 2, sr_err = >>>> 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, >>>> sr_ctrls = 0x0, sr_un = {sru_search = {r_entry = 0x0, >>>> r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, >>>> r_nentries = 0, r_v2ref = 0x0}, sru_sasl = {r_sasldata = >>>> 0x0}, sru_extended = {r_rspoid = 0x0, >>>> r_rspdata = 0x0}}, sr_flags = 0} >>>> tag = 104 >>>> opidx = SLAP_OP_ADD >>>> conn = 0xb7f3bc10 >>>> memctx = 0xa372570 >>>> memctx_null = 0x0 >>>> __PRETTY_FUNCTION__ = "connection_operation" >>>> #12 0x0807a0fd in connection_read_thread (ctx=0x8d9951e8, argv=0x22) at >>>> connection.c:1286 >>>> s =<value optimized out> >>>> #13 0x00717a24 in ldap_int_thread_pool_wrapper (xpool=0xa2265c8) at >>>> tpool.c:688 >>>> task = 0xa382e10 >>>> work_list =<value optimized out> >>>> ctx = {ltu_id = 2375637904, ltu_key = {{ltk_key = 0x80ce400, >>>> ltk_data = 0xa372570, >>>> ltk_free = 0x80ce430<slap_sl_mem_destroy>}, {ltk_key = >>>> 0xa363398, ltk_data = 0xa371a88, >>>> ltk_free = 0x812e4c0<bdb_reader_free>}, {ltk_key = >>>> 0x8078320, ltk_data = 0xa37de68, >>>> ltk_free = 0x80783f0<conn_counter_destroy>}, {ltk_key = >>>> 0x808dde0, ltk_data = 0x0, >>>> ltk_free = 0x808dbf0<slap_op_q_destroy>}, {ltk_key = 0x0, >>>> ltk_data = 0x0, ltk_free = 0}<repeats 28 times>}} >>>> kctx =<value optimized out> >>>> keyslot = 241 >>>> hash = 5278961 >>>> __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" >>>> #14 0x00821832 in start_thread () from /lib/libpthread.so.0 >>>> No symbol table info available. >>>> #15 0x002f746e in clone () from /lib/libc.so.6 >>>> No symbol table info available. >>>> >>>> >>>> >>>> >>>> >>> >>> > -- David Coutadeur - intégrateur LinID Groupe LINAGORA - BU LGS +33 1 46 96 63 63 / poste 601 80 rue Roque de Fillol 92800 PUTEAUX "/La présente transmission contient des informations confidentielles appartenant à Linagora, exclusivement destinées au(x) destinataire(s) identifié(s) ci-dessus. Si vous n'en faites pas partie, toute reproduction, distribution ou divulgation de tout ou partie des informations de cette transmission, ou toute action effectuée sur la base de celles-ci vous sont formellement interdites. Si vous avez reçu cette transmission par erreur, nous vous remercions de nous en avertir et de la détruire de votre système d'information. The present transmission contains privileged and confidential information belonging to Linagora, exclusively intended for the recipient(s) thereabove identified. If you are not one of these aforementioned recipients, any reproduction, distribution, disclosure of said information in whole or in part, as well as any action undertaken on the basis of said information are strictly prohibited. If you received the present transmission by mistake, please inform us and destroy it from your messenging and information systems./"

1 0

Re: (ITS#7299) Memory leaks when using ldapmodify to add members to groupOfNames objectclass
by jsynacek＠redhat.com 12 Jul '12

12 Jul '12

On 06/18/2012 01:55 PM, hyc(a)symas.com wrote: > Jan Synacek wrote: >> On 06/15/2012 03:16 PM, hyc(a)symas.com wrote: >>> jsynacek(a)redhat.com wrote: >>>> Full_Name: Jan Synacek >>>> Version: git (c73ec15) >>>> OS: linux-fedora17 >>>> URL: http://jsynacek.fedorapeople.org/openldap/leak/openldap-mmr-leak.tar.gz >>>> Submission from: (NULL) (209.132.186.34) >>>> >>>> >>>> I'm using a 2-node mmr setup on my local machine - configuration files and >>>> 'uploader' scripts are provided in the archive. >>>> >>>> 1) I have the two nodes running. >>>> 2) Execute run.sh (only a wrapper for ldapusradm.sh) and start monitoring >>>> slapd's memory usage. >>>> 3) After some time (at about 2k users on my system), slapd consumes a large >>>> amount of memory which is still growing >>>> >>>> Note that not using ldapmodify to add members to 'cn=users,dc=yes,dc=my', but >>>> using it e.g. for modifying each user's email, does NOT result in any memory >>>> leakage. >>>> >>>> I have also created a massif output using valgrind's massif tool: >>>> http://jsynacek.fedorapeople.org/openldap/leak/massif.out.17906 >>>> >>>> I found a very similar bug (#7292), but I'm not sure if it's related. >>> >>> Running RE24 with valgrind --leak-check=full I see no leak when running your >>> test. That should be the same as git c73ec15. No idea what leak you're seeing. >>> >> >> The memory consumption still grows and slapd eventually gets killed by oom-killer. > > Perhaps you're seeing fragmentation in the glibc malloc library. Please test > RE24, and try with some other malloc (e.g. tcmalloc). I've run your entire > test with both valgrind and with tcmalloc's heap checker and neither one shows > any leak. > I've done more tests and have some additional observations to add: * tcmalloc doesn't make any difference * if syncing finishes, memory usage drops considerably * putting sleep between ldapadd and ldapmodify in the script seems to stop the memory consumption * also, generating one big ldif, that is used modify all the users in groupOfNames just once (calling ldapmodify only once that is, not calling it once for every user), seems to help as well; the ldif is formatted like so: dn: cn=users,dc=yes,dc=my changetype:modify add: member member: uid=test-1(a)yes1.my,dc=yes,dc=my - add: member member: uid=test-2(a)yes1.my,dc=yes,dc=my - ... I'm also including my configure setup: export CFLAGS="$(rpm --eval %{optflags}) -O2 -fPIC -D_REENTRANT -DHAVE_TLS -DHAVE_MOZNSS" export LIBS="-lpthread -lssl3 -lsmime3 -lnss3 -lnssutil3 -lplds4 -lplc4 -lnspr4" CFLAGS="${CFLAGS:--g -pipe -Wall }"; export CFLAGS; CXXFLAGS="${CXXFLAGS:--g -pipe -Wall }"; export CXXFLAGS; FFLAGS="${FFLAGS:--g -pipe -Wall }"; export FFLAGS; ./configure \ --with-threads=posix --disable-static --with-tls=no \ --with-pic --with-cyrus-sasl \ --enable-bdb \ --enable-overlays --enable-slapd --enable-spasswd --enable-modules --enable-slapi \ --enable-accesslog \ --enable-wrappers -- Jan Synacek Software Engineer, BaseOS team Brno, Red Hat

1 0

(ITS#7323) back-mdb online indexer memory leak
by hyc＠OpenLDAP.org 12 Jul '12

12 Jul '12

Full_Name: Howard Chu Version: HEAD/RE24 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (78.226.5.35) Submitted by: hyc The online indexer doesn't free entries that it has reindexed. A patch is coming.

1 0

ITS#6262 regression
by hyc＠symas.com 11 Jul '12

11 Jul '12

While running valgrind --tool=helgrind on test008 I saw some data races that were quite unexpected, in ldap_pvt_gettime(). These functions are supposed to detect duplicate timestamps being returned, as noted in git rev 6cbf65642a9d094feddf820b206c1a3af70d5fd9 . This detection relies on static variables, and as such their invocations must be mutex-protected, as noted in the function comments (added immediately after, in ee2001ea4b26b0957040ca0753a94f26f78e6147). Unfortunately in f3cdcadf89474e7267d9f8f17d2bac46551b2131 the necessary mutex was removed. This means on multi-processor machines it's possible for us to generate non-unique CSNs. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs