- openldap-bugs - openldap.org

Re: (ITS#5679) Translucent search
by ando＠sys-net.it 08 Sep '08

08 Sep '08

Julien Garnier wrote: > Pierangelo Masarati a écrit : >> Should now be fixed in HEAD; please test and report. >> >> p. > > I've just install head : > @(#) $OpenLDAP: slapd 2.X (Sep 8 2008 13:30:44) $ > > Seems to be OK, I only retrieve my 2 users > What was the problem ? In your specific case (a "liberal" local filter and a strict remote filter ANDed) the original filter was not applied to the entire entry, after merging the local and remote parts. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5656) Bind operations with translucent overlay
by julien.garnier＠dr13.cnrs.fr 08 Sep '08

08 Sep '08

Hi, I'm interersted in this option to. Juju

1 0

Re: (ITS#5679) Translucent search
by julien.garnier＠dr13.cnrs.fr 08 Sep '08

08 Sep '08

This is a cryptographically signed message in MIME format. --------------ms090702020105050508040500 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Pierangelo Masarati a =E9crit : > Should now be fixed in HEAD; please test and report. > > p. I've just install head : @(#) $OpenLDAP: slapd 2.X (Sep 8 2008 13:30:44) $ Seems to be OK, I only retrieve my 2 users What was the problem ? Thanks ! Julien *************************************************************************= ** ldapsearch -x -b "ou=3DPeople,dc=3Dcnrs,dc=3Dfr" =20 "(&(ou=3DMOY1300*)(corsecu=3D*))" ou corsecu # extended LDIF # # LDAPv3 # base <ou=3DPeople,dc=3Dcnrs,dc=3Dfr> with scope subtree # filter: (&(ou=3DMOY1300*)(corsecu=3D*)) # requesting: ou corsecu # # martine.costanzo, cnrs, People, cnrs.fr dn: uid=3Dmartine.costanzo,ou=3Dcnrs,ou=3DPeople,dc=3Dcnrs,dc=3Dfr ou:: TU9ZMTMwMCAtICgxKSAtIETDqWzDqWdhdGlvbiBMYW5ndWVkb2MtUm91c3NpbGxvbg=3D= =3D CorSecu: MOY1300 # vincent.chicot, cnrs, People, cnrs.fr dn: uid=3Dvincent.chicot,ou=3Dcnrs,ou=3DPeople,dc=3Dcnrs,dc=3Dfr ou:: TU9ZMTMwMCAtICgxKSAtIETDqWzDqWdhdGlvbiBMYW5ndWVkb2MtUm91c3NpbGxvbg=3D= =3D CorSecu: MOY1300 # search result search: 2 result: 0 Success # numResponses: 3 # numEntries: 2 --------------ms090702020105050508040500 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMxTCC A2kwggJRoAMCAQICAQEwDQYJKoZIhvcNAQEEBQAwKzELMAkGA1UEBhMCRlIxDTALBgNVBAoT BENOUlMxDTALBgNVBAMTBENOUlMwHhcNMDEwNDI3MDU0NTI4WhcNMTEwNDI1MDU0NTI4WjAw MQswCQYDVQQGEwJGUjENMAsGA1UEChMEQ05SUzESMBAGA1UEAxMJQ05SUy1QbHVzMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyQlSTUNpNZM31NKiH++/aLeFo2lCbD/EdAsq k8Vzl0yoN+BS3qY5EbkZbUwU3x/o0XsfvqsfOqTz4MxEavsJmlRetHAfYUPmXCiwwnxCmFS/ +N2NmN2bnWIY0Vzk6qZkgTdYZqj1eiXNyn1q1E/IpPEp7hA+KdulYJ706Xj99ih8kVFa/a8y 45ub5FOWpK4DJPBoNxS7LPsZyGtfehmcCRtj2JF7BcxJMTH6GPwZ1j/Y4DdBcxmzIfLOjQly ROrlDF5iiscuxzZOPOKUcbnjU5fgFxTE8YQ9jyqL5X6xeWaNABwPR6O+Kln/eDowWrJXnjke VBbfBKm6xYvLyzlQUQIDAQABo4GSMIGPMAwGA1UdEwQFMAMBAf8wHQYDVR0OBBYEFFd9dKaS m4hc/uQEKfTsOmcnVOD4MFMGA1UdIwRMMEqAFFbraLnSXH6YtaVTw5FvY1jE+Wu3oS+kLTAr MQswCQYDVQQGEwJGUjENMAsGA1UEChMEQ05SUzENMAsGA1UEAxMEQ05SU4IBADALBgNVHQ8E BAMCAQYwDQYJKoZIhvcNAQEEBQADggEBAEc8oDJIziXlPHqdm+CF/44HRs8MOif5Un3d8x7y vgBqvLt2WV6xoI4h4Y+54Z7Aog3H65z/qtiZdxb3CehCzhltPGHZ/oNHZJa74xqUXJgXeKUk V/JQw0a/z4VLRjnhU0mzbvghbOAJsA6QqsKWC2ZiWhHZaLScVt3zrJ9F8mWX3DAf4HRN+0iY U438vLKSBM6KJhb7Mn1tXk36IcskrwAnozVizkwLendcMYpKuKyu7DofQXUouGwJF+YE6u3B L72QvPko9jHauBqNWpRm2n1ETnjw2VXs7RKfy8q8no78VLT8+x7fPCBcZMx69Ytyouj+TThX KVNQ4bxYoJEggZUwggSoMIIDkKADAgECAgIOdzANBgkqhkiG9w0BAQUFADAwMQswCQYDVQQG EwJGUjENMAsGA1UEChMEQ05SUzESMBAGA1UEAxMJQ05SUy1QbHVzMB4XDTA3MTEwODEyMDAw NFoXDTA4MTEwNzEyMDAwNFowczELMAkGA1UEBhMCRlIxDTALBgNVBAoTBENOUlMxEDAOBgNV BAsTB01PWTEzMDAxFzAVBgNVBAMTDkp1bGllbiBHYXJuaWVyMSowKAYJKoZIhvcNAQkBFhtK dWxpZW4uR2FybmllckBkcjEzLmNucnMuZnIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDnOJa63KmBNrk1iWwIoBfaNRIoB5R+4X+aCOXHD9jXaq5WUV42JEFHvgA87t6esw5U lKgjjyDa8IEW6YQX/WQ9EuHVq4zAvYFQ37bv+obvf1icCyOxDCqqozcIaP8vawVhD244p3bx nVP18QlmlS6MAoqD2NSOgdXjrqQb2uJSE+KLwGMnjjs4zb8lRt2dYp67z7SBLYTnTq04o0Yr fOtYt+rnlleDlWKdJGgNqryiHO20tKlOAUHE4ahZHjsKhEZGdJ4KCoEuDNQtyRLznRGuuH+b 2QjecVL2DmF26hNYlgM4c4TNWETGEBSgdBnlntcEQH443LN2qEx+lRA5dIr/AgMBAAGjggGH MIIBgzAMBgNVHRMBAf8EAjAAMBEGCWCGSAGG+EIBAQQEAwIEsDAOBgNVHQ8BAf8EBAMCBeAw cAYJYIZIAYb4QgENBGMWYUNlcnRpZmljYXQgQ05SUy1QbHVzLiBQb3VyIHRvdXRlIGluZm9y bWF0aW9uIHNlIHJlcG9ydGVyIOAgaHR0cDovL2lnYy5zZXJ2aWNlcy5jbnJzLmZyL0NOUlMt UGx1cy8wHQYDVR0OBBYEFECFdlYtLkLUfoSH/7VfvQ4hYG60MFMGA1UdIwRMMEqAFFd9dKaS m4hc/uQEKfTsOmcnVOD4oS+kLTArMQswCQYDVQQGEwJGUjENMAsGA1UEChMEQ05SUzENMAsG A1UEAxMEQ05SU4IBATAmBgNVHREEHzAdgRtKdWxpZW4uR2FybmllckBkcjEzLmNucnMuZnIw QgYDVR0fBDswOTA3oDWgM4YxaHR0cDovL2NybHMuc2VydmljZXMuY25ycy5mci9DTlJTLVBs dXMvZ2V0ZGVyLmNybDANBgkqhkiG9w0BAQUFAAOCAQEAuz1KzmYgAcfVPB1mE8GBR0Yzz/td ij3IttaeiCmpDfArhOwdolUiLV1MF/oJGDHX+yxpcHNu6wH3E6eEVoYycPwCcN5P9mTaxrTG KYXIj6RoDPIiCQpE9zjKV+c0jJr0bwBZIIJfCIpOpmcHHW+3BbtqjuboydwOqh5ICesPnMRr BA6WEEnB7pv1sp0vAoK0O7/ctJS6C/X37LsTBYcHVkKoyjGYUYdBjWUgmPs+jsArqe+QKSRA zl/3Xc83ZZ681aKApq9hrlmDYpP50E87uK+c2ul/fm4iwvJdb3WkyQaCfc4Epot5GMusb5/C j8JLmtpc7mv+DIrhbz3jbmZ0HTCCBKgwggOQoAMCAQICAg53MA0GCSqGSIb3DQEBBQUAMDAx CzAJBgNVBAYTAkZSMQ0wCwYDVQQKEwRDTlJTMRIwEAYDVQQDEwlDTlJTLVBsdXMwHhcNMDcx MTA4MTIwMDA0WhcNMDgxMTA3MTIwMDA0WjBzMQswCQYDVQQGEwJGUjENMAsGA1UEChMEQ05S UzEQMA4GA1UECxMHTU9ZMTMwMDEXMBUGA1UEAxMOSnVsaWVuIEdhcm5pZXIxKjAoBgkqhkiG 9w0BCQEWG0p1bGllbi5HYXJuaWVyQGRyMTMuY25ycy5mcjCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAOc4lrrcqYE2uTWJbAigF9o1EigHlH7hf5oI5ccP2NdqrlZRXjYkQUe+ ADzu3p6zDlSUqCOPINrwgRbphBf9ZD0S4dWrjMC9gVDftu/6hu9/WJwLI7EMKqqjNwho/y9r BWEPbjindvGdU/XxCWaVLowCioPY1I6B1eOupBva4lIT4ovAYyeOOzjNvyVG3Z1inrvPtIEt hOdOrTijRit861i36ueWV4OVYp0kaA2qvKIc7bS0qU4BQcThqFkeOwqERkZ0ngoKgS4M1C3J EvOdEa64f5vZCN5xUvYOYXbqE1iWAzhzhM1YRMYQFKB0GeWe1wRAfjjcs3aoTH6VEDl0iv8C AwEAAaOCAYcwggGDMAwGA1UdEwEB/wQCMAAwEQYJYIZIAYb4QgEBBAQDAgSwMA4GA1UdDwEB /wQEAwIF4DBwBglghkgBhvhCAQ0EYxZhQ2VydGlmaWNhdCBDTlJTLVBsdXMuIFBvdXIgdG91 dGUgaW5mb3JtYXRpb24gc2UgcmVwb3J0ZXIg4CBodHRwOi8vaWdjLnNlcnZpY2VzLmNucnMu ZnIvQ05SUy1QbHVzLzAdBgNVHQ4EFgQUQIV2Vi0uQtR+hIf/tV+9DiFgbrQwUwYDVR0jBEww SoAUV310ppKbiFz+5AQp9Ow6ZydU4PihL6QtMCsxCzAJBgNVBAYTAkZSMQ0wCwYDVQQKEwRD TlJTMQ0wCwYDVQQDEwRDTlJTggEBMCYGA1UdEQQfMB2BG0p1bGllbi5HYXJuaWVyQGRyMTMu Y25ycy5mcjBCBgNVHR8EOzA5MDegNaAzhjFodHRwOi8vY3Jscy5zZXJ2aWNlcy5jbnJzLmZy L0NOUlMtUGx1cy9nZXRkZXIuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQC7PUrOZiABx9U8HWYT wYFHRjPP+12KPci21p6IKakN8CuE7B2iVSItXUwX+gkYMdf7LGlwc27rAfcTp4RWhjJw/AJw 3k/2ZNrGtMYphciPpGgM8iIJCkT3OMpX5zSMmvRvAFkggl8Iik6mZwcdb7cFu2qO5ujJ3A6q HkgJ6w+cxGsEDpYQScHum/WynS8CgrQ7v9y0lLoL9ffsuxMFhwdWQqjKMZhRh0GNZSCY+z6O wCup75ApJEDOX/ddzzdlnrzVooCmr2GuWYNik/nQTzu4r5za6X9+biLC8l1vdaTJBoJ9zgSm i3kYy6xvn8KPwkua2lzua/4MiuFvPeNuZnQdMYICojCCAp4CAQEwNjAwMQswCQYDVQQGEwJG UjENMAsGA1UEChMEQ05SUzESMBAGA1UEAxMJQ05SUy1QbHVzAgIOdzAJBgUrDgMCGgUAoIIB QTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wODA5MDgxMTQz NTBaMCMGCSqGSIb3DQEJBDEWBBT/z7sYiEHm4wcm/1VtTFildsjJlDBFBgkrBgEEAYI3EAQx ODA2MDAxCzAJBgNVBAYTAkZSMQ0wCwYDVQQKEwRDTlJTMRIwEAYDVQQDEwlDTlJTLVBsdXMC Ag53MEcGCyqGSIb3DQEJEAILMTigNjAwMQswCQYDVQQGEwJGUjENMAsGA1UEChMEQ05SUzES MBAGA1UEAxMJQ05SUy1QbHVzAgIOdzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4G CCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAN BgkqhkiG9w0BAQEFAASCAQDT70G5dWoLsUNxEnn23uXSg3MAa3xSAWUPJjio5a+iXc+63O2l mjkeYt/uvUyfHNtjfHldd7n8f2Ia20Q7tsIttT0llBozXtuvuJ8UYJ4aAxYxyaeLejLtojFA 5Ewh0O0YZ3vlM7SSm55uzh4MnuMPZdiGqdnw+GbF+RJiN2O9uSrcCRrlyWyCo/xLU5XokkHX hXbpRwy6e9A8QLS89Vqa3ndqtf4Uyy6GPMrCyQp5JgKW968uleP8lyB1tbyyU8mhlLLyvblo WaAWn339Nc/UPLOJy61qv2WTWDVDZzt6GbL07TQcqdx5iJf0Ra8zFN+5E5+7ffUhLtzBAa2m F9CfAAAAAAAA --------------ms090702020105050508040500--

1 0

(ITS#5689) back-config handling of olcTranslucentLocal/Remote is broken
by ando＠sys-net.it 08 Sep '08

08 Sep '08

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (131.175.154.148) Submitted by: ando remove the ARG_STRING to fix. p.

1 0

Re: (ITS#5679) Translucent search
by ando＠sys-net.it 08 Sep '08

08 Sep '08

Should now be fixed in HEAD; please test and report. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5679) Translucent search
by julien.garnier＠dr13.cnrs.fr 08 Sep '08

08 Sep '08

This is a cryptographically signed message in MIME format. --------------ms090100030100000501010002 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> <title></title> </head> <body bgcolor="#ffffff" text="#000000"> Pierangelo Masarati a écrit : <blockquote cite="mid:48C2B56D.6000703@sys-net.it" type="cite"><a class="moz-txt-link-abbreviated" href="mailto:julien@famille-garnier.com">julien(a)famille-garnier.com</a> wrote: <blockquote type="cite">It seems to be impossible to search local and remote together : a search request against one local attribute work correctly and return result 1 (ldapsearch "(local=*)") a search on a remote atttribute works fine  and return result 2 (ldapsearch "(remote=*)") Finaly, a search with the local and remote attribute  (ldapsearch "($(local=*)(remote=*))") </blockquote> I assume "$" is a typo, while you meant "&" in the above filter. </blockquote> Hi Pierangelo, yes, it is a typo <blockquote cite="mid:48C2B56D.6000703@sys-net.it" type="cite"> <blockquote type="cite">only return results as the search on the local attribute and doesn't take the remote attribute. The respons is the same as result 1 In slapd.conf : translucent_local local translucent_remote remote </blockquote> I've checked the current code, and it appears to work as intended.  Can you confirm the fact that the local and remote attributes are contained only in the local and the remote database, respectively?  You can easily check by directly searching the remote database.  Otherwise, you don't provide enough information about configuration and database contents to reproduce the issue. </blockquote> my config : ldap_relay (remote in the translucent config) is synchronize with a master via syncrepl. : ####################################################################### # Global Directives: # Features to permit allow bind_v2 # Schema and objectClass definitions include         /etc/openldap/schema/core.schema include         /etc/openldap/schema/cosine.schema include         /etc/openldap/schema/nis.schema include         /etc/openldap/schema/inetorgperson.schema include         /etc/openldap/schema/cnrs.schema # Where the pid file is put. The init.d script # will not stop the server if you change this. pidfile         /var/run/slapd/slapd.pid # List of arguments that were passed to the server argsfile        /var/run/slapd/slapd.args # Read slapd.conf(5) for possible values loglevel        0 # Where the dynamically loaded modules are stored # The maximum number of entries that is returned for a search operation sizelimit 500000 # The tool-threads parameter sets the actual amount of cpu's that is used # for indexing. tool-threads 2 ####################################################################### # Specific Backend Directives for bdb: # Backend specific directives apply to this backend until another # 'backend' directive occurs backend         bdb #checkpoint 512 30 database        bdb # The base of your directory in database #1 suffix          "ou=People,dc=cnrs,dc=fr" # rootdn directive for specifying a superuser on the database. This is needed # for syncrepl. rootdn          "cn=admin,ou=People,dc=cnrs,dc=fr" rootpw          "password" # Where the database file are physically stored for database #1 directory       "/var/lib/ldap-people" # For the Debian package we use 2MB as default but be sure to update this # value if you have plenty of RAM #dbconfig set_cachesize 0 2097152 0 dbconfig set_cachesize 0 536870912 0 dbconfig set_flags    DB_LOG_AUTOREMOVE # Sven Hartge reported that he had to set this value incredibly high # to get slapd running at all. See <a class="moz-txt-link-freetext" href="http://bugs.debian.org/303057">http://bugs.debian.org/303057</a> # for more information. # Number of objects that can be locked at the same time. dbconfig set_lk_max_objects 1500 # Number of locks (both requestd and granted) dbconfig set_lk_max_locks 1500 # Number of lockers dbconfig set_lk_max_lockers 1500 dbconfig set_flags    DB_LOG_AUTOREMOVE # Indexing options for database #1 index objectClass                       eq index ou,cn,mail,surname,givenname      eq,pres,sub index uid                               eq,pres,sub index entryUUID,entryCSN                eq,pres index cnrsRole,cnrsDepartement          eq,pres,sub index cnrsDelegation                    eq,pres,sub index departmentNumber                  eq,pres,sub # Save the time that the entry gets modified, for database #1 lastmod         on #id du client (numero DR) syncrepl rid=013         provider=<a class="moz-txt-link-freetext" href="ldap://sagan.dr15.cnrs.fr:389">ldap://sagan.dr15.cnrs.fr:389</a>         searchbase="ou=People,dc=cnrs,dc=fr"         type=refreshAndPersist         scope=sub         interval=00:00:00:10         retry="60 10 300 +"         attrs="*"         schemachecking=off         bindmethod=simple         binddn="cn=sync-dr13,ou=people,dc=cnrs,dc=fr"         credentials="password" access to dn.base="" by * read # The admin dn has full write access, everyone else # can read everything. access to *         by dn="cn=admin,ou=People,dc=cnrs,dc=fr" write         by * read ******************************************************************* ******************************************************************* My ldap server user translucent to add attributes to ldap_relay : # Schema and objectClass definitions include         /etc/openldap/schema/core.schema include         /etc/openldap/schema/cosine.schema include         /etc/openldap/schema/nis.schema include         /etc/openldap/schema/inetorgperson.schema include         /etc/openldap/schema/DR13.schema include         /etc/openldap/schema/cnrs.schema include         /etc/openldap/schema/dyngroup.schema #include         /etc/openldap/schema/calendar.schema #include         /etc/openldap/schema/julien.schema pidfile         /var/run/slapd/slapd.pid argsfile        /var/run/slapd/slapd.args loglevel      0 allow bind_v2 # The maximum number of entries that is returned for a search operation sizelimit       50000 # The tool-threads parameter sets the actual amount of cpu's that is used # for indexing. tool-threads    1 ####################################################################### # Specific Backend Directives for bdb: # Backend specific directives apply to this backend until another # 'backend' directive occurs backend         bdb ####################################################################### # Specific Directives for database #1, of type bdb: # Database specific directives apply to this databasse until another # 'database' directive occurs database        bdb # The base of your directory in database #1 suffix          "ou=People,dc=cnrs,dc=fr" # rootdn directive for specifying a superuser on the database. This is needed # for syncrepl. rootdn          "cn=admin,ou=People,dc=cnrs,dc=fr" rootpw          "password" # Where the database file are physically stored for database #1 directory       "/var/lib/ldap-people" dbconfig set_cachesize 0 536870912 0 dbconfig set_flags    DB_LOG_AUTOREMOVE dbconfig set_lk_max_objects 1500 dbconfig set_lk_max_locks 1500 dbconfig set_lk_max_lockers 1500 # Indexing options for database #1 index objectClass                       eq,pres index ou,cn,mail,surname,givenname      eq,pres,sub index uid                               eq,pres index entryCSN,entryUUID                eq,pres index cnrsDelegation                    eq,pres,sub index Service,ACMO,corinfo,corcom,corform,corvalo,gxlab,corsecu,authtest,GLabintel                eq,pres,sub overlay         translucent translucent_no_glue off translucent_strict off translucent_local ACMO,Service,corinfo,corcom,corform,corvalo,gxlab,corsecu,userPassword,shadowLastChange,authtest,GLabintel,Poste translucent_remote sn,GivenName,mail,street,Postalcode,l,cnrsDelegation,uid uri             <a class="moz-txt-link-freetext" href="ldap://ldap_relay.dr13.cnrs.fr">ldap://ldap_relay.dr13.cnrs.fr</a> lastmod         off acl-bind        binddn="cn=admin,ou=People,dc=cnrs,dc=fr" credentials="password" access to attrs=userPassword,shadowLastChange         by dn="cn=admin,ou=People,dc=cnrs,dc=fr" write         by anonymous auth         by self write         by * none access to dn.base=""         by * read # acces de l'IBMM (UMR5247) access to dn.sub="ou=people,dc=cnrs,dc=fr"         filter=(ou=UMR5247*)         by peername.regex="IP=193\.49\.133\..+" read         by peername.regex="IP=127\.0\.0\.1" read         by peername.regex="IP=194\.214\.161\.70" read # acces de la delegation : lecture pour tout access to *         by peername.regex="IP=193\.49\.133\..+" read         by peername.regex="IP=127\.0\.0\.1" read         by dn="cn=admin,ou=People,dc=cnrs,dc=fr" write         by * none *********************************************************** *********************************************************** the searches : ou is in remote (it's ou derivated from inetorgperson) corsecu is in local : attribute is add to inetorgperson : attributetype ( 1.3.6.1.4.1.10813.13.2.9         NAME 'CorSecu'         DESC 'Correspondant Securité'         EQUALITY caseIgnoreMatch         SUBSTR caseIgnoreSubstringsMatch         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) if I search who is corsecu :  ldapsearch -x -b "ou=People,dc=cnrs,dc=fr"  "(corsecu=*)" ou corsecu # extended LDIF # # LDAPv3 # base <ou=People,dc=cnrs,dc=fr> with scope subtree # filter: (corsecu=*) # requesting: ou corsecu # # martine.costanzo, cnrs, People, cnrs.fr dn: uid=martine.costanzo,ou=cnrs,ou=People,dc=cnrs,dc=fr ou:: TU9ZMTMwMCAtICgxKSAtIETDqWzDqWdhdGlvbiBMYW5ndWVkb2MtUm91c3NpbGxvbg== CorSecu: MOY1300 # vincent.chicot, cnrs, People, cnrs.fr dn: uid=vincent.chicot,ou=cnrs,ou=People,dc=cnrs,dc=fr ou:: TU9ZMTMwMCAtICgxKSAtIETDqWzDqWdhdGlvbiBMYW5ndWVkb2MtUm91c3NpbGxvbg== CorSecu: MOY1300 # josiane.tack.1, cnrs, People, cnrs.fr dn: uid=josiane.tack.1,ou=cnrs,ou=People,dc=cnrs,dc=fr ou:: VU1SNTI0MyAtICgxKSAtIEfDqW9zY2llbmNlcyBNb250cGVsbGllcg== CorSecu: UMR5243 # search result search: 2 result: 0 Success # numResponses: 4 # numEntries: 3 Josian Tack is in OU  = UMR5243 - (1) - Géosciences Montpellier other are in OU = MOY1300 - (1) - Délégation Languedoc-Roussillon If I only want corsecu in ou MOY1300 : ldapsearch -x -b "ou=People,dc=cnrs,dc=fr"  "(&(ou=MOY1300*)(corsecu=*))" ou corsecu # extended LDIF # # LDAPv3 # base <ou=People,dc=cnrs,dc=fr> with scope subtree # filter: (&(ou=MOY1300*)(corsecu=*)) # requesting: ou corsecu # # martine.costanzo, cnrs, People, cnrs.fr dn: uid=martine.costanzo,ou=cnrs,ou=People,dc=cnrs,dc=fr ou:: TU9ZMTMwMCAtICgxKSAtIETDqWzDqWdhdGlvbiBMYW5ndWVkb2MtUm91c3NpbGxvbg== CorSecu: MOY1300 # vincent.chicot, cnrs, People, cnrs.fr dn: uid=vincent.chicot,ou=cnrs,ou=People,dc=cnrs,dc=fr ou:: TU9ZMTMwMCAtICgxKSAtIETDqWzDqWdhdGlvbiBMYW5ndWVkb2MtUm91c3NpbGxvbg== CorSecu: MOY1300 # josiane.tack.1, cnrs, People, cnrs.fr dn: uid=josiane.tack.1,ou=cnrs,ou=People,dc=cnrs,dc=fr ou:: VU1SNTI0MyAtICgxKSAtIEfDqW9zY2llbmNlcyBNb250cGVsbGllcg== CorSecu: UMR5243 # search result search: 2 result: 0 Success # numResponses: 4 # numEntries: 3 Josiane Tack is always here Thanks Julien </body> </html> --------------ms090100030100000501010002 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMxTCC A2kwggJRoAMCAQICAQEwDQYJKoZIhvcNAQEEBQAwKzELMAkGA1UEBhMCRlIxDTALBgNVBAoT BENOUlMxDTALBgNVBAMTBENOUlMwHhcNMDEwNDI3MDU0NTI4WhcNMTEwNDI1MDU0NTI4WjAw MQswCQYDVQQGEwJGUjENMAsGA1UEChMEQ05SUzESMBAGA1UEAxMJQ05SUy1QbHVzMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyQlSTUNpNZM31NKiH++/aLeFo2lCbD/EdAsq k8Vzl0yoN+BS3qY5EbkZbUwU3x/o0XsfvqsfOqTz4MxEavsJmlRetHAfYUPmXCiwwnxCmFS/ +N2NmN2bnWIY0Vzk6qZkgTdYZqj1eiXNyn1q1E/IpPEp7hA+KdulYJ706Xj99ih8kVFa/a8y 45ub5FOWpK4DJPBoNxS7LPsZyGtfehmcCRtj2JF7BcxJMTH6GPwZ1j/Y4DdBcxmzIfLOjQly ROrlDF5iiscuxzZOPOKUcbnjU5fgFxTE8YQ9jyqL5X6xeWaNABwPR6O+Kln/eDowWrJXnjke VBbfBKm6xYvLyzlQUQIDAQABo4GSMIGPMAwGA1UdEwQFMAMBAf8wHQYDVR0OBBYEFFd9dKaS m4hc/uQEKfTsOmcnVOD4MFMGA1UdIwRMMEqAFFbraLnSXH6YtaVTw5FvY1jE+Wu3oS+kLTAr MQswCQYDVQQGEwJGUjENMAsGA1UEChMEQ05SUzENMAsGA1UEAxMEQ05SU4IBADALBgNVHQ8E BAMCAQYwDQYJKoZIhvcNAQEEBQADggEBAEc8oDJIziXlPHqdm+CF/44HRs8MOif5Un3d8x7y vgBqvLt2WV6xoI4h4Y+54Z7Aog3H65z/qtiZdxb3CehCzhltPGHZ/oNHZJa74xqUXJgXeKUk V/JQw0a/z4VLRjnhU0mzbvghbOAJsA6QqsKWC2ZiWhHZaLScVt3zrJ9F8mWX3DAf4HRN+0iY U438vLKSBM6KJhb7Mn1tXk36IcskrwAnozVizkwLendcMYpKuKyu7DofQXUouGwJF+YE6u3B L72QvPko9jHauBqNWpRm2n1ETnjw2VXs7RKfy8q8no78VLT8+x7fPCBcZMx69Ytyouj+TThX KVNQ4bxYoJEggZUwggSoMIIDkKADAgECAgIOdzANBgkqhkiG9w0BAQUFADAwMQswCQYDVQQG EwJGUjENMAsGA1UEChMEQ05SUzESMBAGA1UEAxMJQ05SUy1QbHVzMB4XDTA3MTEwODEyMDAw NFoXDTA4MTEwNzEyMDAwNFowczELMAkGA1UEBhMCRlIxDTALBgNVBAoTBENOUlMxEDAOBgNV BAsTB01PWTEzMDAxFzAVBgNVBAMTDkp1bGllbiBHYXJuaWVyMSowKAYJKoZIhvcNAQkBFhtK dWxpZW4uR2FybmllckBkcjEzLmNucnMuZnIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDnOJa63KmBNrk1iWwIoBfaNRIoB5R+4X+aCOXHD9jXaq5WUV42JEFHvgA87t6esw5U lKgjjyDa8IEW6YQX/WQ9EuHVq4zAvYFQ37bv+obvf1icCyOxDCqqozcIaP8vawVhD244p3bx nVP18QlmlS6MAoqD2NSOgdXjrqQb2uJSE+KLwGMnjjs4zb8lRt2dYp67z7SBLYTnTq04o0Yr fOtYt+rnlleDlWKdJGgNqryiHO20tKlOAUHE4ahZHjsKhEZGdJ4KCoEuDNQtyRLznRGuuH+b 2QjecVL2DmF26hNYlgM4c4TNWETGEBSgdBnlntcEQH443LN2qEx+lRA5dIr/AgMBAAGjggGH MIIBgzAMBgNVHRMBAf8EAjAAMBEGCWCGSAGG+EIBAQQEAwIEsDAOBgNVHQ8BAf8EBAMCBeAw cAYJYIZIAYb4QgENBGMWYUNlcnRpZmljYXQgQ05SUy1QbHVzLiBQb3VyIHRvdXRlIGluZm9y bWF0aW9uIHNlIHJlcG9ydGVyIOAgaHR0cDovL2lnYy5zZXJ2aWNlcy5jbnJzLmZyL0NOUlMt UGx1cy8wHQYDVR0OBBYEFECFdlYtLkLUfoSH/7VfvQ4hYG60MFMGA1UdIwRMMEqAFFd9dKaS m4hc/uQEKfTsOmcnVOD4oS+kLTArMQswCQYDVQQGEwJGUjENMAsGA1UEChMEQ05SUzENMAsG A1UEAxMEQ05SU4IBATAmBgNVHREEHzAdgRtKdWxpZW4uR2FybmllckBkcjEzLmNucnMuZnIw QgYDVR0fBDswOTA3oDWgM4YxaHR0cDovL2NybHMuc2VydmljZXMuY25ycy5mci9DTlJTLVBs dXMvZ2V0ZGVyLmNybDANBgkqhkiG9w0BAQUFAAOCAQEAuz1KzmYgAcfVPB1mE8GBR0Yzz/td ij3IttaeiCmpDfArhOwdolUiLV1MF/oJGDHX+yxpcHNu6wH3E6eEVoYycPwCcN5P9mTaxrTG KYXIj6RoDPIiCQpE9zjKV+c0jJr0bwBZIIJfCIpOpmcHHW+3BbtqjuboydwOqh5ICesPnMRr BA6WEEnB7pv1sp0vAoK0O7/ctJS6C/X37LsTBYcHVkKoyjGYUYdBjWUgmPs+jsArqe+QKSRA zl/3Xc83ZZ681aKApq9hrlmDYpP50E87uK+c2ul/fm4iwvJdb3WkyQaCfc4Epot5GMusb5/C j8JLmtpc7mv+DIrhbz3jbmZ0HTCCBKgwggOQoAMCAQICAg53MA0GCSqGSIb3DQEBBQUAMDAx CzAJBgNVBAYTAkZSMQ0wCwYDVQQKEwRDTlJTMRIwEAYDVQQDEwlDTlJTLVBsdXMwHhcNMDcx MTA4MTIwMDA0WhcNMDgxMTA3MTIwMDA0WjBzMQswCQYDVQQGEwJGUjENMAsGA1UEChMEQ05S UzEQMA4GA1UECxMHTU9ZMTMwMDEXMBUGA1UEAxMOSnVsaWVuIEdhcm5pZXIxKjAoBgkqhkiG 9w0BCQEWG0p1bGllbi5HYXJuaWVyQGRyMTMuY25ycy5mcjCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAOc4lrrcqYE2uTWJbAigF9o1EigHlH7hf5oI5ccP2NdqrlZRXjYkQUe+ ADzu3p6zDlSUqCOPINrwgRbphBf9ZD0S4dWrjMC9gVDftu/6hu9/WJwLI7EMKqqjNwho/y9r BWEPbjindvGdU/XxCWaVLowCioPY1I6B1eOupBva4lIT4ovAYyeOOzjNvyVG3Z1inrvPtIEt hOdOrTijRit861i36ueWV4OVYp0kaA2qvKIc7bS0qU4BQcThqFkeOwqERkZ0ngoKgS4M1C3J EvOdEa64f5vZCN5xUvYOYXbqE1iWAzhzhM1YRMYQFKB0GeWe1wRAfjjcs3aoTH6VEDl0iv8C AwEAAaOCAYcwggGDMAwGA1UdEwEB/wQCMAAwEQYJYIZIAYb4QgEBBAQDAgSwMA4GA1UdDwEB /wQEAwIF4DBwBglghkgBhvhCAQ0EYxZhQ2VydGlmaWNhdCBDTlJTLVBsdXMuIFBvdXIgdG91 dGUgaW5mb3JtYXRpb24gc2UgcmVwb3J0ZXIg4CBodHRwOi8vaWdjLnNlcnZpY2VzLmNucnMu ZnIvQ05SUy1QbHVzLzAdBgNVHQ4EFgQUQIV2Vi0uQtR+hIf/tV+9DiFgbrQwUwYDVR0jBEww SoAUV310ppKbiFz+5AQp9Ow6ZydU4PihL6QtMCsxCzAJBgNVBAYTAkZSMQ0wCwYDVQQKEwRD TlJTMQ0wCwYDVQQDEwRDTlJTggEBMCYGA1UdEQQfMB2BG0p1bGllbi5HYXJuaWVyQGRyMTMu Y25ycy5mcjBCBgNVHR8EOzA5MDegNaAzhjFodHRwOi8vY3Jscy5zZXJ2aWNlcy5jbnJzLmZy L0NOUlMtUGx1cy9nZXRkZXIuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQC7PUrOZiABx9U8HWYT wYFHRjPP+12KPci21p6IKakN8CuE7B2iVSItXUwX+gkYMdf7LGlwc27rAfcTp4RWhjJw/AJw 3k/2ZNrGtMYphciPpGgM8iIJCkT3OMpX5zSMmvRvAFkggl8Iik6mZwcdb7cFu2qO5ujJ3A6q HkgJ6w+cxGsEDpYQScHum/WynS8CgrQ7v9y0lLoL9ffsuxMFhwdWQqjKMZhRh0GNZSCY+z6O wCup75ApJEDOX/ddzzdlnrzVooCmr2GuWYNik/nQTzu4r5za6X9+biLC8l1vdaTJBoJ9zgSm i3kYy6xvn8KPwkua2lzua/4MiuFvPeNuZnQdMYICojCCAp4CAQEwNjAwMQswCQYDVQQGEwJG UjENMAsGA1UEChMEQ05SUzESMBAGA1UEAxMJQ05SUy1QbHVzAgIOdzAJBgUrDgMCGgUAoIIB QTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wODA5MDgwODU1 MDBaMCMGCSqGSIb3DQEJBDEWBBSid4zDaEYBT67+19UaSp/1nXMUWDBFBgkrBgEEAYI3EAQx ODA2MDAxCzAJBgNVBAYTAkZSMQ0wCwYDVQQKEwRDTlJTMRIwEAYDVQQDEwlDTlJTLVBsdXMC Ag53MEcGCyqGSIb3DQEJEAILMTigNjAwMQswCQYDVQQGEwJGUjENMAsGA1UEChMEQ05SUzES MBAGA1UEAxMJQ05SUy1QbHVzAgIOdzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4G CCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAN BgkqhkiG9w0BAQEFAASCAQA04y3ZTPTP04e07uaMNwF5+4i+329g+KgAd+lmUvfaGJsOyGjw pCsZQIqeBzZFAfCNtmp8VyU2TCVcF6A5odWabasUltXe8HfLN64njJ/50iUQfDRFZEcZfh9b nYSTsHiuCyua78Iim18gNflXQReHWdreoSkg0MDaq0MTd98tNxZsOFPa4l9e7Xj29F4HHgck pD/0XXmP6/ZtFOxZUojL92H31RS6MlPeLC0EX5RjkLQ4maXlMvjX1MQUpv6uwOG1rkSaTDKW zEcUcKP/gYFHL7LDUZC8GlhLGvuzxrSamS2RRJE+mAzc/U+aOf6O7qeFyje8PM6r57qc0iQQ XCDeAAAAAAAA --------------ms090100030100000501010002--

1 0

Re: (ITS#5663) Declaring substitute syntax as LDAP syntax
by ando＠sys-net.it 07 Sep '08

07 Sep '08

The suggested extension has been added to syntax add code; parsing of a syntax with the given extension will result in using the implementation of the substitute syntax if an implementation is missing for the given syntax. This only works for syntaxes added programmatically using syn_add(), e.g. by run-time modules, as there's no provisions for adding syntaxes via configuration. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5687) corrupted double-linked list on shutdown
by quanah＠zimbra.com 06 Sep '08

06 Sep '08

--On Saturday, September 06, 2008 2:26 PM +0000 ando(a)sys-net.it wrote: > ando(a)sys-net.it wrote: >> The problem is in glue_op_search(): it saves a copy of the rewritten DN; >> in case of CTRL^C, the rewritten DN is deleted by rwm_op_cleanup, and a >> dangling pointer to it is later restored in o_req_[n]dn by >> glue_op_search (lines 446-7 or 463-4). Trying to fix it... > > I've applied a fix that works around this issue without apparently > breaking back-glue (servers/slapd/backglue.c 1.139 -> 1.140). Please > test. I have no more issues after applying these additional fixes. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5679) Translucent search
by ando＠sys-net.it 06 Sep '08

06 Sep '08

julien(a)famille-garnier.com wrote: > It seems to be impossible to search local and remote together : > > a search request against one local attribute work correctly and return result 1 > (ldapsearch "(local=*)") > a search on a remote atttribute works fine and return result 2 (ldapsearch > "(remote=*)") > > Finaly, a search with the local and remote attribute (ldapsearch > "($(local=*)(remote=*))") I assume "$" is a typo, while you meant "&" in the above filter. > only return results as the search on the local > attribute and doesn't take the remote attribute. The respons is the same as > result 1 > > > In slapd.conf : > translucent_local local > translucent_remote remote I've checked the current code, and it appears to work as intended. Can you confirm the fact that the local and remote attributes are contained only in the local and the remote database, respectively? You can easily check by directly searching the remote database. Otherwise, you don't provide enough information about configuration and database contents to reproduce the issue. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5687) corrupted double-linked list on shutdown
by ando＠sys-net.it 06 Sep '08

06 Sep '08

hyc(a)symas.com wrote: > The serious problem is in thread 5, where rwm_op_cleanup frees a DN that > do_search also tries to free. It looks like rwm_op_cleanup is badly broken > here, it apparently should be checking to make sure ros->ro_dn is != ros->r_dn > before freeing r_dn (and ndn). This issue can be serious since it could also hit in case of abandon, not just in case of shutdown. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5687) corrupted double-linked list on shutdown
by ando＠sys-net.it 06 Sep '08

06 Sep '08

ando(a)sys-net.it wrote: > The problem is in glue_op_search(): it saves a copy of the rewritten DN; > in case of CTRL^C, the rewritten DN is deleted by rwm_op_cleanup, and a > dangling pointer to it is later restored in o_req_[n]dn by > glue_op_search (lines 446-7 or 463-4). Trying to fix it... I've applied a fix that works around this issue without apparently breaking back-glue (servers/slapd/backglue.c 1.139 -> 1.140). Please test. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5687) corrupted double-linked list on shutdown
by ando＠sys-net.it 06 Sep '08

06 Sep '08

ando(a)sys-net.it wrote: > It seems that rwm_op_cleanup() frees the massaged DN but does not > restore the original values, since do_search frees it again. I guess > the dn does get massaged, since r_dn is not null. The problem is in glue_op_search(): it saves a copy of the rewritten DN; in case of CTRL^C, the rewritten DN is deleted by rwm_op_cleanup, and a dangling pointer to it is later restored in o_req_[n]dn by glue_op_search (lines 446-7 or 463-4). Trying to fix it... p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5687) corrupted double-linked list on shutdown
by ando＠sys-net.it 06 Sep '08

06 Sep '08

Quanah, I'm not seeing failures like yours, but valgrind is telling me that there is still a double-free in rwm in case of CTRL^C (apart from the listener-related one, which occurs very often): ==12729== Thread 7: ==12729== Invalid free() / delete / delete[] ==12729== at 0x4004FDA: free (vg_replace_malloc.c:233) ==12729== by 0x8240855: ber_memfree_x (memory.c:152) ==12729== by 0x80E5277: slap_sl_free (sl_malloc.c:451) ==12729== by 0x80874AF: do_search (search.c:221) ==12729== by 0x8084347: connection_operation (connection.c:1084) ==12729== by 0x8084834: connection_read_thread (connection.c:1211) ==12729== by 0x820F460: ldap_int_thread_pool_wrapper (tpool.c:663) ==12729== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) ==12729== by 0xD42DBD: clone (in /lib/libc-2.5.so) ==12729== Address 0x44F7908 is 0 bytes inside a block of size 19 free'd ==12729== at 0x4004FDA: free (vg_replace_malloc.c:233) ==12729== by 0x8240855: ber_memfree_x (memory.c:152) ==12729== by 0x80A5A31: ch_free (ch_malloc.c:139) ==12729== by 0x81E1DC0: rwm_op_cleanup (rwm.c:65) ==12729== by 0x80976CD: slap_cleanup_play (result.c:341) ==12729== by 0x8097DEA: send_ldap_response (result.c:522) ==12729== by 0x809850E: slap_send_ldap_result (result.c:642) ==12729== by 0x812D806: ldap_back_search (search.c:544) ==12729== by 0x80F7E40: glue_sub_search (backglue.c:340) ==12729== by 0x80F83A9: glue_op_search (backglue.c:452) ==12729== by 0x80FAD2F: overlay_op_walk (backover.c:657) ==12729== by 0x80FAF64: over_op_func (backover.c:719) ==12729== by 0x80FAFE8: over_op_search (backover.c:741) ==12729== by 0x8087ADB: fe_op_search (search.c:366) ==12729== by 0x80FADAF: overlay_op_walk (backover.c:667) ==12729== by 0x80FAF64: over_op_func (backover.c:719) ==12729== by 0x80FAFE8: over_op_search (backover.c:741) ==12729== by 0x8087483: do_search (search.c:217) ==12729== by 0x8084347: connection_operation (connection.c:1084) ==12729== by 0x8084834: connection_read_thread (connection.c:1211) ==12729== It seems that rwm_op_cleanup() frees the massaged DN but does not restore the original values, since do_search frees it again. I guess the dn does get massaged, since r_dn is not null. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5687) corrupted double-linked list on shutdown
by quanah＠zimbra.com 05 Sep '08

05 Sep '08

--On Saturday, September 06, 2008 1:28 AM +0000 quanah(a)zimbra.com wrote: This one too: Loaded symbols for ../servers/slapd/overlays/.libs/rwm-2.4-releng.so.2 #0 0x0000003bf972e25d in raise () from /lib64/tls/libc.so.6 (gdb) bt #0 0x0000003bf972e25d in raise () from /lib64/tls/libc.so.6 #1 0x0000003bf972fa5e in abort () from /lib64/tls/libc.so.6 #2 0x0000003bf97635e1 in __libc_message () from /lib64/tls/libc.so.6 #3 0x0000003bf9768a78 in malloc_consolidate () from /lib64/tls/libc.so.6 #4 0x0000003bf97698a9 in _int_malloc () from /lib64/tls/libc.so.6 #5 0x0000003bf976b3d2 in calloc () from /lib64/tls/libc.so.6 #6 0x0000002a956bc517 in ber_memcalloc_x (n=1, s=560, ctx=0x0) at memory.c:277 #7 0x0000002a9556a5c0 in ldap_create (ldp=0x45808270) at open.c:113 #8 0x0000002a9556a985 in ldap_initialize (ldp=0x458082e8, url=0x7070c0 "ldap://localhost:9011") at open.c:223 #9 0x0000002a974aa3df in ldap_back_prepare_conn (lc=0x7d63d0, op=0x810030, rs=0x45809cc0, sendok=LDAP_BACK_DONTSEND) at bind.c:639 #10 0x0000002a974ad2c2 in ldap_back_retry (lcp=0x45808520, op=0x810030, rs=0x45809cc0, sendok=LDAP_BACK_DONTSEND) at bind.c:1893 #11 0x0000002a974a8668 in ldap_back_search (op=0x810030, rs=0x45809cc0) at search.c:502 #12 0x00000000004ac45d in glue_sub_search (op=0x810030, rs=0x45809cc0, b0=0x45808740, on=0x6c1e70) at backglue.c:340 #13 0x00000000004aca5f in glue_op_search (op=0x810030, rs=0x45809cc0) at backglue.c:452 #14 0x00000000004afacf in overlay_op_walk (op=0x810030, rs=0x45809cc0, which=op_search, oi=0x6c1c90, on=0x6c1e70) at backover.c:657 #15 0x00000000004afd2b in over_op_func (op=0x810030, rs=0x45809cc0, which=op_search) at backover.c:719 #16 0x00000000004afdc1 in over_op_search (op=0x810030, rs=0x45809cc0) at backover.c:741 #17 0x0000000000435ea8 in fe_op_search (op=0x810030, rs=0x45809cc0) at search.c:366 #18 0x00000000004afb63 in overlay_op_walk (op=0x810030, rs=0x45809cc0, which=op_search, oi=0x702480, on=0x0) at backover.c:667 #19 0x00000000004afd2b in over_op_func (op=0x810030, rs=0x45809cc0, which=op_search) at backover.c:719 #20 0x00000000004afdc1 in over_op_search (op=0x810030, rs=0x45809cc0) at backover.c:741 #21 0x0000000000435865 in do_search (op=0x810030, rs=0x45809cc0) at search.c:217 #22 0x0000000000432839 in connection_operation (ctx=0x45809e20, arg_v=0x810030) at connection.c:1084 #23 0x0000000000432d75 in connection_read_thread (ctx=0x45809e20, argv=0x29) at connection.c:1211 #24 0x0000002a95568cd0 in ldap_int_thread_pool_wrapper (xpool=0x6a3500) at tpool.c:663 #25 0x0000003bfa006137 in start_thread () from /lib64/tls/libpthread.so.0 #26 0x0000003bf97c7533 in clone () from /lib64/tls/libc.so.6 (gdb) info threads 18 process 30967 0x0000003bfa00714b in pthread_join () from /lib64/tls/libpthread.so.0 17 process 31162 0x0000003bfa008b3a in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/tls/libpthread.so.0 16 process 31178 0x0000003bf97be5e2 in poll () from /lib64/tls/libc.so.6 15 process 31259 0x0000003bfa00af8b in __lll_mutex_lock_wait () from /lib64/tls/libpthread.so.0 14 process 31262 0x0000003bf97be5e2 in poll () from /lib64/tls/libc.so.6 13 process 31313 0x0000003bf97be5e2 in poll () from /lib64/tls/libc.so.6 12 process 31397 0x0000003bf97be5e2 in poll () from /lib64/tls/libc.so.6 11 process 31402 0x0000003bf97be5e2 in poll () from /lib64/tls/libc.so.6 10 process 31403 0x0000003bf97be5e2 in poll () from /lib64/tls/libc.so.6 9 process 31408 0x0000003bf97be5e2 in poll () from /lib64/tls/libc.so.6 8 process 31409 0x0000003bf97be5e2 in poll () from /lib64/tls/libc.so.6 7 process 31423 0x0000003bf97be5e2 in poll () from /lib64/tls/libc.so.6 6 process 31485 0x0000003bf97be5e2 in poll () from /lib64/tls/libc.so.6 5 process 31486 0x0000003bf97be5e2 in poll () from /lib64/tls/libc.so.6 4 process 31497 0x0000003bf97be5e2 in poll () from /lib64/tls/libc.so.6 3 process 31498 0x0000003bfa00af8b in __lll_mutex_lock_wait () from /lib64/tls/libpthread.so.0 2 process 31511 0x0000003bf97be5e2 in poll () from /lib64/tls/libc.so.6 * 1 process 31422 0x0000003bf972e25d in raise () from /lib64/tls/libc.so.6 --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5687) corrupted double-linked list on shutdown
by quanah＠zimbra.com 05 Sep '08

05 Sep '08

--On Saturday, September 06, 2008 1:12 AM +0000 quanah(a)zimbra.com wrote: > --On Saturday, September 06, 2008 12:08 AM +0000 hyc(a)symas.com wrote: > >> ando(a)sys-net.it wrote: >>> h.b.furuseth(a)usit.uio.no wrote: >>>>> [quanah@freelancer tests]$ *** glibc detected *** >>>>> /home/quanah/q/openldap-2.4.12/servers/slapd/.libs/lt-slapd: corrupted >>>>> double-linked list: 0x000000000d28a430 *** >>>> This message comes from glibc malloc. Its data structures are >>>> corrupted. >>>> >>>> I couldn't figure out much from the the valgrind output. >>>> But you'll get more frequent mallocs with CPPFLAGS=-DSLAP_NO_SL_MALLOC, >>>> if that code isn't rotted - maybe that'll bring out the problem in >>>> another guise. If that code still works, I don't remember. >>> >>> Here's my output after compiling with -DSLAP_NO_SL_MALLOC=1, running >>> test039 under valgrind and suddenly killing the process: >>> >>> ==9657== Memcheck, a memory error detector. >>> ==9657== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al. >>> ==9657== Using LibVEX rev 1658, a library for dynamic binary >>> translation. ==9657== Copyright (C) 2004-2006, and GNU GPL'd, by >>> OpenWorks LLP. ==9657== Using valgrind-3.2.1, a dynamic binary >>> instrumentation framework. ==9657== Copyright (C) 2000-2006, and GNU >>> GPL'd, by Julian Seward et al. ==9657== For more details, rerun with: -v >>> ==9657== >>> @(#) $OpenLDAP: slapd 2.X (Sep 6 2008 01:35:19) $ >>> masarati@odino.intra.sys-net.it:/home/masarati/Lavoro/sysnet/Ldap/ldap- >>> devel/servers/slapd slapd starting >>> daemon: shutdown requested and initiated. >>> slapd shutdown: waiting for 8 threads to terminate >>> ==9657== Thread 3: >>> ==9657== Invalid read of size 4 >>> ==9657== at 0x807EF03: slap_listener (daemon.c:1754) >>> ==9657== by 0x807F9AC: slap_listener_thread (daemon.c:1997) >>> ==9657== by 0x820F3D4: ldap_int_thread_pool_wrapper (tpool.c:663) >>> ==9657== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) >>> ==9657== by 0xD42DBD: clone (in /lib/libc-2.5.so) >>> ==9657== Address 0x415D3A8 is 32 bytes inside a block of size 164 >>> free'd ==9657== at 0x4004FDA: free (vg_replace_malloc.c:233) >>> ==9657== by 0x82407C9: ber_memfree_x (memory.c:152) >>> ==9657== by 0x80A59E5: ch_free (ch_malloc.c:139) >>> ==9657== by 0x807EDF8: close_listeners (daemon.c:1703) >>> ==9657== by 0x808137F: slapd_daemon_task (daemon.c:2578) >>> ==9657== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) >>> ==9657== by 0xD42DBD: clone (in /lib/libc-2.5.so) >>> ==9657== >>> ==9657== Invalid write of size 4 >>> ==9657== at 0x807EF22: slap_listener (daemon.c:1759) >>> ==9657== by 0x807F9AC: slap_listener_thread (daemon.c:1997) >>> ==9657== by 0x820F3D4: ldap_int_thread_pool_wrapper (tpool.c:663) >>> ==9657== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) >>> ==9657== by 0xD42DBD: clone (in /lib/libc-2.5.so) >>> ==9657== Address 0x415D3A4 is 28 bytes inside a block of size 164 >>> free'd ==9657== at 0x4004FDA: free (vg_replace_malloc.c:233) >>> ==9657== by 0x82407C9: ber_memfree_x (memory.c:152) >>> ==9657== by 0x80A59E5: ch_free (ch_malloc.c:139) >>> ==9657== by 0x807EDF8: close_listeners (daemon.c:1703) >>> ==9657== by 0x808137F: slapd_daemon_task (daemon.c:2578) >>> ==9657== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) >>> ==9657== by 0xD42DBD: clone (in /lib/libc-2.5.so) >>> ==9657== >>> ==9657== Invalid read of size 4 >>> ==9657== at 0x807EFCD: slap_listener (daemon.c:1781) >>> ==9657== by 0x807F9AC: slap_listener_thread (daemon.c:1997) >>> ==9657== by 0x820F3D4: ldap_int_thread_pool_wrapper (tpool.c:663) >>> ==9657== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) >>> ==9657== by 0xD42DBD: clone (in /lib/libc-2.5.so) >>> ==9657== Address 0x415D3A8 is 32 bytes inside a block of size 164 >>> free'd ==9657== at 0x4004FDA: free (vg_replace_malloc.c:233) >>> ==9657== by 0x82407C9: ber_memfree_x (memory.c:152) >>> ==9657== by 0x80A59E5: ch_free (ch_malloc.c:139) >>> ==9657== by 0x807EDF8: close_listeners (daemon.c:1703) >>> ==9657== by 0x808137F: slapd_daemon_task (daemon.c:2578) >>> ==9657== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) >>> ==9657== by 0xD42DBD: clone (in /lib/libc-2.5.so) >>> daemon: accept(7) failed errno=9 (Bad file descriptor) >>> ==9657== >>> ==9657== Thread 5: >>> ==9657== Invalid free() / delete / delete[] >>> ==9657== at 0x4004FDA: free (vg_replace_malloc.c:233) >>> ==9657== by 0x82407C9: ber_memfree_x (memory.c:152) >>> ==9657== by 0x80E522B: slap_sl_free (sl_malloc.c:451) >>> ==9657== by 0x80874AF: do_search (search.c:221) >>> ==9657== by 0x8084347: connection_operation (connection.c:1084) >>> ==9657== by 0x8084834: connection_read_thread (connection.c:1211) >>> ==9657== by 0x820F3D4: ldap_int_thread_pool_wrapper (tpool.c:663) >>> ==9657== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) >>> ==9657== by 0xD42DBD: clone (in /lib/libc-2.5.so) >>> ==9657== Address 0x5595D60 is 0 bytes inside a block of size 29 free'd >>> ==9657== at 0x4004FDA: free (vg_replace_malloc.c:233) >>> ==9657== by 0x82407C9: ber_memfree_x (memory.c:152) >>> ==9657== by 0x80A59E5: ch_free (ch_malloc.c:139) >>> ==9657== by 0x81E1D64: rwm_op_cleanup (rwm.c:64) >>> ==9657== by 0x80976CD: slap_cleanup_play (result.c:341) >>> ==9657== by 0x8097DEA: send_ldap_response (result.c:522) >>> ==9657== by 0x809850E: slap_send_ldap_result (result.c:642) >>> ==9657== by 0x81855CE: ldap_back_op_result (bind.c:1823) >>> ==9657== by 0x8184C3D: ldap_back_dobind_int (bind.c:1486) >>> ==9657== by 0x8184D41: ldap_back_dobind (bind.c:1520) >>> ==9657== by 0x812C9F7: ldap_back_search (search.c:174) >>> ==9657== by 0x80F7DF4: glue_sub_search (backglue.c:340) >>> ==9657== by 0x80F8458: glue_op_search (backglue.c:467) >>> ==9657== by 0x80FACE3: overlay_op_walk (backover.c:657) >>> ==9657== by 0x80FAF18: over_op_func (backover.c:719) >>> ==9657== by 0x80FAF9C: over_op_search (backover.c:741) >>> ==9657== by 0x8087ADB: fe_op_search (search.c:366) >>> ==9657== by 0x80FAD63: overlay_op_walk (backover.c:667) >>> ==9657== by 0x80FAF18: over_op_func (backover.c:719) >>> ==9657== by 0x80FAF9C: over_op_search (backover.c:741) >>> ==9657== >>> ==9657== Invalid free() / delete / delete[] >>> ==9657== at 0x4004FDA: free (vg_replace_malloc.c:233) >>> ==9657== by 0x82407C9: ber_memfree_x (memory.c:152) >>> ==9657== by 0x80E522B: slap_sl_free (sl_malloc.c:451) >>> ==9657== by 0x80874D3: do_search (search.c:224) >>> ==9657== by 0x8084347: connection_operation (connection.c:1084) >>> ==9657== by 0x8084834: connection_read_thread (connection.c:1211) >>> ==9657== by 0x820F3D4: ldap_int_thread_pool_wrapper (tpool.c:663) >>> ==9657== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) >>> ==9657== by 0xD42DBD: clone (in /lib/libc-2.5.so) >>> ==9657== Address 0x5595E60 is 0 bytes inside a block of size 29 free'd >>> ==9657== at 0x4004FDA: free (vg_replace_malloc.c:233) >>> ==9657== by 0x82407C9: ber_memfree_x (memory.c:152) >>> ==9657== by 0x80A59E5: ch_free (ch_malloc.c:139) >>> ==9657== by 0x81E1D90: rwm_op_cleanup (rwm.c:69) >>> ==9657== by 0x80976CD: slap_cleanup_play (result.c:341) >>> ==9657== by 0x8097DEA: send_ldap_response (result.c:522) >>> ==9657== by 0x809850E: slap_send_ldap_result (result.c:642) >>> ==9657== by 0x81855CE: ldap_back_op_result (bind.c:1823) >>> ==9657== by 0x8184C3D: ldap_back_dobind_int (bind.c:1486) >>> ==9657== by 0x8184D41: ldap_back_dobind (bind.c:1520) >>> ==9657== by 0x812C9F7: ldap_back_search (search.c:174) >>> ==9657== by 0x80F7DF4: glue_sub_search (backglue.c:340) >>> ==9657== by 0x80F8458: glue_op_search (backglue.c:467) >>> ==9657== by 0x80FACE3: overlay_op_walk (backover.c:657) >>> ==9657== by 0x80FAF18: over_op_func (backover.c:719) >>> ==9657== by 0x80FAF9C: over_op_search (backover.c:741) >>> ==9657== by 0x8087ADB: fe_op_search (search.c:366) >>> ==9657== by 0x80FAD63: overlay_op_walk (backover.c:667) >>> ==9657== by 0x80FAF18: over_op_func (backover.c:719) >>> ==9657== by 0x80FAF9C: over_op_search (backover.c:741) >>> conn=3 op=1 ldap_back_retry: retrying URI="ldap://localhost:9011" >>> DN="cn=manager,dc=example,dc=com" >>> ==9657== Warning: invalid file descriptor -1 in syscall close() >>> ==9657== Warning: invalid file descriptor -1 in syscall close() >>> ==9657== Warning: invalid file descriptor -1 in syscall close() >>> ==9657== Warning: invalid file descriptor -1 in syscall close() >>> ==9657== Warning: invalid file descriptor -1 in syscall close() >>> ==9657== Warning: invalid file descriptor -1 in syscall close() >>> ==9657== Warning: invalid file descriptor -1 in syscall close() >>> ==9657== Warning: invalid file descriptor -1 in syscall close() >>> slapd stopped. >>> ==9657== >>> ==9657== ERROR SUMMARY: 7 errors from 5 contexts (suppressed: 36 from 1) >>> ==9657== malloc/free: in use at exit: 1,127 bytes in 15 blocks. >>> ==9657== malloc/free: 34,414 allocs, 34,403 frees, 12,376,432 bytes >>> allocated. >>> ==9657== For counts of detected errors, rerun with: -v >>> ==9657== searching for pointers to 15 not-freed blocks. >>> ==9657== checked 774,072 bytes. >>> >>> Apparently, the listener is freed while some thread is still using it. >> >> Since that can only occur during shutdown, I don't think it's really a >> high priority problem. More to the point, it will not cause any heap >> corruption. The serious problem is in thread 5, where rwm_op_cleanup >> frees a DN that do_search also tries to free. It looks like >> rwm_op_cleanup is badly broken here, it apparently should be checking to >> make sure ros->ro_dn is != ros->r_dn before freeing r_dn (and ndn). > > With the latest rwm revision, I still get the glibc corruption: > > PID=15912 - Search(500): base="o=Example,c=US" scope=sub > filter="(cn=Alumni Assoc Staff)" attrs=cn (more...). > > [quanah@tribes tests]$ *** glibc detected *** corrupted double-linked > list: 0x0000003bf99316b8 *** > > when I hit control-C during the search. Longer backtrace: Loaded symbols for /lib64/libgcc_s.so.1 #0 0x0000003bf972e25d in raise () from /lib64/tls/libc.so.6 (gdb) bt #0 0x0000003bf972e25d in raise () from /lib64/tls/libc.so.6 #1 0x0000003bf972fa5e in abort () from /lib64/tls/libc.so.6 #2 0x0000003bf97635e1 in __libc_message () from /lib64/tls/libc.so.6 #3 0x0000003bf9768a78 in malloc_consolidate () from /lib64/tls/libc.so.6 #4 0x0000003bf97698a9 in _int_malloc () from /lib64/tls/libc.so.6 #5 0x0000003bf976b682 in malloc () from /lib64/tls/libc.so.6 #6 0x0000002a956bc46d in ber_memalloc_x (s=4060, ctx=0x0) at memory.c:226 #7 0x0000002a956bc5b1 in ber_memrealloc_x (p=0x0, s=4060, ctx=0x0) at memory.c:304 #8 0x0000002a956ba5ef in ber_realloc (ber=0x7ce520, len=1) at io.c:155 #9 0x0000002a956ba49b in ber_write (ber=0x7ce520, buf=0x42001010 "\002ï¿½\177@", len=1, nosos=0) at io.c:114 #10 0x0000002a956b8145 in ber_put_tag (ber=0x7ce520, tag=0, nosos=0) at encode.c:100 #11 0x0000002a956b877e in ber_put_int_or_enum (ber=0x7ce520, num=6, tag=2) at encode.c:284 #12 0x0000002a956b8933 in ber_put_int (ber=0x7ce520, num=6, tag=2) at encode.c:333 #13 0x0000002a956b99f7 in ber_printf (ber=0x7ce520, fmt=0x2a955a1629 "iti") at encode.c:774 #14 0x0000002a95574f68 in do_abandon (ld=0x81f9f0, origid=5, msgid=5, sctrls=0x0, sendabandon=1) at abandon.c:243 #15 0x0000002a95574c49 in ldap_abandon_ext (ld=0x81f9f0, msgid=5, sctrls=0x0, cctrls=0x0) at abandon.c:80 #16 0x0000002a974ac864 in ldap_back_cancel (lc=0x81f5d0, op=0x7bab00, rs=0x42002cc0, msgid=5, sendok=LDAP_BACK_DONTSEND) at bind.c:1607 #17 0x0000002a974a7d02 in ldap_back_search (op=0x7bab00, rs=0x42002cc0) at search.c:287 #18 0x00000000004ac45d in glue_sub_search (op=0x7bab00, rs=0x42002cc0, b0=0x42001740, on=0x6c1e70) at backglue.c:340 #19 0x00000000004aca5f in glue_op_search (op=0x7bab00, rs=0x42002cc0) at backglue.c:452 #20 0x00000000004afacf in overlay_op_walk (op=0x7bab00, rs=0x42002cc0, which=op_search, oi=0x6c1c90, on=0x6c1e70) at backover.c:657 #21 0x00000000004afd2b in over_op_func (op=0x7bab00, rs=0x42002cc0, which=op_search) at backover.c:719 #22 0x00000000004afdc1 in over_op_search (op=0x7bab00, rs=0x42002cc0) at backover.c:741 #23 0x0000000000435ea8 in fe_op_search (op=0x7bab00, rs=0x42002cc0) at search.c:366 #24 0x00000000004afb63 in overlay_op_walk (op=0x7bab00, rs=0x42002cc0, which=op_search, oi=0x702480, on=0x0) at backover.c:667 #25 0x00000000004afd2b in over_op_func (op=0x7bab00, rs=0x42002cc0, which=op_search) at backover.c:719 #26 0x00000000004afdc1 in over_op_search (op=0x7bab00, rs=0x42002cc0) at backover.c:741 #27 0x0000000000435865 in do_search (op=0x7bab00, rs=0x42002cc0) at search.c:217 #28 0x0000000000432839 in connection_operation (ctx=0x42002e20, arg_v=0x7bab00) at connection.c:1084 #29 0x0000000000432d75 in connection_read_thread (ctx=0x42002e20, argv=0x2b) at connection.c:1211 #30 0x0000002a95568cd0 in ldap_int_thread_pool_wrapper (xpool=0x6a3500) at tpool.c:663 #31 0x0000003bfa006137 in start_thread () from /lib64/tls/libpthread.so.0 #32 0x0000003bf97c7533 in clone () from /lib64/tls/libc.so.6 (gdb) info threads 15 process 25502 0x0000003bfa00714b in pthread_join () from /lib64/tls/libpthread.so.0 14 process 25532 0x0000003bfa008b3a in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/tls/libpthread.so.0 13 process 25554 0x0000003bf97be5e2 in poll () from /lib64/tls/libc.so.6 12 process 25555 0x0000003bf97be5e2 in poll () from /lib64/tls/libc.so.6 11 process 25821 0x0000003bf97be5e2 in poll () from /lib64/tls/libc.so.6 10 process 25834 0x0000003bf97be5e2 in poll () from /lib64/tls/libc.so.6 9 process 25852 0x0000003bf97be5e2 in poll () from /lib64/tls/libc.so.6 8 process 25869 0x0000003bf97be5e2 in poll () from /lib64/tls/libc.so.6 7 process 25870 0x0000003bf97be5e2 in poll () from /lib64/tls/libc.so.6 6 process 25871 0x0000003bf97be5e2 in poll () from /lib64/tls/libc.so.6 5 process 25923 0x0000003bf97be5e2 in poll () from /lib64/tls/libc.so.6 4 process 25925 0x0000003bf97be5e2 in poll () from /lib64/tls/libc.so.6 3 process 25928 0x0000003bf97be5e2 in poll () from /lib64/tls/libc.so.6 2 process 25931 0x0000003bf97be5e2 in poll () from /lib64/tls/libc.so.6 * 1 process 25820 0x0000003bf972e25d in raise () from /lib64/tls/libc.so.6 --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5687) corrupted double-linked list on shutdown
by quanah＠zimbra.com 05 Sep '08

05 Sep '08

--On Saturday, September 06, 2008 12:08 AM +0000 hyc(a)symas.com wrote: > ando(a)sys-net.it wrote: >> h.b.furuseth(a)usit.uio.no wrote: >>>> [quanah@freelancer tests]$ *** glibc detected *** >>>> /home/quanah/q/openldap-2.4.12/servers/slapd/.libs/lt-slapd: corrupted >>>> double-linked list: 0x000000000d28a430 *** >>> This message comes from glibc malloc. Its data structures are >>> corrupted. >>> >>> I couldn't figure out much from the the valgrind output. >>> But you'll get more frequent mallocs with CPPFLAGS=-DSLAP_NO_SL_MALLOC, >>> if that code isn't rotted - maybe that'll bring out the problem in >>> another guise. If that code still works, I don't remember. >> >> Here's my output after compiling with -DSLAP_NO_SL_MALLOC=1, running >> test039 under valgrind and suddenly killing the process: >> >> ==9657== Memcheck, a memory error detector. >> ==9657== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al. >> ==9657== Using LibVEX rev 1658, a library for dynamic binary translation. >> ==9657== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP. >> ==9657== Using valgrind-3.2.1, a dynamic binary instrumentation >> framework. ==9657== Copyright (C) 2000-2006, and GNU GPL'd, by Julian >> Seward et al. ==9657== For more details, rerun with: -v >> ==9657== >> @(#) $OpenLDAP: slapd 2.X (Sep 6 2008 01:35:19) $ >> masarati@odino.intra.sys-net.it:/home/masarati/Lavoro/sysnet/Ldap/ldap- >> devel/servers/slapd slapd starting >> daemon: shutdown requested and initiated. >> slapd shutdown: waiting for 8 threads to terminate >> ==9657== Thread 3: >> ==9657== Invalid read of size 4 >> ==9657== at 0x807EF03: slap_listener (daemon.c:1754) >> ==9657== by 0x807F9AC: slap_listener_thread (daemon.c:1997) >> ==9657== by 0x820F3D4: ldap_int_thread_pool_wrapper (tpool.c:663) >> ==9657== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) >> ==9657== by 0xD42DBD: clone (in /lib/libc-2.5.so) >> ==9657== Address 0x415D3A8 is 32 bytes inside a block of size 164 free'd >> ==9657== at 0x4004FDA: free (vg_replace_malloc.c:233) >> ==9657== by 0x82407C9: ber_memfree_x (memory.c:152) >> ==9657== by 0x80A59E5: ch_free (ch_malloc.c:139) >> ==9657== by 0x807EDF8: close_listeners (daemon.c:1703) >> ==9657== by 0x808137F: slapd_daemon_task (daemon.c:2578) >> ==9657== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) >> ==9657== by 0xD42DBD: clone (in /lib/libc-2.5.so) >> ==9657== >> ==9657== Invalid write of size 4 >> ==9657== at 0x807EF22: slap_listener (daemon.c:1759) >> ==9657== by 0x807F9AC: slap_listener_thread (daemon.c:1997) >> ==9657== by 0x820F3D4: ldap_int_thread_pool_wrapper (tpool.c:663) >> ==9657== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) >> ==9657== by 0xD42DBD: clone (in /lib/libc-2.5.so) >> ==9657== Address 0x415D3A4 is 28 bytes inside a block of size 164 free'd >> ==9657== at 0x4004FDA: free (vg_replace_malloc.c:233) >> ==9657== by 0x82407C9: ber_memfree_x (memory.c:152) >> ==9657== by 0x80A59E5: ch_free (ch_malloc.c:139) >> ==9657== by 0x807EDF8: close_listeners (daemon.c:1703) >> ==9657== by 0x808137F: slapd_daemon_task (daemon.c:2578) >> ==9657== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) >> ==9657== by 0xD42DBD: clone (in /lib/libc-2.5.so) >> ==9657== >> ==9657== Invalid read of size 4 >> ==9657== at 0x807EFCD: slap_listener (daemon.c:1781) >> ==9657== by 0x807F9AC: slap_listener_thread (daemon.c:1997) >> ==9657== by 0x820F3D4: ldap_int_thread_pool_wrapper (tpool.c:663) >> ==9657== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) >> ==9657== by 0xD42DBD: clone (in /lib/libc-2.5.so) >> ==9657== Address 0x415D3A8 is 32 bytes inside a block of size 164 free'd >> ==9657== at 0x4004FDA: free (vg_replace_malloc.c:233) >> ==9657== by 0x82407C9: ber_memfree_x (memory.c:152) >> ==9657== by 0x80A59E5: ch_free (ch_malloc.c:139) >> ==9657== by 0x807EDF8: close_listeners (daemon.c:1703) >> ==9657== by 0x808137F: slapd_daemon_task (daemon.c:2578) >> ==9657== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) >> ==9657== by 0xD42DBD: clone (in /lib/libc-2.5.so) >> daemon: accept(7) failed errno=9 (Bad file descriptor) >> ==9657== >> ==9657== Thread 5: >> ==9657== Invalid free() / delete / delete[] >> ==9657== at 0x4004FDA: free (vg_replace_malloc.c:233) >> ==9657== by 0x82407C9: ber_memfree_x (memory.c:152) >> ==9657== by 0x80E522B: slap_sl_free (sl_malloc.c:451) >> ==9657== by 0x80874AF: do_search (search.c:221) >> ==9657== by 0x8084347: connection_operation (connection.c:1084) >> ==9657== by 0x8084834: connection_read_thread (connection.c:1211) >> ==9657== by 0x820F3D4: ldap_int_thread_pool_wrapper (tpool.c:663) >> ==9657== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) >> ==9657== by 0xD42DBD: clone (in /lib/libc-2.5.so) >> ==9657== Address 0x5595D60 is 0 bytes inside a block of size 29 free'd >> ==9657== at 0x4004FDA: free (vg_replace_malloc.c:233) >> ==9657== by 0x82407C9: ber_memfree_x (memory.c:152) >> ==9657== by 0x80A59E5: ch_free (ch_malloc.c:139) >> ==9657== by 0x81E1D64: rwm_op_cleanup (rwm.c:64) >> ==9657== by 0x80976CD: slap_cleanup_play (result.c:341) >> ==9657== by 0x8097DEA: send_ldap_response (result.c:522) >> ==9657== by 0x809850E: slap_send_ldap_result (result.c:642) >> ==9657== by 0x81855CE: ldap_back_op_result (bind.c:1823) >> ==9657== by 0x8184C3D: ldap_back_dobind_int (bind.c:1486) >> ==9657== by 0x8184D41: ldap_back_dobind (bind.c:1520) >> ==9657== by 0x812C9F7: ldap_back_search (search.c:174) >> ==9657== by 0x80F7DF4: glue_sub_search (backglue.c:340) >> ==9657== by 0x80F8458: glue_op_search (backglue.c:467) >> ==9657== by 0x80FACE3: overlay_op_walk (backover.c:657) >> ==9657== by 0x80FAF18: over_op_func (backover.c:719) >> ==9657== by 0x80FAF9C: over_op_search (backover.c:741) >> ==9657== by 0x8087ADB: fe_op_search (search.c:366) >> ==9657== by 0x80FAD63: overlay_op_walk (backover.c:667) >> ==9657== by 0x80FAF18: over_op_func (backover.c:719) >> ==9657== by 0x80FAF9C: over_op_search (backover.c:741) >> ==9657== >> ==9657== Invalid free() / delete / delete[] >> ==9657== at 0x4004FDA: free (vg_replace_malloc.c:233) >> ==9657== by 0x82407C9: ber_memfree_x (memory.c:152) >> ==9657== by 0x80E522B: slap_sl_free (sl_malloc.c:451) >> ==9657== by 0x80874D3: do_search (search.c:224) >> ==9657== by 0x8084347: connection_operation (connection.c:1084) >> ==9657== by 0x8084834: connection_read_thread (connection.c:1211) >> ==9657== by 0x820F3D4: ldap_int_thread_pool_wrapper (tpool.c:663) >> ==9657== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) >> ==9657== by 0xD42DBD: clone (in /lib/libc-2.5.so) >> ==9657== Address 0x5595E60 is 0 bytes inside a block of size 29 free'd >> ==9657== at 0x4004FDA: free (vg_replace_malloc.c:233) >> ==9657== by 0x82407C9: ber_memfree_x (memory.c:152) >> ==9657== by 0x80A59E5: ch_free (ch_malloc.c:139) >> ==9657== by 0x81E1D90: rwm_op_cleanup (rwm.c:69) >> ==9657== by 0x80976CD: slap_cleanup_play (result.c:341) >> ==9657== by 0x8097DEA: send_ldap_response (result.c:522) >> ==9657== by 0x809850E: slap_send_ldap_result (result.c:642) >> ==9657== by 0x81855CE: ldap_back_op_result (bind.c:1823) >> ==9657== by 0x8184C3D: ldap_back_dobind_int (bind.c:1486) >> ==9657== by 0x8184D41: ldap_back_dobind (bind.c:1520) >> ==9657== by 0x812C9F7: ldap_back_search (search.c:174) >> ==9657== by 0x80F7DF4: glue_sub_search (backglue.c:340) >> ==9657== by 0x80F8458: glue_op_search (backglue.c:467) >> ==9657== by 0x80FACE3: overlay_op_walk (backover.c:657) >> ==9657== by 0x80FAF18: over_op_func (backover.c:719) >> ==9657== by 0x80FAF9C: over_op_search (backover.c:741) >> ==9657== by 0x8087ADB: fe_op_search (search.c:366) >> ==9657== by 0x80FAD63: overlay_op_walk (backover.c:667) >> ==9657== by 0x80FAF18: over_op_func (backover.c:719) >> ==9657== by 0x80FAF9C: over_op_search (backover.c:741) >> conn=3 op=1 ldap_back_retry: retrying URI="ldap://localhost:9011" >> DN="cn=manager,dc=example,dc=com" >> ==9657== Warning: invalid file descriptor -1 in syscall close() >> ==9657== Warning: invalid file descriptor -1 in syscall close() >> ==9657== Warning: invalid file descriptor -1 in syscall close() >> ==9657== Warning: invalid file descriptor -1 in syscall close() >> ==9657== Warning: invalid file descriptor -1 in syscall close() >> ==9657== Warning: invalid file descriptor -1 in syscall close() >> ==9657== Warning: invalid file descriptor -1 in syscall close() >> ==9657== Warning: invalid file descriptor -1 in syscall close() >> slapd stopped. >> ==9657== >> ==9657== ERROR SUMMARY: 7 errors from 5 contexts (suppressed: 36 from 1) >> ==9657== malloc/free: in use at exit: 1,127 bytes in 15 blocks. >> ==9657== malloc/free: 34,414 allocs, 34,403 frees, 12,376,432 bytes >> allocated. >> ==9657== For counts of detected errors, rerun with: -v >> ==9657== searching for pointers to 15 not-freed blocks. >> ==9657== checked 774,072 bytes. >> >> Apparently, the listener is freed while some thread is still using it. > > Since that can only occur during shutdown, I don't think it's really a > high priority problem. More to the point, it will not cause any heap > corruption. The serious problem is in thread 5, where rwm_op_cleanup > frees a DN that do_search also tries to free. It looks like > rwm_op_cleanup is badly broken here, it apparently should be checking to > make sure ros->ro_dn is != ros->r_dn before freeing r_dn (and ndn). With the latest rwm revision, I still get the glibc corruption: PID=15912 - Search(500): base="o=Example,c=US" scope=sub filter="(cn=Alumni Assoc Staff)" attrs=cn (more...). [quanah@tribes tests]$ *** glibc detected *** corrupted double-linked list: 0x0000003bf99316b8 *** when I hit control-C during the search. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5687) corrupted double-linked list on shutdown
by hyc＠symas.com 05 Sep '08

05 Sep '08

ando(a)sys-net.it wrote: > h.b.furuseth(a)usit.uio.no wrote: >>> [quanah@freelancer tests]$ *** glibc detected *** >>> /home/quanah/q/openldap-2.4.12/servers/slapd/.libs/lt-slapd: corrupted >>> double-linked list: 0x000000000d28a430 *** >> This message comes from glibc malloc. Its data structures are >> corrupted. >> >> I couldn't figure out much from the the valgrind output. >> But you'll get more frequent mallocs with CPPFLAGS=-DSLAP_NO_SL_MALLOC, >> if that code isn't rotted - maybe that'll bring out the problem in >> another guise. If that code still works, I don't remember. > > Here's my output after compiling with -DSLAP_NO_SL_MALLOC=1, running > test039 under valgrind and suddenly killing the process: > > ==9657== Memcheck, a memory error detector. > ==9657== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al. > ==9657== Using LibVEX rev 1658, a library for dynamic binary translation. > ==9657== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP. > ==9657== Using valgrind-3.2.1, a dynamic binary instrumentation framework. > ==9657== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al. > ==9657== For more details, rerun with: -v > ==9657== > @(#) $OpenLDAP: slapd 2.X (Sep 6 2008 01:35:19) $ > masarati@odino.intra.sys-net.it:/home/masarati/Lavoro/sysnet/Ldap/ldap-devel/servers/slapd > slapd starting > daemon: shutdown requested and initiated. > slapd shutdown: waiting for 8 threads to terminate > ==9657== Thread 3: > ==9657== Invalid read of size 4 > ==9657== at 0x807EF03: slap_listener (daemon.c:1754) > ==9657== by 0x807F9AC: slap_listener_thread (daemon.c:1997) > ==9657== by 0x820F3D4: ldap_int_thread_pool_wrapper (tpool.c:663) > ==9657== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) > ==9657== by 0xD42DBD: clone (in /lib/libc-2.5.so) > ==9657== Address 0x415D3A8 is 32 bytes inside a block of size 164 free'd > ==9657== at 0x4004FDA: free (vg_replace_malloc.c:233) > ==9657== by 0x82407C9: ber_memfree_x (memory.c:152) > ==9657== by 0x80A59E5: ch_free (ch_malloc.c:139) > ==9657== by 0x807EDF8: close_listeners (daemon.c:1703) > ==9657== by 0x808137F: slapd_daemon_task (daemon.c:2578) > ==9657== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) > ==9657== by 0xD42DBD: clone (in /lib/libc-2.5.so) > ==9657== > ==9657== Invalid write of size 4 > ==9657== at 0x807EF22: slap_listener (daemon.c:1759) > ==9657== by 0x807F9AC: slap_listener_thread (daemon.c:1997) > ==9657== by 0x820F3D4: ldap_int_thread_pool_wrapper (tpool.c:663) > ==9657== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) > ==9657== by 0xD42DBD: clone (in /lib/libc-2.5.so) > ==9657== Address 0x415D3A4 is 28 bytes inside a block of size 164 free'd > ==9657== at 0x4004FDA: free (vg_replace_malloc.c:233) > ==9657== by 0x82407C9: ber_memfree_x (memory.c:152) > ==9657== by 0x80A59E5: ch_free (ch_malloc.c:139) > ==9657== by 0x807EDF8: close_listeners (daemon.c:1703) > ==9657== by 0x808137F: slapd_daemon_task (daemon.c:2578) > ==9657== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) > ==9657== by 0xD42DBD: clone (in /lib/libc-2.5.so) > ==9657== > ==9657== Invalid read of size 4 > ==9657== at 0x807EFCD: slap_listener (daemon.c:1781) > ==9657== by 0x807F9AC: slap_listener_thread (daemon.c:1997) > ==9657== by 0x820F3D4: ldap_int_thread_pool_wrapper (tpool.c:663) > ==9657== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) > ==9657== by 0xD42DBD: clone (in /lib/libc-2.5.so) > ==9657== Address 0x415D3A8 is 32 bytes inside a block of size 164 free'd > ==9657== at 0x4004FDA: free (vg_replace_malloc.c:233) > ==9657== by 0x82407C9: ber_memfree_x (memory.c:152) > ==9657== by 0x80A59E5: ch_free (ch_malloc.c:139) > ==9657== by 0x807EDF8: close_listeners (daemon.c:1703) > ==9657== by 0x808137F: slapd_daemon_task (daemon.c:2578) > ==9657== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) > ==9657== by 0xD42DBD: clone (in /lib/libc-2.5.so) > daemon: accept(7) failed errno=9 (Bad file descriptor) > ==9657== > ==9657== Thread 5: > ==9657== Invalid free() / delete / delete[] > ==9657== at 0x4004FDA: free (vg_replace_malloc.c:233) > ==9657== by 0x82407C9: ber_memfree_x (memory.c:152) > ==9657== by 0x80E522B: slap_sl_free (sl_malloc.c:451) > ==9657== by 0x80874AF: do_search (search.c:221) > ==9657== by 0x8084347: connection_operation (connection.c:1084) > ==9657== by 0x8084834: connection_read_thread (connection.c:1211) > ==9657== by 0x820F3D4: ldap_int_thread_pool_wrapper (tpool.c:663) > ==9657== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) > ==9657== by 0xD42DBD: clone (in /lib/libc-2.5.so) > ==9657== Address 0x5595D60 is 0 bytes inside a block of size 29 free'd > ==9657== at 0x4004FDA: free (vg_replace_malloc.c:233) > ==9657== by 0x82407C9: ber_memfree_x (memory.c:152) > ==9657== by 0x80A59E5: ch_free (ch_malloc.c:139) > ==9657== by 0x81E1D64: rwm_op_cleanup (rwm.c:64) > ==9657== by 0x80976CD: slap_cleanup_play (result.c:341) > ==9657== by 0x8097DEA: send_ldap_response (result.c:522) > ==9657== by 0x809850E: slap_send_ldap_result (result.c:642) > ==9657== by 0x81855CE: ldap_back_op_result (bind.c:1823) > ==9657== by 0x8184C3D: ldap_back_dobind_int (bind.c:1486) > ==9657== by 0x8184D41: ldap_back_dobind (bind.c:1520) > ==9657== by 0x812C9F7: ldap_back_search (search.c:174) > ==9657== by 0x80F7DF4: glue_sub_search (backglue.c:340) > ==9657== by 0x80F8458: glue_op_search (backglue.c:467) > ==9657== by 0x80FACE3: overlay_op_walk (backover.c:657) > ==9657== by 0x80FAF18: over_op_func (backover.c:719) > ==9657== by 0x80FAF9C: over_op_search (backover.c:741) > ==9657== by 0x8087ADB: fe_op_search (search.c:366) > ==9657== by 0x80FAD63: overlay_op_walk (backover.c:667) > ==9657== by 0x80FAF18: over_op_func (backover.c:719) > ==9657== by 0x80FAF9C: over_op_search (backover.c:741) > ==9657== > ==9657== Invalid free() / delete / delete[] > ==9657== at 0x4004FDA: free (vg_replace_malloc.c:233) > ==9657== by 0x82407C9: ber_memfree_x (memory.c:152) > ==9657== by 0x80E522B: slap_sl_free (sl_malloc.c:451) > ==9657== by 0x80874D3: do_search (search.c:224) > ==9657== by 0x8084347: connection_operation (connection.c:1084) > ==9657== by 0x8084834: connection_read_thread (connection.c:1211) > ==9657== by 0x820F3D4: ldap_int_thread_pool_wrapper (tpool.c:663) > ==9657== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) > ==9657== by 0xD42DBD: clone (in /lib/libc-2.5.so) > ==9657== Address 0x5595E60 is 0 bytes inside a block of size 29 free'd > ==9657== at 0x4004FDA: free (vg_replace_malloc.c:233) > ==9657== by 0x82407C9: ber_memfree_x (memory.c:152) > ==9657== by 0x80A59E5: ch_free (ch_malloc.c:139) > ==9657== by 0x81E1D90: rwm_op_cleanup (rwm.c:69) > ==9657== by 0x80976CD: slap_cleanup_play (result.c:341) > ==9657== by 0x8097DEA: send_ldap_response (result.c:522) > ==9657== by 0x809850E: slap_send_ldap_result (result.c:642) > ==9657== by 0x81855CE: ldap_back_op_result (bind.c:1823) > ==9657== by 0x8184C3D: ldap_back_dobind_int (bind.c:1486) > ==9657== by 0x8184D41: ldap_back_dobind (bind.c:1520) > ==9657== by 0x812C9F7: ldap_back_search (search.c:174) > ==9657== by 0x80F7DF4: glue_sub_search (backglue.c:340) > ==9657== by 0x80F8458: glue_op_search (backglue.c:467) > ==9657== by 0x80FACE3: overlay_op_walk (backover.c:657) > ==9657== by 0x80FAF18: over_op_func (backover.c:719) > ==9657== by 0x80FAF9C: over_op_search (backover.c:741) > ==9657== by 0x8087ADB: fe_op_search (search.c:366) > ==9657== by 0x80FAD63: overlay_op_walk (backover.c:667) > ==9657== by 0x80FAF18: over_op_func (backover.c:719) > ==9657== by 0x80FAF9C: over_op_search (backover.c:741) > conn=3 op=1 ldap_back_retry: retrying URI="ldap://localhost:9011" > DN="cn=manager,dc=example,dc=com" > ==9657== Warning: invalid file descriptor -1 in syscall close() > ==9657== Warning: invalid file descriptor -1 in syscall close() > ==9657== Warning: invalid file descriptor -1 in syscall close() > ==9657== Warning: invalid file descriptor -1 in syscall close() > ==9657== Warning: invalid file descriptor -1 in syscall close() > ==9657== Warning: invalid file descriptor -1 in syscall close() > ==9657== Warning: invalid file descriptor -1 in syscall close() > ==9657== Warning: invalid file descriptor -1 in syscall close() > slapd stopped. > ==9657== > ==9657== ERROR SUMMARY: 7 errors from 5 contexts (suppressed: 36 from 1) > ==9657== malloc/free: in use at exit: 1,127 bytes in 15 blocks. > ==9657== malloc/free: 34,414 allocs, 34,403 frees, 12,376,432 bytes > allocated. > ==9657== For counts of detected errors, rerun with: -v > ==9657== searching for pointers to 15 not-freed blocks. > ==9657== checked 774,072 bytes. > > Apparently, the listener is freed while some thread is still using it. Since that can only occur during shutdown, I don't think it's really a high priority problem. More to the point, it will not cause any heap corruption. The serious problem is in thread 5, where rwm_op_cleanup frees a DN that do_search also tries to free. It looks like rwm_op_cleanup is badly broken here, it apparently should be checking to make sure ros->ro_dn is != ros->r_dn before freeing r_dn (and ndn). -- -- 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

Searching for (objectClass=UNDEFINED)...
by Pierangelo Masarati 05 Sep '08

05 Sep '08

... returns success with the text "value does not conform to assertion syntax"; is this the intended behavior, or should the filter error go completely unnoticed, and the text rather be logged, or what? The current behavior seems to be a consequence of servers/slapd/ava.c 1.45 -> 1.46 (by hyc) returning LDAP_SUCCESS instead of rc, without intentionally?) clearing text. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

5 8

Re: (ITS#5687) corrupted double-linked list on shutdown
by ando＠sys-net.it 05 Sep '08

05 Sep '08

h.b.furuseth(a)usit.uio.no wrote: >> [quanah@freelancer tests]$ *** glibc detected *** >> /home/quanah/q/openldap-2.4.12/servers/slapd/.libs/lt-slapd: corrupted >> double-linked list: 0x000000000d28a430 *** > > This message comes from glibc malloc. Its data structures are > corrupted. > > I couldn't figure out much from the the valgrind output. > But you'll get more frequent mallocs with CPPFLAGS=-DSLAP_NO_SL_MALLOC, > if that code isn't rotted - maybe that'll bring out the problem in > another guise. If that code still works, I don't remember. Here's my output after compiling with -DSLAP_NO_SL_MALLOC=1, running test039 under valgrind and suddenly killing the process: ==9657== Memcheck, a memory error detector. ==9657== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al. ==9657== Using LibVEX rev 1658, a library for dynamic binary translation. ==9657== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP. ==9657== Using valgrind-3.2.1, a dynamic binary instrumentation framework. ==9657== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al. ==9657== For more details, rerun with: -v ==9657== @(#) $OpenLDAP: slapd 2.X (Sep 6 2008 01:35:19) $ masarati@odino.intra.sys-net.it:/home/masarati/Lavoro/sysnet/Ldap/ldap-devel/servers/slapd slapd starting daemon: shutdown requested and initiated. slapd shutdown: waiting for 8 threads to terminate ==9657== Thread 3: ==9657== Invalid read of size 4 ==9657== at 0x807EF03: slap_listener (daemon.c:1754) ==9657== by 0x807F9AC: slap_listener_thread (daemon.c:1997) ==9657== by 0x820F3D4: ldap_int_thread_pool_wrapper (tpool.c:663) ==9657== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) ==9657== by 0xD42DBD: clone (in /lib/libc-2.5.so) ==9657== Address 0x415D3A8 is 32 bytes inside a block of size 164 free'd ==9657== at 0x4004FDA: free (vg_replace_malloc.c:233) ==9657== by 0x82407C9: ber_memfree_x (memory.c:152) ==9657== by 0x80A59E5: ch_free (ch_malloc.c:139) ==9657== by 0x807EDF8: close_listeners (daemon.c:1703) ==9657== by 0x808137F: slapd_daemon_task (daemon.c:2578) ==9657== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) ==9657== by 0xD42DBD: clone (in /lib/libc-2.5.so) ==9657== ==9657== Invalid write of size 4 ==9657== at 0x807EF22: slap_listener (daemon.c:1759) ==9657== by 0x807F9AC: slap_listener_thread (daemon.c:1997) ==9657== by 0x820F3D4: ldap_int_thread_pool_wrapper (tpool.c:663) ==9657== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) ==9657== by 0xD42DBD: clone (in /lib/libc-2.5.so) ==9657== Address 0x415D3A4 is 28 bytes inside a block of size 164 free'd ==9657== at 0x4004FDA: free (vg_replace_malloc.c:233) ==9657== by 0x82407C9: ber_memfree_x (memory.c:152) ==9657== by 0x80A59E5: ch_free (ch_malloc.c:139) ==9657== by 0x807EDF8: close_listeners (daemon.c:1703) ==9657== by 0x808137F: slapd_daemon_task (daemon.c:2578) ==9657== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) ==9657== by 0xD42DBD: clone (in /lib/libc-2.5.so) ==9657== ==9657== Invalid read of size 4 ==9657== at 0x807EFCD: slap_listener (daemon.c:1781) ==9657== by 0x807F9AC: slap_listener_thread (daemon.c:1997) ==9657== by 0x820F3D4: ldap_int_thread_pool_wrapper (tpool.c:663) ==9657== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) ==9657== by 0xD42DBD: clone (in /lib/libc-2.5.so) ==9657== Address 0x415D3A8 is 32 bytes inside a block of size 164 free'd ==9657== at 0x4004FDA: free (vg_replace_malloc.c:233) ==9657== by 0x82407C9: ber_memfree_x (memory.c:152) ==9657== by 0x80A59E5: ch_free (ch_malloc.c:139) ==9657== by 0x807EDF8: close_listeners (daemon.c:1703) ==9657== by 0x808137F: slapd_daemon_task (daemon.c:2578) ==9657== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) ==9657== by 0xD42DBD: clone (in /lib/libc-2.5.so) daemon: accept(7) failed errno=9 (Bad file descriptor) ==9657== ==9657== Thread 5: ==9657== Invalid free() / delete / delete[] ==9657== at 0x4004FDA: free (vg_replace_malloc.c:233) ==9657== by 0x82407C9: ber_memfree_x (memory.c:152) ==9657== by 0x80E522B: slap_sl_free (sl_malloc.c:451) ==9657== by 0x80874AF: do_search (search.c:221) ==9657== by 0x8084347: connection_operation (connection.c:1084) ==9657== by 0x8084834: connection_read_thread (connection.c:1211) ==9657== by 0x820F3D4: ldap_int_thread_pool_wrapper (tpool.c:663) ==9657== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) ==9657== by 0xD42DBD: clone (in /lib/libc-2.5.so) ==9657== Address 0x5595D60 is 0 bytes inside a block of size 29 free'd ==9657== at 0x4004FDA: free (vg_replace_malloc.c:233) ==9657== by 0x82407C9: ber_memfree_x (memory.c:152) ==9657== by 0x80A59E5: ch_free (ch_malloc.c:139) ==9657== by 0x81E1D64: rwm_op_cleanup (rwm.c:64) ==9657== by 0x80976CD: slap_cleanup_play (result.c:341) ==9657== by 0x8097DEA: send_ldap_response (result.c:522) ==9657== by 0x809850E: slap_send_ldap_result (result.c:642) ==9657== by 0x81855CE: ldap_back_op_result (bind.c:1823) ==9657== by 0x8184C3D: ldap_back_dobind_int (bind.c:1486) ==9657== by 0x8184D41: ldap_back_dobind (bind.c:1520) ==9657== by 0x812C9F7: ldap_back_search (search.c:174) ==9657== by 0x80F7DF4: glue_sub_search (backglue.c:340) ==9657== by 0x80F8458: glue_op_search (backglue.c:467) ==9657== by 0x80FACE3: overlay_op_walk (backover.c:657) ==9657== by 0x80FAF18: over_op_func (backover.c:719) ==9657== by 0x80FAF9C: over_op_search (backover.c:741) ==9657== by 0x8087ADB: fe_op_search (search.c:366) ==9657== by 0x80FAD63: overlay_op_walk (backover.c:667) ==9657== by 0x80FAF18: over_op_func (backover.c:719) ==9657== by 0x80FAF9C: over_op_search (backover.c:741) ==9657== ==9657== Invalid free() / delete / delete[] ==9657== at 0x4004FDA: free (vg_replace_malloc.c:233) ==9657== by 0x82407C9: ber_memfree_x (memory.c:152) ==9657== by 0x80E522B: slap_sl_free (sl_malloc.c:451) ==9657== by 0x80874D3: do_search (search.c:224) ==9657== by 0x8084347: connection_operation (connection.c:1084) ==9657== by 0x8084834: connection_read_thread (connection.c:1211) ==9657== by 0x820F3D4: ldap_int_thread_pool_wrapper (tpool.c:663) ==9657== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) ==9657== by 0xD42DBD: clone (in /lib/libc-2.5.so) ==9657== Address 0x5595E60 is 0 bytes inside a block of size 29 free'd ==9657== at 0x4004FDA: free (vg_replace_malloc.c:233) ==9657== by 0x82407C9: ber_memfree_x (memory.c:152) ==9657== by 0x80A59E5: ch_free (ch_malloc.c:139) ==9657== by 0x81E1D90: rwm_op_cleanup (rwm.c:69) ==9657== by 0x80976CD: slap_cleanup_play (result.c:341) ==9657== by 0x8097DEA: send_ldap_response (result.c:522) ==9657== by 0x809850E: slap_send_ldap_result (result.c:642) ==9657== by 0x81855CE: ldap_back_op_result (bind.c:1823) ==9657== by 0x8184C3D: ldap_back_dobind_int (bind.c:1486) ==9657== by 0x8184D41: ldap_back_dobind (bind.c:1520) ==9657== by 0x812C9F7: ldap_back_search (search.c:174) ==9657== by 0x80F7DF4: glue_sub_search (backglue.c:340) ==9657== by 0x80F8458: glue_op_search (backglue.c:467) ==9657== by 0x80FACE3: overlay_op_walk (backover.c:657) ==9657== by 0x80FAF18: over_op_func (backover.c:719) ==9657== by 0x80FAF9C: over_op_search (backover.c:741) ==9657== by 0x8087ADB: fe_op_search (search.c:366) ==9657== by 0x80FAD63: overlay_op_walk (backover.c:667) ==9657== by 0x80FAF18: over_op_func (backover.c:719) ==9657== by 0x80FAF9C: over_op_search (backover.c:741) conn=3 op=1 ldap_back_retry: retrying URI="ldap://localhost:9011" DN="cn=manager,dc=example,dc=com" ==9657== Warning: invalid file descriptor -1 in syscall close() ==9657== Warning: invalid file descriptor -1 in syscall close() ==9657== Warning: invalid file descriptor -1 in syscall close() ==9657== Warning: invalid file descriptor -1 in syscall close() ==9657== Warning: invalid file descriptor -1 in syscall close() ==9657== Warning: invalid file descriptor -1 in syscall close() ==9657== Warning: invalid file descriptor -1 in syscall close() ==9657== Warning: invalid file descriptor -1 in syscall close() slapd stopped. ==9657== ==9657== ERROR SUMMARY: 7 errors from 5 contexts (suppressed: 36 from 1) ==9657== malloc/free: in use at exit: 1,127 bytes in 15 blocks. ==9657== malloc/free: 34,414 allocs, 34,403 frees, 12,376,432 bytes allocated. ==9657== For counts of detected errors, rerun with: -v ==9657== searching for pointers to 15 not-freed blocks. ==9657== checked 774,072 bytes. Apparently, the listener is freed while some thread is still using it. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5688) slapd returns success with message when an undefined objectClass is used in filter
by ando＠sys-net.it 05 Sep '08

05 Sep '08

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando See discussion here: <http://www.openldap.org/lists/openldap-bugs/200809/msg00029.html>. A fix is coming. p.

1 0

Re: (ITS#5687) corrupted double-linked list on shutdown
by quanah＠zimbra.com 05 Sep '08

05 Sep '08

--On Friday, September 05, 2008 8:52 PM +0000 h.b.furuseth(a)usit.uio.no wrote: >> [quanah@freelancer tests]$ *** glibc detected *** >> /home/quanah/q/openldap-2.4.12/servers/slapd/.libs/lt-slapd: corrupted >> double-linked list: 0x000000000d28a430 *** > > This message comes from glibc malloc. Its data structures are > corrupted. > > I couldn't figure out much from the the valgrind output. > But you'll get more frequent mallocs with CPPFLAGS=-DSLAP_NO_SL_MALLOC, > if that code isn't rotted - maybe that'll bring out the problem in > another guise. If that code still works, I don't remember. More notes: I get a core file every time I kill test039, even at stages outside the search. I only get the glibc error some of the time. Even testing with the latest and greatest valgrind, I don't see anything in its output file. I've managed to reproduce this behavior on both CentOS5 (64-bit) and RHEL4 (64-bit), which are running different kernels (and I assume glibc versions). backtrace on a non-glibc fault core: Core was generated by `/home/quanah/q/openldap-2.4.12/servers/slapd/.libs/lt-slapd -s0 -f /home/quanah'. Program terminated with signal 11, Segmentation fault. #0 0x00000038dc06ca17 in malloc_consolidate () from /lib64/libc.so.6 (gdb) bt #0 0x00000038dc06ca17 in malloc_consolidate () from /lib64/libc.so.6 #1 0x00000038dc06e607 in _int_free () from /lib64/libc.so.6 #2 0x00000038dc071fac in free () from /lib64/libc.so.6 #3 0x00002ae61bf34732 in ber_memfree_x (p=0x7302670, ctx=0x0) at memory.c:152 #4 0x000000000049d882 in slap_sl_mem_destroy (key=0x49da46, data=0x7302630) at sl_malloc.c:41 #5 0x00002ae61bce35c2 in ldap_pvt_thread_pool_context_reset (vctx=0x46da1dd0) at tpool.c:943 #6 0x00002ae61bce2a8a in ldap_int_thread_pool_wrapper (xpool=0x688e610) at tpool.c:677 #7 0x00000038dcc061b5 in start_thread () from /lib64/libpthread.so.0 #8 0x00000038dc0cd36d in clone () from /lib64/libc.so.6 #9 0x0000000000000000 in ?? () -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5687) corrupted double-linked list on shutdown
by hyc＠symas.com 05 Sep '08

05 Sep '08

h.b.furuseth(a)usit.uio.no wrote: >> [quanah@freelancer tests]$ *** glibc detected *** >> /home/quanah/q/openldap-2.4.12/servers/slapd/.libs/lt-slapd: corrupted >> double-linked list: 0x000000000d28a430 *** > > This message comes from glibc malloc. Its data structures are > corrupted. Right. But ordinarily, valgrind intercepts all mallocs and as such, any corruption should have been detected first by valgrind. The fact that valgrind didn't complain implies either a bug in valgrind or a bug in glibc. -- -- 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#5687) corrupted double-linked list on shutdown
by h.b.furuseth＠usit.uio.no 05 Sep '08

05 Sep '08

> [quanah@freelancer tests]$ *** glibc detected *** > /home/quanah/q/openldap-2.4.12/servers/slapd/.libs/lt-slapd: corrupted > double-linked list: 0x000000000d28a430 *** This message comes from glibc malloc. Its data structures are corrupted. I couldn't figure out much from the the valgrind output. But you'll get more frequent mallocs with CPPFLAGS=-DSLAP_NO_SL_MALLOC, if that code isn't rotted - maybe that'll bring out the problem in another guise. If that code still works, I don't remember. -- Hallvard

1 0

Re: (ITS#5687) corrupted double-linked list on shutdown
by quanah＠zimbra.com 05 Sep '08

05 Sep '08

--On Friday, September 05, 2008 7:03 PM +0000 quanah(a)zimbra.com wrote: With valgrind: [quanah@freelancer tests]$ *** glibc detected *** /home/quanah/q/openldap-2.4.12/servers/slapd/.libs/lt-slapd: corrupted double-linked list: 0x000000000d28a430 *** ======= Backtrace: ========= /lib64/libc.so.6[0x38dc06cbb7] /lib64/libc.so.6[0x38dc06ee92] /lib64/libc.so.6(__libc_calloc+0x96)[0x38dc070376] /lib64/ld-linux-x86-64.so.2[0x38dbc09c85] /lib64/ld-linux-x86-64.so.2[0x38dbc05abc] /lib64/ld-linux-x86-64.so.2[0x38dbc07cac] /lib64/ld-linux-x86-64.so.2[0x38dbc1088f] /lib64/ld-linux-x86-64.so.2[0x38dbc0cc36] /lib64/ld-linux-x86-64.so.2[0x38dbc1036c] /lib64/libc.so.6[0x38dc101320] /lib64/ld-linux-x86-64.so.2[0x38dbc0cc36] /lib64/libc.so.6(__libc_dlopen_mode+0x47)[0x38dc101487] /lib64/libpthread.so.0[0x38dcc0e40c] /lib64/libpthread.so.0[0x38dcc0e520] /lib64/libpthread.so.0(__pthread_unwind+0x40)[0x38dcc0c430] /lib64/libpthread.so.0[0x38dcc07335] /home/quanah/q/openldap-2.4.12/libraries/libldap_r/.libs/libldap_r-2.4-releng.so.2(ldap_pvt_thread_join+0x0)[0x2b537fec7e4a] /home/quanah/q/openldap-2.4.12/libraries/libldap_r/.libs/libldap_r-2.4-releng.so.2[0x2b537fec6b9c] /lib64/libpthread.so.0[0x38dcc061b5] /lib64/libc.so.6(clone+0x6d)[0x38dc0cd36d] ======= Memory map: ======== 00400000-00530000 r-xp 00000000 fd:00 32115271 /home/quanah/q/openldap-2.4.12/servers/slapd/.libs/lt-slapd 00730000-00739000 rw-p 00130000 fd:00 32115271 /home/quanah/q/openldap-2.4.12/servers/slapd/.libs/lt-slapd 00739000-0077d000 rw-p 00739000 00:00 0 0ce47000-0de31000 rw-p 0ce47000 00:00 0 40940000-40941000 ---p 40940000 00:00 0 40941000-41141000 rwxp 40941000 00:00 0 41141000-41142000 ---p 41141000 00:00 0 41142000-41942000 rwxp 41142000 00:00 0 41942000-41943000 ---p 41942000 00:00 0 41943000-42143000 rwxp 41943000 00:00 0 42143000-42144000 ---p 42143000 00:00 0 42144000-42944000 rwxp 42144000 00:00 0 42944000-42945000 ---p 42944000 00:00 0 42945000-43145000 rwxp 42945000 00:00 0 43145000-43146000 ---p 43145000 00:00 0 43146000-43946000 rwxp 43146000 00:00 0 43946000-43947000 ---p 43946000 00:00 0 43947000-44147000 rwxp 43947000 00:00 0 44147000-44148000 ---p 44147000 00:00 0 44148000-44948000 rwxp 44148000 00:00 0 44948000-44949000 ---p 44948000 00:00 0 44949000-45149000 rwxp 44949000 00:00 0 45149000-4514a000 ---p 45149000 00:00 0 4514a000-4594a000 rwxp 4514a000 00:00 0 4594a000-4594b000 ---p 4594a000 00:00 0 4594b000-4614b000 rwxp 4594b000 00:00 0 4614b000-4614c000 ---p 4614b000 00:00 0 4614c000-4694c000 rwxp 4614c000 00:00 0 4694c000-4694d000 ---p 4694c000 00:00 0 4694d000-4714d000 rwxp 4694d000 00:00 0 4714d000-4714e000 ---p 4714d000 00:00 0 4714e000-4794e000 rwxp 4714e000 00:00 0 4794e000-4794f000 ---p 4794e000 00:00 0 4794f000-4814f000 rwxp 4794f000 00:00 0 4814f000-48150000 ---p 4814f000 00:00 0 48150000-48950000 rwxp 48150000 00:00 0 48950000-48951000 ---p 48950000 00:00 0 48951000-49151000 rwxp 48951000 00:00 0 38dbc00000-38dbc1a000 r-xp 00000000 fd:00 12026130 /lib64/ld-2.5.so 38dbe19000-38dbe1a000 r--p 00019000 fd:00 12026130 /lib64/ld-2.5.so 38dbe1a000-38dbe1b000 rw-p 0001a000 fd:00 12026130 /lib64/ld-2.5.so 38dc000000-38dc144000 r-xp 00000000 fd:00 12026131 /lib64/libc-2.5.so 38dc144000-38dc344000 ---p 00144000 fd:00 12026131 /lib64/libc-2.5.so 38dc344000-38dc348000 r--p 00144000 fd:00 12026131 /lib64/libc-2.5.so 38dc348000-38dc349000 rw-p 00148000 fd:00 12026131 /lib64/libc-2.5.so 38dc349000-38dc34e000 rw-p 38dc349000 00:00 0 38dc400000-38dc402000 r-xp 00000000 fd:00 12026132 /lib64/libdl-2.5.so 38dc402000-38dc602000 ---p 00002000 fd:00 12026132 /lib64/libdl-2.5.so 38dc602000-38dc603000 r--p 00002000 fd:00 12026132 /lib64/libdl-2.5.so 38dc603000-38dc604000 rw-p 00003000 fd:00 12026132 /lib64/libdl-2.5.so 38dcc00000-38dcc15000 r-xp 00000000 fd:00 12026136 Core was generated by `/home/quanah/q/openldap-2.4.12/servers/slapd/.libs/lt-slapd -s0 -f /home/quanah'. Program terminated with signal 6, Aborted. #0 0x00000038dc030015 in raise () from /lib64/libc.so.6 (gdb) bt #0 0x00000038dc030015 in raise () from /lib64/libc.so.6 #1 0x00000038dc031980 in abort () from /lib64/libc.so.6 #2 0x00000038dc0674cb in __libc_message () from /lib64/libc.so.6 #3 0x00000038dc06cbb7 in malloc_consolidate () from /lib64/libc.so.6 #4 0x00000038dc06ee92 in _int_malloc () from /lib64/libc.so.6 #5 0x00000038dc070376 in calloc () from /lib64/libc.so.6 #6 0x00000038dbc09c85 in _dl_new_object () from /lib64/ld-linux-x86-64.so.2 #7 0x00000038dbc05abc in _dl_map_object_from_fd () from /lib64/ld-linux-x86-64.so.2 #8 0x00000038dbc07cac in _dl_map_object () from /lib64/ld-linux-x86-64.so.2 #9 0x00000038dbc1088f in dl_open_worker () from /lib64/ld-linux-x86-64.so.2 #10 0x00000038dbc0cc36 in _dl_catch_error () from /lib64/ld-linux-x86-64.so.2 #11 0x00000038dbc1036c in _dl_open () from /lib64/ld-linux-x86-64.so.2 #12 0x00000038dc101320 in do_dlopen () from /lib64/libc.so.6 #13 0x00000038dbc0cc36 in _dl_catch_error () from /lib64/ld-linux-x86-64.so.2 #14 0x00000038dc101487 in __libc_dlopen_mode () from /lib64/libc.so.6 #15 0x00000038dcc0e40c in pthread_cancel_init () from /lib64/libpthread.so.0 #16 0x00000038dcc0e520 in _Unwind_ForcedUnwind () from /lib64/libpthread.so.0 #17 0x00000038dcc0c430 in __pthread_unwind () from /lib64/libpthread.so.0 #18 0x00000038dcc07335 in pthread_exit () from /lib64/libpthread.so.0 #19 0x00002b537fec7e4a in ldap_pvt_thread_exit (retval=0x0) at thr_posix.c:186 #20 0x00002b537fec6b9c in ldap_int_thread_pool_wrapper (xpool=0xce75610) at tpool.c:691 #21 0x00000038dcc061b5 in start_thread () from /lib64/libpthread.so.0 #22 0x00000038dc0cd36d in clone () from /lib64/libc.so.6 #23 0x0000000000000000 in ?? () -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5686) OpenLDAP build broken for solaris 64bit
by h.b.furuseth＠usit.uio.no 05 Sep '08

05 Sep '08

quanah(a)zimbra.com writes: > Sounds like a broken release of libtool to me. i.e., I don't see > anything here that's an openldap specific issue. I'd advise examining > your tool chain. Hm? libtool is built from build/ltmain.sh + build/config.* bundled with OpenLDAP. And it's quite old. If that's failing, it needs an upgrade in OpenLDAP. I looked at it once but couldn't test a fresh libtool + autotools on more than one or two hosts. And the current installation uses some patches form the standar dlibtool distribution which I don't know what do. I don't remember what came of it. Anyway, it might be a fix to try libtoolize --copy --force aclocal autoconf with later versions of autotools (autoconf, automake, libtool). -- Hallvard

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs