- openldap-bugs - openldap.org

Re: (ITS#7681) Bugfix for MDB_SET_RANGE
by hyc＠symas.com 05 Sep '13

05 Sep '13

claude.brisson(a)gmail.com wrote: > Full_Name: Claude Brisson > Version: HEAD > OS: linux 64 > URL: ftp://ftp.openldap.org/incoming/0001-fix-mdb_cursor_set-behaviour-for-MDB_S… > Submission from: (NULL) (84.103.74.195) > > > When no other page was found while provided key is less than found key, > mdb_cursor_get should not return MDB_NOTFOUND. > > The attached patch is a proposal to fix the behaviour of mdb_cursor_set for > MDB_SET_RANGE. Please review that it is correct before integration. Thanks. exactp is always NULL when using SET_RANGE, so that part of the patch is unnecessary. Otherwise looks OK. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#7681) Bugfix for MDB_SET_RANGE
by claude.brisson＠gmail.com 05 Sep '13

05 Sep '13

Full_Name: Claude Brisson Version: HEAD OS: linux 64 URL: ftp://ftp.openldap.org/incoming/0001-fix-mdb_cursor_set-behaviour-for-MDB_S… Submission from: (NULL) (84.103.74.195) When no other page was found while provided key is less than found key, mdb_cursor_get should not return MDB_NOTFOUND. The attached patch is a proposal to fix the behaviour of mdb_cursor_set for MDB_SET_RANGE. Please review that it is correct before integration.

1 0

RE: (ITS#7673)
by Russell.Mosemann＠cune.edu 04 Sep '13

04 Sep '13

Pierangelo Masarati wrote: > Try rwm-drop-unrequested-attrs no (slapo-rwm(5)). That had my hopes up. I didn't think any of those settings applied, because nothing about the query or the results is being rewritten or mapped. In effect, rwm should not be doing anything at all. Everything should pass through the overlay. I set rwm-drop-unrequested-attrs to no, and it made things worse. If I include the filter attributes in the query, nothing is returned, now. If no attributes are specified, all of the allowed attributes are returned, as before. -- Russell Mosemann, Ph.D. Professor of Computer Science

1 0

Re: (ITS#7673)
by pierangelo.masarati＠polimi.it 04 Sep '13

04 Sep '13

On 09/04/2013 10:22 PM, Russell.Mosemann(a)cune.edu wrote: > --_000_B01302EA11DF7D40B2AD9CBEC71B02562C4A3ED5exchange2cunepr_ > Content-Type: text/plain; charset="us-ascii" > Content-Transfer-Encoding: quoted-printable > > The lookup succeeds, and the returned entry is run through the searchEntryD= > N context. It appears that somewhere in or around there all of the attribut= > es are removed except for the requested attributes. That means the ACL filt= > er will fail, if the filter attributes are not requested in the query. If t= > he requested attributes include the filter attributes, the query succeeds, = > but the result only returns the dn without any other attributes. > > If no attributes are requested, all allowed attributes are returned. > > The man page indicates that searchEntryDN should not be applied, because it= > is not defined, and there is no default. Try rwm-drop-unrequested-attrs no (slapo-rwm(5)). p. > > > --_000_B01302EA11DF7D40B2AD9CBEC71B02562C4A3ED5exchange2cunepr_ > Content-Type: text/html; charset="us-ascii" > Content-Transfer-Encoding: quoted-printable > > <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= > osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = > xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= > //www.w3.org/TR/REC-html40"> > <head> > <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= >> > <meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"> > <style></style> > </head> > <body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"> > <div class=3D"WordSection1"> > mes New Roman","serif"">The lookup succeeds, and the returne= > d entry is run through the searchEntryDN context. It appears that somewhere= > in or around there all of the attributes are removed except > for the requested attributes. That means the ACL filter will fail, if the = > filter attributes are not requested in the query. If the requested attribut= > es include the filter attributes, the query succeeds, but the result only r= > eturns the dn without any other > attributes.<o:p></o:p> > mes New Roman","serif""><o:p> </o:p> > mes New Roman","serif"">If no attributes are requested, all = > allowed attributes are returned.<o:p></o:p> > mes New Roman","serif""><o:p> </o:p> > mes New Roman","serif"">The man page indicates that searchEn= > tryDN should not be applied, because it is not defined, and there is no def= > ault.<o:p></o:p> > mes New Roman","serif""><o:p> </o:p> > </div> > </body> > </html> > > --_000_B01302EA11DF7D40B2AD9CBEC71B02562C4A3ED5exchange2cunepr_-- > > > > > -- Pierangelo Masarati Associate Professor Dipartimento di Scienze e Tecnologie Aerospaziali Politecnico di Milano

1 0

(ITS#7673)
by Russell.Mosemann＠cune.edu 04 Sep '13

04 Sep '13

--_000_B01302EA11DF7D40B2AD9CBEC71B02562C4A3ED5exchange2cunepr_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The lookup succeeds, and the returned entry is run through the searchEntryD= N context. It appears that somewhere in or around there all of the attribut= es are removed except for the requested attributes. That means the ACL filt= er will fail, if the filter attributes are not requested in the query. If t= he requested attributes include the filter attributes, the query succeeds, = but the result only returns the dn without any other attributes. If no attributes are requested, all allowed attributes are returned. The man page indicates that searchEntryDN should not be applied, because it= is not defined, and there is no default. --_000_B01302EA11DF7D40B2AD9CBEC71B02562C4A3ED5exchange2cunepr_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"> <style></style> </head> <body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"> <div class=3D"WordSection1"> The lookup succeeds, and the returne= d entry is run through the searchEntryDN context. It appears that somewhere= in or around there all of the attributes are removed except for the requested attributes. That means the ACL filter will fail, if the = filter attributes are not requested in the query. If the requested attribut= es include the filter attributes, the query succeeds, but the result only r= eturns the dn without any other attributes.<o:p></o:p> <o:p> </o:p> If no attributes are requested, all = allowed attributes are returned.<o:p></o:p> <o:p> </o:p> The man page indicates that searchEn= tryDN should not be applied, because it is not defined, and there is no def= ault.<o:p></o:p> <o:p> </o:p> </div> </body> </html> --_000_B01302EA11DF7D40B2AD9CBEC71B02562C4A3ED5exchange2cunepr_--

1 0

Re: (ITS#7680) [Patch] Fix typos in manpages
by hyc＠symas.com 03 Sep '13

03 Sep '13

jsynacek(a)redhat.com wrote: > Full_Name: Jan Synacek > Version: master > OS: Linux - Fedora 19 > URL: http://jsynacek.fedorapeople.org/openldap/jsynacek-20130903-0001-Fix-typos-… > Submission from: (NULL) (209.132.186.34) > > > Minor documentation typos in ldapsearch.1 and slapd-passwd.5. > > Thanks, applied to master -- -- 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#7679) Problem with overlay dynlist
by pierangelo.masarati＠polimi.it 03 Sep '13

03 Sep '13

On 09/02/2013 04:52 PM, a.rossini(a)cineca.it wrote: > Full_Name: Angelo Rossini > Version: slapd 2.4.23 (Dec 16 2012 11:48:44) > OS: Debian GNU/Linux 6.0 2.6.32-5-amd64 x86_64 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (130.186.20.62) > > > I've tried to use the overlay dynlist to manage dynamic group; i've added these > rows to slapd.conf: > > # required schema for dynamic groups > include /etc/ldap/schema/dyngroup.schema > > # permanent load of the dynlist overlay > > moduleload dynlist > > overlay dynlist > dynlist-attrset groupOfURLs memberURL seeAlso > > And created a group using this LDIF: > > dn: cn=GROUP_DYN,ou=gruppi,o=unixx,dc=unixx,dc=it > > objectClass: groupOfURLs > > cn: GROUP_DYN > > memberURL: ldap:///ou=users,o=unixx,dc=unixx,dc=it??sub?(schacPersonalPosition=STUDENTE) > > When i try ldap searches like ldapsearch --baseDN > cn=GROUP_DYN,ou=gruppi,o=unixx,dc=unixx,dc=it '(objectClass=*)' or like > ldapsearch --baseDN cn=GROUP_DYN,ou=gruppi,o=unixx,dc=unixx,dc=it > 'isMemberOf=cn=GROUP_DYN,ou=gruppi,o=unixx,dc=unixx,dc=it' is not possible to > retrieve the list of distinguished names of the results but only a list of some > other attributes of the result. > > The configuration is exactly the one described in the > http://www.openldap.org/doc/admin24/overlays.html#Dynamic Lists page. > > What is wrong? So far, there is no evidence of a software bug. Does your build pass test044 ? If so, then it must be something in the way you're using the overlay. You should direct the discussion to the openldap-technical mailing list, and provide a simple, self-contained test case that reproduces the problem. p. -- Pierangelo Masarati Associate Professor Dipartimento di Scienze e Tecnologie Aerospaziali Politecnico di Milano

1 0

(ITS#7680) [Patch] Fix typos in manpages
by jsynacek＠redhat.com 03 Sep '13

03 Sep '13

Full_Name: Jan Synacek Version: master OS: Linux - Fedora 19 URL: http://jsynacek.fedorapeople.org/openldap/jsynacek-20130903-0001-Fix-typos-… Submission from: (NULL) (209.132.186.34) Minor documentation typos in ldapsearch.1 and slapd-passwd.5.

1 0

Re: Re : Re: (ITS#7676) OpenLDAP 2.4.36 slapd crash with "assertion failed" message
by hyc＠symas.com 03 Sep '13

03 Sep '13

"POISSON Frédéric" wrote: > Hello all, > > Thanks first for the patch, i have applied it on my own build of 2.4.36 but i > have now a strange behavior, the slapd do not crash but it refused operations. > > First here is the diff after applying the patch : > $ diff ../BUILD/openldap-2.4.36/servers/slapd/bconfig.c > ../BUILD/openldap-2.4.36/servers/slapd/bconfig.c.orig > 3795d3794 > < slap_tls_ctx = NULL; > 3804,3808d3802 > < } else { > < if ( rc == LDAP_NOT_SUPPORTED ) > < rc = LDAP_UNWILLING_TO_PERFORM; > < else > < rc = LDAP_OTHER; > > Now when i only add or replace only attribute olcTLSRandFile on cn=config i have : > > ldap_modify: Server is unwilling to perform (53) > > > When i replace following values in this order with 4 actions/operations or > with a single action/operation it works : > > dn: cn=config > changetype: modify > replace: olcTLSCACertificateFile > olcTLSCACertificateFile: /usr/products/openldap/etc/openldap-single/tls/cacert.pem > - > replace: olcTLSCertificateFile > olcTLSCertificateFile: /usr/products/openldap/etc/openldap-single/tls/cert.pem > - > replace: olcTLSCertificateKeyFile > olcTLSCertificateKeyFile: /usr/products/openldap/etc/openldap-single/tls/key.pem > - > replace: olcTLSRandFile > olcTLSRandFile: /dev/random > > But it don't works with only olcTLSRandfile if i do an add or replace first, why ? > > What do you need for investigation ? There's nothing to investigate, this works as designed. The config engine requires your TLS configuration to be valid when you configure it. That means at a minimum you must configure a server cert and key. If you only configure the randfile and nothing else, the config is rejected. -- -- 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#7673) rwm and bad ACL evaluation
by Russell.Mosemann＠cune.edu 02 Sep '13

02 Sep '13

> Hmm, maybe it's related to this: > http://www.openldap.org/its/index.cgi?findid=7495 extra_attrs is a great suggestion. Unfortunately, it doesn't work. If I execute the query and specify an attribute, it returns nothing. If I execute the query and do not specify an attribute, slapd dies, which is what you reported. -- Russell Mosemann, Ph.D. Professor of Computer Science

1 0

Re: (ITS#7678) Operational Error propagated from back-meta
by matth＠netsight.co.uk 02 Sep '13

02 Sep '13

On 2 Sep 2013, at 04:15 PM, Howard Chu <hyc(a)symas.com> wrote: > matth(a)netsight.co.uk wrote: >> Full_Name: Matt Hamilton >> Version: 2.4.36 >> OS: Linux >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (213.133.64.253) >> >> >> I am using the meta backend to query multiple LDAP (AD) backends. This is to >> consolidate several directories in different departments into one. We attempt >> both simple binds with username/password and also anon binds to look up user >> information. > > That doesn't make much sense, since AD disallows anonymous Binds. Sorry, I wasn't clear. I mean we do both anon and simple binds to OpenLDAP. Hence why the config has credentials in it to use against the backends if not supplied by the client. >> At the moment, trying to do an authenticated simple bind to slapd caused an >> Operational Error to be propagated to the client regardless of the setting of >> 'onerr'. Even when a result is successfully found. This is due to one server in >> the backend succeeding and the other returning an operational error due to an >> invalid bind (as would be expected as the credentials supplied from the client >> will only work with one of the backends). >> >> Looking at servers/slapd/back-meta/search.c at around line 1903 it appears that >> the code is not checking for 'Operational Error' as a specific case above and so >> uses the default case (line 1665). Hence sres is set to 'Operational Error' too >> at line 1934. > > back-meta/search.c has nothing to do with Binds. Not sure what you're trying to demonstrate there. I'm not talking about binds there. I'm talking about errors being propagated. -Matt >> >> The server should be changing this to LDAP_SUCCESS somewhere in that logic >> unless META_BACK_ONERR_REPORT. > > -- > -- 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#7678) Operational Error propagated from back-meta
by hyc＠symas.com 02 Sep '13

02 Sep '13

matth(a)netsight.co.uk wrote: > Full_Name: Matt Hamilton > Version: 2.4.36 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (213.133.64.253) > > > I am using the meta backend to query multiple LDAP (AD) backends. This is to > consolidate several directories in different departments into one. We attempt > both simple binds with username/password and also anon binds to look up user > information. That doesn't make much sense, since AD disallows anonymous Binds. > At the moment, trying to do an authenticated simple bind to slapd caused an > Operational Error to be propagated to the client regardless of the setting of > 'onerr'. Even when a result is successfully found. This is due to one server in > the backend succeeding and the other returning an operational error due to an > invalid bind (as would be expected as the credentials supplied from the client > will only work with one of the backends). > > Looking at servers/slapd/back-meta/search.c at around line 1903 it appears that > the code is not checking for 'Operational Error' as a specific case above and so > uses the default case (line 1665). Hence sres is set to 'Operational Error' too > at line 1934. back-meta/search.c has nothing to do with Binds. Not sure what you're trying to demonstrate there. > > The server should be changing this to LDAP_SUCCESS somewhere in that logic > unless META_BACK_ONERR_REPORT. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#7679) Problem with overlay dynlist
by a.rossini＠cineca.it 02 Sep '13

02 Sep '13

Full_Name: Angelo Rossini Version: slapd 2.4.23 (Dec 16 2012 11:48:44) OS: Debian GNU/Linux 6.0 2.6.32-5-amd64 x86_64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (130.186.20.62) I've tried to use the overlay dynlist to manage dynamic group; i've added these rows to slapd.conf: # required schema for dynamic groups include /etc/ldap/schema/dyngroup.schema # permanent load of the dynlist overlay moduleload dynlist overlay dynlist dynlist-attrset groupOfURLs memberURL seeAlso And created a group using this LDIF: dn: cn=GROUP_DYN,ou=gruppi,o=unixx,dc=unixx,dc=it objectClass: groupOfURLs cn: GROUP_DYN memberURL: ldap:///ou=users,o=unixx,dc=unixx,dc=it??sub?(schacPersonalPosition=STUDENTE) When i try ldap searches like ldapsearch --baseDN cn=GROUP_DYN,ou=gruppi,o=unixx,dc=unixx,dc=it '(objectClass=*)' or like ldapsearch --baseDN cn=GROUP_DYN,ou=gruppi,o=unixx,dc=unixx,dc=it 'isMemberOf=cn=GROUP_DYN,ou=gruppi,o=unixx,dc=unixx,dc=it' is not possible to retrieve the list of distinguished names of the results but only a list of some other attributes of the result. The configuration is exactly the one described in the http://www.openldap.org/doc/admin24/overlays.html#Dynamic Lists page. What is wrong? Regards, Angelo Rossini.

1 0

(ITS#7678) Operational Error propagated from back-meta
by matth＠netsight.co.uk 02 Sep '13

02 Sep '13

Full_Name: Matt Hamilton Version: 2.4.36 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (213.133.64.253) I am using the meta backend to query multiple LDAP (AD) backends. This is to consolidate several directories in different departments into one. We attempt both simple binds with username/password and also anon binds to look up user information. database meta suffix "DC=hscic,DC=nhs,DC=uk" rootdn "DC=hscic,DC=nhs,DC=uk" chase-referrals no norefs yes uri "ldap://dc1lv.npfit.nhs.uk/DC=hscic,DC=nhs,DC=uk" "ldap://dc2lv.npfit.nhs.uk" "ldap://dc1dr.npfit.nhs.uk" suffixmassage "DC=hscic,DC=nhs,DC=uk" "OU=Accounts - Active Users, OU=routine objects, DC=npfit, DC=nhs, DC=uk" idassert-bind bindmethod=simple binddn="CN=webuser,OU=Surnames Q to Z,OU=Accounts - Active Users,OU=Routine Objects,DC=npfit,DC=nhs,DC=uk" credentials="secret1" mode=self idassert-authzFrom "dn:*" uri "ldap://ts-l-dci-350.ic.green.net/DC=hscic,DC=nhs,DC=uk" "ldap://ts-l-dci-344.ic.green.net" "ldap://hg-l-dci-332.ic.green.net" suffixmassage "DC=hscic,DC=nhs,DC=uk" "OU=HSCIC,DC=ic,DC=Green,DC=Net" idassert-bind bindmethod=simple binddn="CN=z-CFHimport,OU=Service Accounts,OU=Administration,DC=ic,DC=Green,DC=Net" credentials="secret2" mode=self idassert-authzFrom "dn:*" At the moment, trying to do an authenticated simple bind to slapd caused an Operational Error to be propagated to the client regardless of the setting of 'onerr'. Even when a result is successfully found. This is due to one server in the backend succeeding and the other returning an operational error due to an invalid bind (as would be expected as the credentials supplied from the client will only work with one of the backends). Looking at servers/slapd/back-meta/search.c at around line 1903 it appears that the code is not checking for 'Operational Error' as a specific case above and so uses the default case (line 1665). Hence sres is set to 'Operational Error' too at line 1934. The server should be changing this to LDAP_SUCCESS somewhere in that logic unless META_BACK_ONERR_REPORT.

1 0

Re: (ITS#7673) rwm and bad ACL evaluation
by michael＠stroeder.com 02 Sep '13

02 Sep '13

This is a cryptographically signed message in MIME format. --------------ms030200060406090105050307 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Russell.Mosemann(a)cune.edu wrote: > Further testing confirms that the filter for the ACL is not being appli= ed > correctly when rwm is used. Turning the rewriteEngine off has no effect= =2E > All lines referring to rwm must be commented. >=20 > Interestingly, performing the query without specifying any attribute > succeeds. All allowed attributes are returned. Hmm, maybe it's related to this: http://www.openldap.org/its/index.cgi?findid=3D7495 Ciao, Michael. --------------ms030200060406090105050307 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFfzCC BXswggNjoAMCAQICAwxOfTANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMjEw MDIyMDE3MDlaFw0xNDEwMDIyMDE3MDlaMD8xGDAWBgNVBAMUD01pY2hhZWwgU3Ry9mRlcjEj MCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDo2SKth5GhtaDrCyfGtyUG+/hAAa/J52L0NFN4SSRvTtdGf9HfWwwd NCtgae0TVGWk2lKDbXA9d5vmyIiRhuwxd90H6FLErhRBeB9G67qtw87E8WUoXt2DwPQEUTWV hqHpPadlmgFw3+i3TGQQTe3O3W9MMMd4GJNhObem2VGRuCD37OXnzBksTcq0FPJgcWAhe3d/ 0ItOkNWBqgq8Mf3p7WFBhaQ0a27BC/mKtH8fI3kPcS305imPRja69Msq3EwUZBc9ToVp6FRQ NYKjfOBybDUzVkmRZl3H8xutQP2w8Zxb8m5f7Q1BfLLrIFScfYvIDgOERxTCd4lab8+/09XH AgMBAAGjggFEMIIBQDAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJFkdUbyBnZXQgeW91 ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6Ly93d3cuQ0Fj ZXJ0Lm9yZzAOBgNVHQ8BAf8EBAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMC BgorBgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIG CCsGAQUFBzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMDEGA1UdHwQqMCgwJqAkoCKGIGh0 dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9yZXZva2UuY3JsMB8GA1UdEQQYMBaBFG1pY2hhZWxAc3Ry b2VkZXIuY29tMA0GCSqGSIb3DQEBBQUAA4ICAQC9ouXq3p/bDWMM4tBKgD3tl4HY5H0eECl8 q9/nqk0UL6YeWkrCiQdrDtNPW7DcGqNYtzdgtzmyTr1GhiAX+igrOjdk/ge5NRcQOpONK/4b zrmpQEcIUyxSSDKLWh211/kcFfxxLEiJ5teF4GL8Fc1qbrLP4+DCvJXWfYaaR5NLjZMqm2VP yKTv3qpXWnGohiRkGTwS/11QM2XCfIGdRsQT9a8mO4m2fn2tGPp2TEIoCLrDDrbGVeDWaOWB OIeTrp4wa3Q4OI6yCptJhEqKvjhV96IBRYgM76nTBqsqnDzwxExAyhhWiUS5DunRHOr/+NyF pUpD4883RBLO0g9kUEGOhtZNF1u+8zEL0YgMGvifAom9JEklLOXZuqj0MThypKs/3d/OyOQb 4gURnu6oZwcKZ7LskytWnlRKUxF6o0A8grtmyKkqe14TS7cQbg0NTaIYXPkHR+dfFmb3uEqn BBjvpJXFcEtWI2lQXC/ET+au991pK797ExBOmpQwjIn3SjiW80vw/UoL6DMvqY/6JhVhyNTP MJ2W5AX5kc27DIbVtVGZs8J4AYhuNALJUq9N9Ka7rPRj3RcYDrfehDLOkM5iMnarpmtuOpLK d1SvZhqj/0N/JWGIDpPSTkTFOPP6ZN9I9Rqyf+9NGqb2sjo4DkIiZcHxt735/GJLwus5KLBl 2DGCA6EwggOdAgEBMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93 d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8G CSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wCQYFKw4DAhoFAKCCAfUwGAYJ KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwOTAyMTMzNzMyWjAj BgkqhkiG9w0BCQQxFgQUSUWFlNi+P3gVhEYcXVvCWpgF+p0wbAYJKoZIhvcNAQkPMV8wXTAL BglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAN BggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGD MIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9y ZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYS c3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wgZMGCyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNV BAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZ Q0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNl cnQub3JnAgMMTn0wDQYJKoZIhvcNAQEBBQAEggEAHz5RR3K9GzJnvCkk+VEaz3FbSTprmvi/ Ey1b74sXSMNwTx85VZ12vvZZquUFwFxXckqtNoqlHQfggDf224UjQB0Fx8NTzdwKuMDJAjBI +/VGV0EP7EXkhHXoPjYAhiWU2QnX4/bWLMwIaXYhT2ANJL9dV03WU6Y2UoC6Sh+xdKEQOCA4 kjQ54Zi5e09/KuWl+3eIQivGzIi+5zbukV6VHvumpQd5IL4s1F8VTHpHgmMQiDLPK2xv5+Uc DuwnggSmLjskrUwg7uQtJARk3Cx6k9+SM0dB0c5Edrv8kDoDpFEanS5zvtRVP13/415dJJcP MH5Bv8s+9RzDAKF6D4vcAAAAAAAAAA== --------------ms030200060406090105050307--

1 0

RE: (ITS#7673) rwm and bad ACL evaluation
by Russell.Mosemann＠cune.edu 31 Aug '13

31 Aug '13

Further testing confirms that the filter for the ACL is not being applied correctly when rwm is used. Turning the rewriteEngine off has no effect. All lines referring to rwm must be commented. Interestingly, performing the query without specifying any attribute succeeds. All allowed attributes are returned. ldapsearch -D "qmailGID=306,ou=accounts,o=cune" -w password \ -E 2.16.840.1.113730.3.4.2 -b "ou=accounts,o=cune" "(uid=Test.Entry)" # extended LDIF # # LDAPv3 # base <ou=accounts,o=cune> with scope subtree # filter: (uid=Test.Entry) # requesting: ALL # # 2, accounts, cune dn: qmailUID=2,ou=accounts,o=cune objectClass: pilotPerson objectClass: qmailUser objectClass: PureFTPdUser cn: Test Entry sn: Entry uid: Test.Entry accountStatus: active mail: test.entry(a)cune.org userClass: stu # search result search: 2 result: 0 Success Specifying an allowed attribute or no attributes (1.1) causes the query to fail. For example, ldapsearch -D "qmailGID=306,ou=accounts,o=cune" -w password \ -E 2.16.840.1.113730.3.4.2 -b "ou=accounts,o=cune" "(uid=Test.Entry)" cn ldapsearch -D "qmailGID=306,ou=accounts,o=cune" -w password \ -E 2.16.840.1.113730.3.4.2 -b "ou=accounts,o=cune" "(uid=Test.Entry)" 1.1 # extended LDIF # # LDAPv3 # base <ou=accounts,o=cune> with scope subtree # filter: (uid=Test.Entry) # requesting: cn # # search result search: 2 result: 32 No such object # numResponses: 1 Removing the filter from the ACL allows the query to succeed. access to dn.subtree="ou=accounts,o=cune" attrs=cn,entry,mail,objectClass,sn,uid,userClass,accountStatus by dn="qmailGID=306,ou=accounts,o=cune" read by peername.ip=127.0.0.0%255.255.255.0 read by peername.ip=10.0.0.0%255.255.192.0 read by * none In summary, slapd is unable to apply the filter for an ACL correctly when rwm is being used and an attribute (or no attributes) is specified with the query.

1 0

Re: (ITS#7676) OpenLDAP 2.4.36 slapd crash with "assertion failed" message
by hyc＠symas.com 30 Aug '13

30 Aug '13

frederic.poisson(a)admin.gmessaging.net wrote: > Full_Name: Frederic POISSON > Version: 2.4.36 > OS: RHEL 6.2 > URL: ftp://ftp.openldap.org/incoming/slapcat_cn_config.ldif ftp://ftp.openldap.org/incoming/slapd_debug_255.txt ftp://ftp.openldap.org/incoming/gdb_output.txt > Submission from: (NULL) (57.250.229.136) Thanks for the report, this is now fixed in git master. > > I'm testing the latest release of OpenLDAP 2.4.36 and my slapd crash while i'm > doing a change on cn=config. > My tests are with my own compilation of OpenLDAP on a RHEL6 server but i see the > same problem with "LTB project RPMs" > http://ltb-project.org/wiki/download#openldap with RHEL6 package. > My aim is to modify cn=config like this in order to implement TLS, here is my > ldap modify command with ldif : > # /usr/local/openldap/bin/ldapmodify -f /tmp/ldif -h "localhost" -p "25389" -D > "cn=root DN,cn=config" -w "secret" > modifying entry "cn=config" > ldap_result: Can't contact LDAP server (-1) > > # cat /tmp/ldif > dn: cn=config > changetype: modify > add: olcTLSRandFile > olcTLSRandFile: /dev/random > > The server shutdown when i add this entry and with slapd option "-d 255" i have > : > slapd: result.c:813: slap_send_ldap_result: Assertion `!((rs->sr_err)<0)' > failed. > /etc/init.d/slapd: line 285: 5461 Aborted $SLAPD_BIN -h > "$SLAPD_SERVICES" $SLAPD_PARAMS > > Notice that i test this ldif modification on release 2.4.35 without problem. > > I put on your ftp three files, the file slapcat_cn_config.ldif corresponding to > configuration, the file slapd_debug_255.txt which correspond to the slapd > process with debug set to 255 with only the part corresponding to the moment i > launch ldapmodify action, the file gdb_output.txt corresponding to the full > backtrace i run when doing the ldapmodify action. > > And so the credentials are "cn=root DN,cn=config" with password secret. > > -- -- 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#7677) slapd crashes when modifying cn=config
by hyc＠symas.com 30 Aug '13

30 Aug '13

grimeton(a)gmx.net wrote: > Full_Name: Oliver Loch > Version: 2.4.36 > OS: Ubuntu 13.04 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (88.134.35.240) > > > Hi, > > when chaning TLS related configuration in cn=config, slapd crashes. > It looks pretty similar to ITS#7676. Yes, now fixed in master. Closing this as a dup of #7676. > > If you have questions, feel free to contact me. > > KR, > > Oliver > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#7677) slapd crashes when modifying cn=config
by grimeton＠gmx.net 30 Aug '13

30 Aug '13

Full_Name: Oliver Loch Version: 2.4.36 OS: Ubuntu 13.04 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (88.134.35.240) Hi, when chaning TLS related configuration in cn=config, slapd crashes. The slapd version 2.4.36 I'm using are packages that I built on my own with the help of the original Debian (!) source packages for 2.4.35. Even if the source packages come from Debian, they have been built on Ubuntu 13.04 and are used on Ubuntu 13.04. There are no "binary parts" of Debian involved in any way. If you want the source packages, just let me know. I kicked a lot of patches including the GNUTLS stuff and linked against OpenSSL. # ldd $(which slapd) linux-vdso.so.1 => (0x00007fffeddfe000) libldap_r-2.4.so.2 => /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2 (0x00007f0a66da9000) liblber-2.4.so.2 => /usr/lib/x86_64-linux-gnu/liblber-2.4.so.2 (0x00007f0a66b9b000) libslp.so.1 => /usr/lib/libslp.so.1 (0x00007f0a66988000) libsasl2.so.2 => /usr/lib/x86_64-linux-gnu/libsasl2.so.2 (0x00007f0a6676d000) libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 (0x00007f0a66534000) libslapi-2.4.so.2 => /usr/lib/x86_64-linux-gnu/libslapi-2.4.so.2 (0x00007f0a66315000) libltdl.so.7 => /usr/lib/x86_64-linux-gnu/libltdl.so.7 (0x00007f0a6610b000) libwrap.so.0 => /lib/x86_64-linux-gnu/libwrap.so.0 (0x00007f0a65f01000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f0a65ce3000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f0a6591b000) libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007f0a65701000) libssl.so.1.0.0 => /lib/x86_64-linux-gnu/libssl.so.1.0.0 (0x00007f0a654a3000) libcrypto.so.1.0.0 => /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 (0x00007f0a650c8000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f0a64ec4000) libnsl.so.1 => /lib/x86_64-linux-gnu/libnsl.so.1 (0x00007f0a64ca9000) /lib64/ld-linux-x86-64.so.2 (0x00007f0a6738c000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f0a64a92000) # I'm able to change any of the olcTLS* attributes in cn=config and only "olcTLSCACertificateFile" crashes slapd. When adding, the data is written to the cn=config backend and stored there (data available after a restart), when deleting, slapd crashes before the data has been written back. The LDIF file looks like this: ===== SNIP ===== 8< ======== dn: cn=config changetype: modify add: olcTLSCACertificateFile olcTLSCACertificateFile: /etc/ssl/certs/some.cert.pem - add: olcTLSCertificateFile olcTLSCertificateFile: /etc/ssl/private/cert.server.pem - add: olcTLSCertificateKeyFile olcTLSCertificateKeyFile: /etc/ssl/private/key.server.pem - add: olcTLSDHParamFile olcTLSDHParamFile: /etc/ssl/private/system.dhparam - add: olcTLSVerifyClient olcTLSVerifyClient: allow - add: olcTLSCRLCheck olcTLSCRLCheck: all - add: olcTLSCRLFile olcTLSCRLFile: /etc/ssl/certs/somecrl.crl.pem - ======= >8 ======= SNAP ======== The files do all exist and can be accessed by slapd. The error message before slapd core dumps: slapd: ../../../../servers/slapd/result.c:813: slap_send_ldap_result: Assertion `!((rs->sr_err)<0)' failed. Aborted (core dumped) It looks pretty similar to ITS#7676. If you have questions, feel free to contact me. KR, Oliver

1 0

(ITS#7676) OpenLDAP 2.4.36 slapd crash with "assertion failed" message
by frederic.poisson＠admin.gmessaging.net 30 Aug '13

30 Aug '13

Full_Name: Frederic POISSON Version: 2.4.36 OS: RHEL 6.2 URL: ftp://ftp.openldap.org/incoming/slapcat_cn_config.ldif ftp://ftp.openldap.org/incoming/slapd_debug_255.txt ftp://ftp.openldap.org/incoming/gdb_output.txt Submission from: (NULL) (57.250.229.136) I'm testing the latest release of OpenLDAP 2.4.36 and my slapd crash while i'm doing a change on cn=config. My tests are with my own compilation of OpenLDAP on a RHEL6 server but i see the same problem with "LTB project RPMs" http://ltb-project.org/wiki/download#openldap with RHEL6 package. My aim is to modify cn=config like this in order to implement TLS, here is my ldap modify command with ldif : # /usr/local/openldap/bin/ldapmodify -f /tmp/ldif -h "localhost" -p "25389" -D "cn=root DN,cn=config" -w "secret" modifying entry "cn=config" ldap_result: Can't contact LDAP server (-1) # cat /tmp/ldif dn: cn=config changetype: modify add: olcTLSRandFile olcTLSRandFile: /dev/random The server shutdown when i add this entry and with slapd option "-d 255" i have : slapd: result.c:813: slap_send_ldap_result: Assertion `!((rs->sr_err)<0)' failed. /etc/init.d/slapd: line 285: 5461 Aborted $SLAPD_BIN -h "$SLAPD_SERVICES" $SLAPD_PARAMS Notice that i test this ldif modification on release 2.4.35 without problem. I put on your ftp three files, the file slapcat_cn_config.ldif corresponding to configuration, the file slapd_debug_255.txt which correspond to the slapd process with debug set to 255 with only the part corresponding to the moment i launch ldapmodify action, the file gdb_output.txt corresponding to the full backtrace i run when doing the ldapmodify action. And so the credentials are "cn=root DN,cn=config" with password secret.

1 0

Re: (ITS#7675) Crash on mtestx.exe
by hyc＠symas.com 28 Aug '13

28 Aug '13

tghill(a)hotmail.com wrote: > Full_Name: TG Hill > Version: LMDB_0.9.7 > OS: Windows 7 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (216.211.58.121) > > > I frequently (but not always) get a crash when I run mtest(x).exe. It always > works after I delete data.mdb. It's normal. None of the test programs do any error checking, and they are not meant to be run. They are meant to be single-stepped under a debugger, and a developer is meant to examine the result of each call, manually. If you're not an LMDB developer you should just ignore these. Closing this ITS. > > The line causing the crash is listed below. > > rc = mdb_txn_begin(env, NULL, 0, &txn); > > > The binary was compiled using mingw gcc 4.6.2. > > I modified the makefile to use -lpthread or -mthreads so it would compile. Both > versions would periodically crash. > > Any ideas? > > Thanks! > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#7675) Crash on mtestx.exe
by tghill＠hotmail.com 28 Aug '13

28 Aug '13

Full_Name: TG Hill Version: LMDB_0.9.7 OS: Windows 7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (216.211.58.121) I frequently (but not always) get a crash when I run mtest(x).exe. It always works after I delete data.mdb. The line causing the crash is listed below. rc = mdb_txn_begin(env, NULL, 0, &txn); The binary was compiled using mingw gcc 4.6.2. I modified the makefile to use -lpthread or -mthreads so it would compile. Both versions would periodically crash. Any ideas? Thanks!

1 0

Re: (ITS#7674) Configure Mirror Mode Replication
by quanah＠zimbra.com 27 Aug '13

27 Aug '13

--On Tuesday, August 27, 2013 11:19 PM +0000 cpetty(a)luthresearch.com wrote: > Full_Name: Clint Petty > Version: 2.4.23 > OS: CentOS 6.4 The ITS system is for bug reports. Help requests such as this should be sent to openldap-technical(a)openldap.org I would note the release you are using is ancient, and it is well known that the build from RedHat/CentOS has numerous problems and is quite broken. You would be best served to build a current release of OpenLDAP yourself, or grab the package from <http://ltb-project.org/wiki/download#openldap> for OpenLDAP 2.4.36. This ITS will be closed. --Quanah -- Quanah Gibson-Mount Lead Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7674) Configure Mirror Mode Replication
by cpetty＠luthresearch.com 27 Aug '13

27 Aug '13

Full_Name: Clint Petty Version: 2.4.23 OS: CentOS 6.4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (65.44.192.153) I am wanting to implement Mirror Mode Replication. I am using OpenLDAP 2.4.23 which uses cn=config format, that does not have a slapd.conf file. The instructions say to add the following to the slapd.conf file: database bdb suffix dc=Example,dc=com rootdn dc=Example,dc=com directory /var/ldap/db index objectclass,entryCSN,entryUUID eq overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 MirrorMode node 1: # Global section serverID 1 # database section # syncrepl directive syncrepl rid=001 provider=ldap://ldap-sid2.example.com bindmethod=simple binddn="cn=mirrormode,dc=example,dc=com" credentials=mirrormode searchbase="dc=example,dc=com" schemachecking=on type=refreshAndPersist retry="60 +" mirrormode on MirrorMode node 2: # Global section serverID 2 # database section # syncrepl directive syncrepl rid=001 provider=ldap://ldap-sid1.example.com bindmethod=simple binddn="cn=mirrormode,dc=example,dc=com" credentials=mirrormode searchbase="dc=example,dc=com" schemachecking=on type=refreshAndPersist retry="60 +" mirrormode on Since there is no slapd.conf file, how do I configure replication in a cn=config format? Do I need to run a slapadd or ldapadd command? Syntax? What files do I need to create, and where? Thanks in advance.

1 0

(ITS#7673) rwm and bad ACL evaluation
by Russell.Mosemann＠cune.edu 27 Aug '13

27 Aug '13

Full_Name: Russell Mosemann Version: 2.4.36 OS: Debian 6 and 7 URL: Submission from: (NULL) (192.160.64.50) Including rwm directives causes ACL evaluation to be incorrectly performed. rwm plays no role in rewriting any part of the incoming query or outgoing results. Simply commenting the rwm lines without making any other configuration changes permits the query to succeed. The query is coming from an authenticated entry that is allowed to search the subtree. # rwm configuration - Commenting the follow lines allows the query to succeed. overlay rwm rwm-rewriteEngine on rwm-rewriteMap slapd flt2dn "ldap:///ou=accounts,o=cune?dn?sub" rwm-rewriteContext bindDN rwm-rewriteRule "^(mail=[a-z0-9-]+\\.[a-z0-9-]+(a)cune\\.org),ou=People,o=cune$" "${flt2dn((\&($1)(accountStatus=active)(userClass=stu)))}" ":@I" # There are only 4 ACLs. # Allow authentication access to dn.subtree="ou=accounts,o=cune" attrs=userPassword by self write by peername.ip=127.0.0.0%255.255.255.0 search by peername.ip=10.0.0.0%255.255.192.0 search by anonymous auth # Allow reading of certain attributes. access to dn.subtree="ou=accounts,o=cune" filter=(&(userClass=stu)(accountStatus=active)) attrs=cn,entry,mail,objectClass,sn,uid,userClass,accountStatus by dn="qmailGID=306,ou=accounts,o=cune" read by peername.ip=127.0.0.0%255.255.255.0 read by peername.ip=10.0.0.0%255.255.192.0 read by * none # Search access to the base is required to search children. access to dn.base="ou=accounts,o=cune" by dn="qmailGID=306,ou=accounts,o=cune" search by peername.ip=127.0.0.0%255.255.255.0 read by peername.ip=10.0.0.0%255.255.192.0 read by * none # No access to other parts. access to dn.subtree="o=cune" by dn="qmailGID=306,ou=accounts,o=cune" none by peername.ip=127.0.0.0%255.255.255.0 read by peername.ip=10.0.0.0%255.255.192.0 read by * none The query is from the authenticated entry "qmailGID=306,ou=accounts,o=cune" searching the base "ou=accounts,o=cune" with the filter "(uid=Test.Entry)". This is the debugging output when the rwm lines above are commented. The query succeeds. 521cdb75 => send_search_entry: conn 1001 dn="qmailUID=2,ou=accounts,o=cune" 521cdb75 => access_allowed: read access to "qmailUID=2,ou=accounts,o=cune" "entry" requested 521cdb75 => dn: [1] ou=accounts,o=cune 521cdb75 => acl_get: [1] matched 521cdb75 => dn: [2] ou=accounts,o=cune 521cdb75 => acl_get: [2] matched 521cdb75 => test_filter 521cdb75 AND 521cdb75 => test_filter_and 521cdb75 => test_filter 521cdb75 EQUALITY 521cdb75 => access_allowed: search access to "qmailUID=2,ou=accounts,o=cune" "userClass" requested 521cdb75 <= test_filter 6 521cdb75 => test_filter 521cdb75 EQUALITY 521cdb75 => access_allowed: search access to "qmailUID=2,ou=accounts,o=cune" "accountStatus" requested 521cdb75 <= test_filter 6 521cdb75 <= test_filter_and 6 521cdb75 <= test_filter 6 521cdb75 => acl_get: [2] attr entry 521cdb75 => acl_mask: access to entry "qmailUID=2,ou=accounts,o=cune", attr "entry" requested 521cdb75 => acl_mask: to all values by "qmailGID=306,ou=accounts,o=cune", (=0) 521cdb75 <= check a_dn_pat: qmailGID=306,ou=accounts,o=cune 521cdb75 <= acl_mask: [1] applying read(=rscxd) (stop) 521cdb75 <= acl_mask: [1] mask: read(=rscxd) 521cdb75 => slap_access_allowed: read access granted by read(=rscxd) 521cdb75 => access_allowed: read access granted by read(=rscxd) ber_flush2: 40 bytes to sd 22 0000: 30 26 02 01 02 64 21 04 1d 71 6d 61 69 6c 55 49 0&...d!..qmailUI 0010: 44 3d 32 2c 6f 75 3d 61 63 63 6f 75 6e 74 73 2c D=2,ou=accounts, 0020: 6f 3d 63 75 6e 65 30 00 o=cune0. ldap_write: want=40, written=40 0000: 30 26 02 01 02 64 21 04 1d 71 6d 61 69 6c 55 49 0&...d!..qmailUI 0010: 44 3d 32 2c 6f 75 3d 61 63 63 6f 75 6e 74 73 2c D=2,ou=accounts, 0020: 6f 3d 63 75 6e 65 30 00 o=cune0. 521cdb75 <= send_search_entry: conn 1001 exit. 521cdb75 send_ldap_result: conn=1001 op=1 p=3 521cdb75 send_ldap_result: err=0 matched="" text="" 521cdb75 send_ldap_response: msgid=2 tag=101 err=0 This is the debugging output after uncommenting the rwm lines and making no other configuration changes. Search access allowed in the second ACL is not found, and it proceeds to the fourth ACL where all access is denied. 521cdd96 => send_search_entry: conn 1004 dn="qmailUID=2,ou=accounts,o=cune" 521cdd96 => access_allowed: read access to "qmailUID=2,ou=accounts,o=cune" "entry" requested 521cdd96 => dn: [1] ou=accounts,o=cune 521cdd96 => acl_get: [1] matched 521cdd96 => dn: [2] ou=accounts,o=cune 521cdd96 => acl_get: [2] matched 521cdd96 => test_filter 521cdd96 AND 521cdd96 => test_filter_and 521cdd96 => test_filter 521cdd96 EQUALITY 521cdd96 => access_allowed: search access to "qmailUID=2,ou=accounts,o=cune" "userClass" requested 521cdd96 <= test_filter 5 521cdd96 <= test_filter_and 5 521cdd96 <= test_filter 5 521cdd96 => dn: [3] ou=accounts,o=cune 521cdd96 => dn: [4] o=cune 521cdd96 => acl_get: [4] matched 521cdd96 => acl_get: [4] attr entry 521cdd96 => acl_mask: access to entry "qmailUID=2,ou=accounts,o=cune", attr "entry" requested 521cdd96 => acl_mask: to all values by "qmailGID=306,ou=accounts,o=cune", (=0) 521cdd96 <= check a_dn_pat: qmailGID=306,ou=accounts,o=cune 521cdd96 <= acl_mask: [1] applying none(=0) (stop) 521cdd96 <= acl_mask: [1] mask: none(=0) 521cdd96 => slap_access_allowed: read access denied by none(=0) 521cdd96 => access_allowed: no more rules 521cdd96 send_search_entry: conn 1004 access to entry (qmailUID=2,ou=accounts,o=cune) not allowed 521cdd96 send_ldap_result: conn=1004 op=1 p=3 521cdd96 send_ldap_result: err=0 matched="" text="" 521cdd96 send_ldap_response: msgid=2 tag=101 err=0 There is nothing special about the LDAP entry for Test.Entry. dn: qmailUID=2,ou=accounts,o=cune objectClass: pilotPerson objectClass: qmailUser objectClass: PureFTPdUser cn: Test Entry sn: Entry uid: Test.Entry qmailUID: 2 accountStatus: active mail: test.entry(a)cune.org userClass: stu Please let me know if you require any other information. Thank you. Russell Mosemann

1 0

Re: (ITS#7672) LMDB: mdb_dbi_flags fails with newly created DataBase
by hyc＠symas.com 27 Aug '13

27 Aug '13

sog(a)msg.com.mx wrote: > Full_Name: Salvador Ortiz > Version: 24 > OS: Linux > URL: > Submission from: (NULL) (187.162.45.111) > > > Using mdb_dbi_flags with newly created database fails or lies. mdb_dbi_flags() has been changed to take a txn instead of an env pointer. Fixed in mdb.master. > In the case of MAIN _DBI, if I set some flags in mdb_dbi_open, the flags isn't > propagated to the environment, I think the fix is simple: > > --- a/libraries/liblmdb/mdb.c > +++ b/libraries/liblmdb/mdb.c > @@ -7881,6 +7881,7 @@ int mdb_dbi_open(MDB_txn *txn, const char *name, unsigned > int flags, MDB_dbi *db > /* make sure flag changes get committed */ > if ((txn->mt_dbs[MAIN_DBI].md_flags | f2) != > txn->mt_dbs[MAIN_DBI].md_flags) { > txn->mt_dbs[MAIN_DBI].md_flags |= f2; > + txn->mt_env->me_dbflags[MAIN_DBI] = > txn->mt_dbs[MAIN_DBI].md_flags; > txn->mt_flags |= MDB_TXN_DIRTY; > } > } > > But in the case of a newly created named database, env->me_numdbs isn't adjusted > until the transaction is committed, so mdb_env_flags fails. > > The more that I think about it, seems that the proper way to get the flags of an > opened db is with a new API, something like: > > int mbd_get_flags(MDB_txn *, MDB_dbi dbi, unsigned int *flags) > { > if (txn == NULL || arg == NULL || dbi >= txn->mt_numdbs) > return EINVAL; > > *flags = txn->mt_dbflags[dbi]; > return MDB_SUCCESS; > } > > > Comments? > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#7672) LMDB: mdb_dbi_flags fails with newly created DataBase
by sog＠msg.com.mx 23 Aug '13

23 Aug '13

Full_Name: Salvador Ortiz Version: 24 OS: Linux URL: Submission from: (NULL) (187.162.45.111) Using mdb_dbi_flags with newly created database fails or lies. In the case of MAIN _DBI, if I set some flags in mdb_dbi_open, the flags isn't propagated to the environment, I think the fix is simple: --- a/libraries/liblmdb/mdb.c +++ b/libraries/liblmdb/mdb.c @@ -7881,6 +7881,7 @@ int mdb_dbi_open(MDB_txn *txn, const char *name, unsigned int flags, MDB_dbi *db /* make sure flag changes get committed */ if ((txn->mt_dbs[MAIN_DBI].md_flags | f2) != txn->mt_dbs[MAIN_DBI].md_flags) { txn->mt_dbs[MAIN_DBI].md_flags |= f2; + txn->mt_env->me_dbflags[MAIN_DBI] = txn->mt_dbs[MAIN_DBI].md_flags; txn->mt_flags |= MDB_TXN_DIRTY; } } But in the case of a newly created named database, env->me_numdbs isn't adjusted until the transaction is committed, so mdb_env_flags fails. The more that I think about it, seems that the proper way to get the flags of an opened db is with a new API, something like: int mbd_get_flags(MDB_txn *, MDB_dbi dbi, unsigned int *flags) { if (txn == NULL || arg == NULL || dbi >= txn->mt_numdbs) return EINVAL; *flags = txn->mt_dbflags[dbi]; return MDB_SUCCESS; } Comments?

1 0

Re: (ITS#7670) mdb_cursor_del() behaviour improvement
by hyc＠symas.com 23 Aug '13

23 Aug '13

spam(a)markandruth.co.uk wrote: > Full_Name: Mark Zealey > Version: git > OS: linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (88.253.191.53) > > > As per email thread with Howard, mdb_cursor_del() has a somewhat strange > behaviour when you reach the end of a page. To my mind it should skip to the > next entry. This should also be documented as at the moment there is no sign in > the docs of what happens to the cursor after a delete. Fixed now in mdb.master, cursor_del will always try to advance to the next item. > Mark Zealey wrote: >> On 23/08/13 00:07, Howard Chu wrote: >>> ... as I said already, it does exactly what you said. When you've >>> deleted the last item on the page the cursor no longer points at a >>> valid node, so GET_CURRENT returns EINVAL. >> >> OK I think that's a pretty big gotcha - it would be great to either make >> the cursor behaviour consistent (ie automatically skip to next record at >> end of a page) or to very clearly document this! It's pretty different >> from kyoto/bdb interfaces in that (to my mind at least) it requires a >> bit too much knowledge from the developer about the underlying structure >> of the database which should be abstracted by the interface. > > Yeah, this should probably be changed. Could you submit an ITS for this? Thanks. > > -- -- 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#7666) segfault when searching regex minus than 3 characters over translucent
by hyc＠symas.com 23 Aug '13

23 Aug '13

I tried to use your configuration to reproduce your error but saw no crash. Probably there are other elements of the configuration or test data missing, or the exact sequence of steps you followed is missing. theju ju wrote: > # schema.perso/c.schema > > attributetype ( 1.3.6.1.4.1.10000.13.2.20 > NAME 'Application' > DESC 'Acces sur les application' > EQUALITY caseIgnoreMatch > SUBSTR caseIgnoreSubstringsMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) > > objectclass ( 1.3.6.1.4.1.10013.2.2.1.0.0 > NAME 'cPerson' > SUP 'inetOrgPerson' > STRUCTURAL > MUST ( uid ) > MAY ( Application) ) > > > > #slapd.conf > > 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.perso/c.schema > > pidfile /var/run/slapd/slapd.pid > argsfile /var/run/slapd/slapd.args > loglevel 2 > > allow bind_v2 > > # 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 1 > > > database bdb > > # The base of your directory in database #1 > suffix "ou=People,dc=c,dc=fr" > > # rootdn directive for specifying a superuser on the database. This is needed > # for syncrepl. > rootdn "cn=admin,ou=People,dc=c,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 > > > index objectClass eq,pres > index ou,cn,mail,surname,givenname eq,pres,sub > index uid eq,pres > index Application eq,pres,sub > > > overlay translucent > > # on demande que les resultats des 2 annuaires soient mergés > translucent_no_glue off > translucent_strict off > > #liste des attribut a chercher sur l'overlay > translucent_local Application > #liste des attributs a chercher sur le master > translucent_remote > sn,GivenName,mail,street,Postalcode,l,uid,facsimileTelephoneNumber > > #activation du bind local > translucent_bind_local on > > # activation de la possibilité de changer le mot de passe > translucent_pwmod_local on > > uri ldap://ldapr.c.fr <http://ldapr.c.fr> > lastmod off > acl-bind binddn="cn=admin,ou=People,dc=c,dc=fr" credentials="password" > > access to attrs=userPassword,shadowLastChange > by dn="cn=admin,ou=People,dc=c,dc=fr" write > by anonymous auth > by self write > by * none > > access to dn.base="" > by * read > > > Ex user : > > dn: uid=w.k.1,ou=c,ou=People,dc=c,dc=fr > displayName: K W > givenName: W > postalCode: 44095 > objectClass: cPerson > uid: w.k.1 > mail: w.k(a)mail.fr <mailto:w.k@mail.fr> > cn: K W > telephoneNumber: 06 06 06 06 06 > o: C > l: MON > sn: KNAP > Application: contrat:ABC221:082534 -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#7671) LMDB cursor_next key
by hyc＠OpenLDAP.org 23 Aug '13

23 Aug '13

Full_Name: Howard Chu Version: 2.4.36 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (78.155.233.73) Submitted by: hyc When the next value to return is a duplicate value, cursor_get(MDB_NEXT_DUP) skips returning the key, because it is assumed to already be known. cursor_get(MDB_NEXT) also skips returning the key because it falls thru the same code, but in this case we cannot assume the key is already known.

1 0

(ITS#7670) mdb_cursor_del() behaviour improvement
by spam＠markandruth.co.uk 23 Aug '13

23 Aug '13

Full_Name: Mark Zealey Version: git OS: linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (88.253.191.53) As per email thread with Howard, mdb_cursor_del() has a somewhat strange behaviour when you reach the end of a page. To my mind it should skip to the next entry. This should also be documented as at the moment there is no sign in the docs of what happens to the cursor after a delete. Mark Zealey wrote: > On 23/08/13 00:07, Howard Chu wrote: >> ... as I said already, it does exactly what you said. When you've >> deleted the last item on the page the cursor no longer points at a >> valid node, so GET_CURRENT returns EINVAL. > > OK I think that's a pretty big gotcha - it would be great to either make > the cursor behaviour consistent (ie automatically skip to next record at > end of a page) or to very clearly document this! It's pretty different > from kyoto/bdb interfaces in that (to my mind at least) it requires a > bit too much knowledge from the developer about the underlying structure > of the database which should be abstracted by the interface. Yeah, this should probably be changed. Could you submit an ITS for this? Thanks.

1 0

Re: (ITS#7667) performance degradation when using MDB_INTEGERKEY
by romange＠gmail.com 21 Aug '13

21 Aug '13

--047d7b66f59964903104e4826241 Content-Type: text/plain; charset=UTF-8 Just to give some numbers: if the keys are sent in order, the insertion of 166,500,000 items finishes in about 3min. When the order is random (keys are reversed): it inserted 34,000,000 items in 548 min (the average time per item was 967usec or 1000 ops/sec). I wonder how other DBs (leveldb?) behave when number of items grows beyond several millions. On Wed, Aug 21, 2013 at 9:55 PM, Roman Gershman <romange(a)gmail.com> wrote: > Thanks! I was aware of little endian transformation. I did not know that > the change of insertion order affects write performance of the database > that much. > > > > On Wed, Aug 21, 2013 at 12:54 AM, Howard Chu <hyc(a)symas.com> wrote: > >> romange(a)gmail.com wrote: >> >>> --001a11c1e98008372804e46726c2 >>> Content-Type: text/plain; charset=UTF-8 >>> >>> >>> Hi, I extracted a small dataset that shows the problem. >>> you can download it from here: >>> https://docs.google.com/file/**d/**0B6o29pwkWoERdnFSaUtMNDljemc/** >>> edit?usp=sharing<https://docs.google.com/file/d/0B6o29pwkWoERdnFSaUtMNDljemc/edit?usp=sharing> >>> >>> I modified mdb_copy.c to demonstrate the difference. copy it to source >>> dir >>> from here >>> https://docs.google.com/file/**d/**0B6o29pwkWoERd3VuUm1DN0FpcUU/** >>> edit?usp=sharing<https://docs.google.com/file/d/0B6o29pwkWoERd3VuUm1DN0FpcUU/edit?usp=sharing> >>> >>> build and >>> run "time ./mdb_copy foo foo2" >>> after this change the flag at line 64 and run it again. >>> at my computer the difference is 17s vs 1.7s for 3 million items. >>> >> >> This test doesn't prove the existence of a bug. You're running on a >> Little-Endian machine, therefore data that is in sorted order as a string >> is in hashed order when used as an integer. Your data insert turns into a >> worst-case insert order in this case, causing the worst possible random >> access strides through memory. Assuming the two orders to be equivalent is >> a pretty common mistake for DB programmers. Microsoft has done the same >> thing in ActiveDirectory, I mentioned it here a few years ago >> http://www.openldap.org/lists/**openldap-devel/200711/**msg00002.html<http://www.openldap.org/lists/openldap-devel/200711/msg00002.html> >> >> If you had run this test on a Big-Endian machine, like SPARC, the insert >> order would be identical either way, and INTEGERKEY result would have been >> faster. >> >> Closing this ITS, no bug. >> >> >>> >>> >>> On Tue, Aug 20, 2013 at 9:04 PM, Quanah Gibson-Mount <quanah(a)zimbra.com >>> >wrote: >>> >>> --On Sunday, August 18, 2013 11:46 AM +0000 romange(a)gmail.com wrote: >>>> >>>> Full_Name: Roman Gershman >>>> >>>>> Version: >>>>> OS: linux 3.8.0-25-generic >>>>> URL: >>>>> Submission from: (NULL) (212.150.97.210) >>>>> >>>>> >>>> Please provide further information, specifically: >>>> >>>> The size of values >>>> Insert order >>>> Sample code if possible >>>> >>>> Thanks, >>>> Quanah >>>> >>>> >>>> -- >>>> >>>> Quanah Gibson-Mount >>>> Lead Engineer >>>> Zimbra, Inc >>>> -------------------- >>>> Zimbra :: the leader in open source messaging and collaboration >>>> >>>> >>> >>> >>> >> >> -- >> -- Howard Chu >> CTO, Symas Corp. http://www.symas.com >> Director, Highland Sun http://highlandsun.com/hyc/ >> Chief Architect, OpenLDAP http://www.openldap.org/**project/<http://www.openldap.org/project/> >> > > > > -- > Best regards, > Roman > -- Best regards, Roman --047d7b66f59964903104e4826241 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Just to give some numbers: if the keys are sent in order, = the insertion of=C2=A0166,500,000 items finishes in about 3min.<div>When th= e order is random (keys are reversed): it inserted 34,000,000 items in 548 = min (the average time per item was 967usec or 1000 ops/sec).</div> <div> </div><div>I wonder how other DBs (leveldb?) behave when number of= items grows beyond several millions.</div></div><div class=3D"gmail_extra"= > <div class=3D"gmail_quote">On Wed, Aug 21, 2013 at 9:55 PM, Roman = Gershman <<a href=3D"mailto:romange@gmail.com" target= =3D"_blank">romange(a)gmail.com</a>> wrote: <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra">= Thanks! I was aware of little endian transformation. I did not know that th= e change of insertion order affects write performance of the database that = much.=C2=A0</div> <div class=3D"gmail_extra"> </div><div class=3D"gmail_extra"> </div><div class=3D"gmail_extra"><= div><div class=3D"h5"> <div class=3D"gmail_quote">On Wed, Aug 21, <a hre= f=3D"tel:2013" value=3D"+9722013" target=3D"_blank">2013</a> at 12:54 AM, H= oward Chu <<a href=3D"mailto:hyc@symas.com" target=3D"= _blank">hyc(a)symas.com</a>> wrote: <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><a href=3D"mailto:romange@gmail.com" target= =3D"_blank">romange(a)gmail.com</a> wrote: <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> --001a11c1e98008372804e46726c2 Content-Type: text/plain; charset=3DUTF-8<div> Hi, I extracted a small dataset that shows the problem. you can download it from here: <a href=3D"https://docs.google.com/file/d/0B6o29pwkWoERdnFSaUtMNDljemc/edit= ?usp=3Dsharing" target=3D"_blank">https://docs.google.com/file/d/= 0B6o29pwkWoERdnFSaUtMNDljemc/edit?usp=3Dsharing</a> I modified mdb_copy.c to demonstrate the difference. copy it to source dir<= br> from here <a href=3D"https://docs.google.com/file/d/0B6o29pwkWoERd3VuUm1DN0FpcUU/edit= ?usp=3Dsharing" target=3D"_blank">https://docs.google.com/file/d/= 0B6o29pwkWoERd3VuUm1DN0FpcUU/edit?usp=3Dsharing</a> build and run "time ./mdb_copy foo foo2" after this change the flag at line 64 and run it again. at my computer the difference is 17s vs 1.7s for 3 million items. </div></blockquote> This test doesn't prove the existence of a bug. You're running on a= Little-Endian machine, therefore data that is in sorted order as a string = is in hashed order when used as an integer. Your data insert turns into a w= orst-case insert order in this case, causing the worst possible random acce= ss strides through memory. Assuming the two orders to be equivalent is a pr= etty common mistake for DB programmers. Microsoft has done the same thing i= n ActiveDirectory, I mentioned it here a few years ago <a href=3D"http://ww= w.openldap.org/lists/openldap-devel/200711/msg00002.html" target=3D"_blank"= >http://www.openldap.org/lists/openldap-devel/200711/msg00002= .html</a> If you had run this test on a Big-Endian machine, like SPARC, the insert or= der would be identical either way, and INTEGERKEY result would have been fa= ster. Closing this ITS, no bug.<div><div> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> On Tue, Aug 20, <a href=3D"tel:2013" value=3D"+9722013" target=3D"_blank">2= 013</a> at 9:04 PM, Quanah Gibson-Mount <<a href=3D"mailto:quanah@zimbra= .com" target=3D"_blank">quanah(a)zimbra.com</a>>wrote: <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> --On Sunday, August 18, <a href=3D"tel:2013" value=3D"+9722013" target=3D"_= blank">2013</a> 11:46 AM +0000 <a href=3D"mailto:romange@gmail.com" target= =3D"_blank">romange(a)gmail.com</a> wrote: =C2=A0 Full_Name: Roman Gershman <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Version: OS: linux 3.8.0-25-generic URL: Submission from: (NULL) (212.150.97.210) </blockquote> Please provide further information, specifically: The size of values Insert order Sample code if possible Thanks, Quanah -- Quanah Gibson-Mount Lead Engineer Zimbra, Inc -------------------- Zimbra :: =C2=A0the leader in open source messaging and collaboration </blockquote> </blockquote> -- </div></div> =C2=A0 -- Howard Chu =C2=A0 CTO, Symas Corp. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"http:= //www.symas.com" target=3D"_blank">http://www.symas.com</a> =C2=A0 Director, Highland Sun =C2=A0 =C2=A0 <a href=3D"http://highlandsun.c= om/hyc/" target=3D"_blank">http://highlandsun.com/hyc/</a> =C2=A0 Chief Architect, OpenLDAP =C2=A0<a href=3D"http://www.openldap.org/p= roject/" target=3D"_blank">http://www.openldap.org/project/</a> </blockquote></div> <div> </div></div= ></div>-- Best regards,<= br>=C2=A0 =C2=A0=C2=A0 Roman </div></div> </blockquote></div> <div> </div>-- Best regards= , =C2=A0 =C2=A0=C2=A0 Roman </div> --047d7b66f59964903104e4826241--

1 0

Re: (ITS#7667) performance degradation when using MDB_INTEGERKEY
by romange＠gmail.com 21 Aug '13

21 Aug '13

--f46d043c7d22cec95604e479b9f8 Content-Type: text/plain; charset=UTF-8 Thanks! I was aware of little endian transformation. I did not know that the change of insertion order affects write performance of the database that much. On Wed, Aug 21, 2013 at 12:54 AM, Howard Chu <hyc(a)symas.com> wrote: > romange(a)gmail.com wrote: > >> --001a11c1e98008372804e46726c2 >> Content-Type: text/plain; charset=UTF-8 >> >> >> Hi, I extracted a small dataset that shows the problem. >> you can download it from here: >> https://docs.google.com/file/**d/**0B6o29pwkWoERdnFSaUtMNDljemc/** >> edit?usp=sharing<https://docs.google.com/file/d/0B6o29pwkWoERdnFSaUtMNDljemc/edit?usp=sharing> >> >> I modified mdb_copy.c to demonstrate the difference. copy it to source dir >> from here >> https://docs.google.com/file/**d/**0B6o29pwkWoERd3VuUm1DN0FpcUU/** >> edit?usp=sharing<https://docs.google.com/file/d/0B6o29pwkWoERd3VuUm1DN0FpcUU/edit?usp=sharing> >> >> build and >> run "time ./mdb_copy foo foo2" >> after this change the flag at line 64 and run it again. >> at my computer the difference is 17s vs 1.7s for 3 million items. >> > > This test doesn't prove the existence of a bug. You're running on a > Little-Endian machine, therefore data that is in sorted order as a string > is in hashed order when used as an integer. Your data insert turns into a > worst-case insert order in this case, causing the worst possible random > access strides through memory. Assuming the two orders to be equivalent is > a pretty common mistake for DB programmers. Microsoft has done the same > thing in ActiveDirectory, I mentioned it here a few years ago > http://www.openldap.org/lists/**openldap-devel/200711/**msg00002.html<http://www.openldap.org/lists/openldap-devel/200711/msg00002.html> > > If you had run this test on a Big-Endian machine, like SPARC, the insert > order would be identical either way, and INTEGERKEY result would have been > faster. > > Closing this ITS, no bug. > > >> >> >> On Tue, Aug 20, 2013 at 9:04 PM, Quanah Gibson-Mount <quanah(a)zimbra.com >> >wrote: >> >> --On Sunday, August 18, 2013 11:46 AM +0000 romange(a)gmail.com wrote: >>> >>> Full_Name: Roman Gershman >>> >>>> Version: >>>> OS: linux 3.8.0-25-generic >>>> URL: >>>> Submission from: (NULL) (212.150.97.210) >>>> >>>> >>> Please provide further information, specifically: >>> >>> The size of values >>> Insert order >>> Sample code if possible >>> >>> Thanks, >>> Quanah >>> >>> >>> -- >>> >>> Quanah Gibson-Mount >>> Lead Engineer >>> Zimbra, Inc >>> -------------------- >>> Zimbra :: the leader in open source messaging and collaboration >>> >>> >> >> >> > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/**project/<http://www.openldap.org/project/> > -- Best regards, Roman --f46d043c7d22cec95604e479b9f8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra">Thanks! I was aware of little e= ndian transformation. I did not know that the change of insertion order aff= ects write performance of the database that much.=C2=A0</div><div class=3D"= gmail_extra"> </div><div class=3D"gmail_extra"> </div><div class=3D"gmail_extra"><= br><div class=3D"gmail_quote">On Wed, Aug 21, <a href=3D"tel:2013" value=3D= "+9722013" target=3D"_blank">2013</a> at 12:54 AM, Howard Chu <<a href=3D"mailto:hyc@symas.com" target=3D"_blank">hyc(a)symas.com</= a>> wrote: <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><a href=3D"mailto:romange@gmail.com" target= =3D"_blank">romange(a)gmail.com</a> wrote: <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> --001a11c1e98008372804e46726c2 Content-Type: text/plain; charset=3DUTF-8<div> Hi, I extracted a small dataset that shows the problem. you can download it from here: <a href=3D"https://docs.google.com/file/d/0B6o29pwkWoERdnFSaUtMNDljemc/edit= ?usp=3Dsharing" target=3D"_blank">https://docs.google.com/file/d/= 0B6o29pwkWoERdnFSaUtMNDljemc/edit?usp=3Dsharing</a> I modified mdb_copy.c to demonstrate the difference. copy it to source dir<= br> from here <a href=3D"https://docs.google.com/file/d/0B6o29pwkWoERd3VuUm1DN0FpcUU/edit= ?usp=3Dsharing" target=3D"_blank">https://docs.google.com/file/d/= 0B6o29pwkWoERd3VuUm1DN0FpcUU/edit?usp=3Dsharing</a> build and run "time ./mdb_copy foo foo2" after this change the flag at line 64 and run it again. at my computer the difference is 17s vs 1.7s for 3 million items. </div></blockquote> This test doesn't prove the existence of a bug. You're running on a= Little-Endian machine, therefore data that is in sorted order as a string = is in hashed order when used as an integer. Your data insert turns into a w= orst-case insert order in this case, causing the worst possible random acce= ss strides through memory. Assuming the two orders to be equivalent is a pr= etty common mistake for DB programmers. Microsoft has done the same thing i= n ActiveDirectory, I mentioned it here a few years ago <a href=3D"http://ww= w.openldap.org/lists/openldap-devel/200711/msg00002.html" target=3D"_blank"= >http://www.openldap.org/lists/openldap-devel/200711/msg00002= .html</a> If you had run this test on a Big-Endian machine, like SPARC, the insert or= der would be identical either way, and INTEGERKEY result would have been fa= ster. Closing this ITS, no bug.<div><div> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> On Tue, Aug 20, <a href=3D"tel:2013" value=3D"+9722013" target=3D"_blank">2= 013</a> at 9:04 PM, Quanah Gibson-Mount <<a href=3D"mailto:quanah@zimbra= .com" target=3D"_blank">quanah(a)zimbra.com</a>>wrote: <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> --On Sunday, August 18, <a href=3D"tel:2013" value=3D"+9722013" target=3D"_= blank">2013</a> 11:46 AM +0000 <a href=3D"mailto:romange@gmail.com" target= =3D"_blank">romange(a)gmail.com</a> wrote: =C2=A0 Full_Name: Roman Gershman <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Version: OS: linux 3.8.0-25-generic URL: Submission from: (NULL) (212.150.97.210) </blockquote> Please provide further information, specifically: The size of values Insert order Sample code if possible Thanks, Quanah -- Quanah Gibson-Mount Lead Engineer Zimbra, Inc -------------------- Zimbra :: =C2=A0the leader in open source messaging and collaboration </blockquote> </blockquote> -- </div></div> =C2=A0 -- Howard Chu =C2=A0 CTO, Symas Corp. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"http:= //www.symas.com" target=3D"_blank">http://www.symas.com</a> =C2=A0 Director, Highland Sun =C2=A0 =C2=A0 <a href=3D"http://highlandsun.c= om/hyc/" target=3D"_blank">http://highlandsun.com/hyc/</a> =C2=A0 Chief Architect, OpenLDAP =C2=A0<a href=3D"http://www.openldap.org/p= roject/" target=3D"_blank">http://www.openldap.org/project/</a> </blockquote></div> <div> </div>-- <b= r>Best regards, =C2=A0 =C2=A0=C2=A0 Roman </div></div> --f46d043c7d22cec95604e479b9f8--

1 0

(ITS#7669) tool_bind in common.c should be doing conditional assert
by k.venkata.kiran＠ericsson.com 21 Aug '13

21 Aug '13

Full_Name: Venkata Kiran K Version: 2.4.35 OS: linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (192.71.175.12) tool_bind has below assert which might be hit when nsctrls is not updated assert(nsctrls < (int) (sizeof(sctrls) / sizeof(sctrls[0])));

1 0

Re: (ITS#7667) performance degradation when using MDB_INTEGERKEY
by hyc＠symas.com 20 Aug '13

20 Aug '13

romange(a)gmail.com wrote: > --001a11c1e98008372804e46726c2 > Content-Type: text/plain; charset=UTF-8 > > Hi, I extracted a small dataset that shows the problem. > you can download it from here: > https://docs.google.com/file/d/0B6o29pwkWoERdnFSaUtMNDljemc/edit?usp=sharing > > I modified mdb_copy.c to demonstrate the difference. copy it to source dir > from here > https://docs.google.com/file/d/0B6o29pwkWoERd3VuUm1DN0FpcUU/edit?usp=sharing > > build and > run "time ./mdb_copy foo foo2" > after this change the flag at line 64 and run it again. > at my computer the difference is 17s vs 1.7s for 3 million items. This test doesn't prove the existence of a bug. You're running on a Little-Endian machine, therefore data that is in sorted order as a string is in hashed order when used as an integer. Your data insert turns into a worst-case insert order in this case, causing the worst possible random access strides through memory. Assuming the two orders to be equivalent is a pretty common mistake for DB programmers. Microsoft has done the same thing in ActiveDirectory, I mentioned it here a few years ago http://www.openldap.org/lists/openldap-devel/200711/msg00002.html If you had run this test on a Big-Endian machine, like SPARC, the insert order would be identical either way, and INTEGERKEY result would have been faster. Closing this ITS, no bug. > > > > On Tue, Aug 20, 2013 at 9:04 PM, Quanah Gibson-Mount <quanah(a)zimbra.com>wrote: > >> --On Sunday, August 18, 2013 11:46 AM +0000 romange(a)gmail.com wrote: >> >> Full_Name: Roman Gershman >>> Version: >>> OS: linux 3.8.0-25-generic >>> URL: >>> Submission from: (NULL) (212.150.97.210) >>> >> >> Please provide further information, specifically: >> >> The size of values >> Insert order >> Sample code if possible >> >> Thanks, >> Quanah >> >> >> -- >> >> Quanah Gibson-Mount >> Lead Engineer >> Zimbra, Inc >> -------------------- >> Zimbra :: the leader in open source messaging and collaboration >> > > > -- -- 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#7667) performance degradation when using MDB_INTEGERKEY
by romange＠gmail.com 20 Aug '13

20 Aug '13

--001a11c1e98008372804e46726c2 Content-Type: text/plain; charset=UTF-8 Hi, I extracted a small dataset that shows the problem. you can download it from here: https://docs.google.com/file/d/0B6o29pwkWoERdnFSaUtMNDljemc/edit?usp=sharing I modified mdb_copy.c to demonstrate the difference. copy it to source dir from here https://docs.google.com/file/d/0B6o29pwkWoERd3VuUm1DN0FpcUU/edit?usp=sharing build and run "time ./mdb_copy foo foo2" after this change the flag at line 64 and run it again. at my computer the difference is 17s vs 1.7s for 3 million items. On Tue, Aug 20, 2013 at 9:04 PM, Quanah Gibson-Mount <quanah(a)zimbra.com>wrote: > --On Sunday, August 18, 2013 11:46 AM +0000 romange(a)gmail.com wrote: > > Full_Name: Roman Gershman >> Version: >> OS: linux 3.8.0-25-generic >> URL: >> Submission from: (NULL) (212.150.97.210) >> > > Please provide further information, specifically: > > The size of values > Insert order > Sample code if possible > > Thanks, > Quanah > > > -- > > Quanah Gibson-Mount > Lead Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration > -- Best regards, Roman --001a11c1e98008372804e46726c2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div>Hi, I extracted a small dataset that shows the proble= m.</div><div>you can download it from here: <a href=3D"https://docs.google.= com/file/d/0B6o29pwkWoERdnFSaUtMNDljemc/edit?usp=3Dsharing">https://docs.go= ogle.com/file/d/0B6o29pwkWoERdnFSaUtMNDljemc/edit?usp=3Dsharing</a></div> <div> </div><div>I modified mdb_copy.c to demonstrate the difference. co= py it to source dir from here <a href=3D"https://docs.google.com/file/d/0B6= o29pwkWoERd3VuUm1DN0FpcUU/edit?usp=3Dsharing">https://docs.google.com/file/= d/0B6o29pwkWoERd3VuUm1DN0FpcUU/edit?usp=3Dsharing</a></div> <div> </div><div>build and=C2=A0</div><div>run "time ./mdb_copy foo= foo2"</div><div>after this change the flag at line 64 and run it agai= n.</div><div>at my computer the difference is 17s vs 1.7s for 3 million ite= ms.</div> <div> </div></div><div class=3D"gmail_extra"> <div class=3D"gmail= _quote">On Tue, Aug 20, 2013 at 9:04 PM, Quanah Gibson-Mount <<a href=3D"mailto:quanah@zimbra.com" target=3D"_blank">quanah@zimbr= a.com</a>> wrote: <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex">--On Sunday, August 18, <a href=3D"tel:2013"= value=3D"+9722013" target=3D"_blank">2013</a> 11:46 AM +0000 <a href=3D"ma= ilto:romange@gmail.com" target=3D"_blank">romange(a)gmail.com</a> wrote: <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Full_Name: Roman Gershman Version: OS: linux 3.8.0-25-generic URL: Submission from: (NULL) (212.150.97.210) </blockquote> Please provide further information, specifically: The size of values Insert order Sample code if possible Thanks, Quanah -- Quanah Gibson-Mount Lead Engineer Zimbra, Inc -------------------- Zimbra :: =C2=A0the leader in open source messaging and collaboration </blockquote></div> <div> </div>-- Best regards= , =C2=A0 =C2=A0=C2=A0 Roman </div> --001a11c1e98008372804e46726c2--

1 0

Re: (ITS#7667) performance degradation when using MDB_INTEGERKEY
by quanah＠zimbra.com 20 Aug '13

20 Aug '13

--On Sunday, August 18, 2013 11:46 AM +0000 romange(a)gmail.com wrote: > Full_Name: Roman Gershman > Version: > OS: linux 3.8.0-25-generic > URL: > Submission from: (NULL) (212.150.97.210) Please provide further information, specifically: The size of values Insert order Sample code if possible Thanks, Quanah -- Quanah Gibson-Mount Lead Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7668) LMDB enhancement, corruption detection
by hyc＠OpenLDAP.org 20 Aug '13

20 Aug '13

Full_Name: Howard Chu Version: LMDB 0.9.7 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (78.155.233.73) Submitted by: hyc Currently LMDB always stores two snapshots of the environment, one in each of the two meta pages. For ongoing operation it simply uses the one with the higher transaction number; the older one is ignored. If a power failure occurs at the instant that a transaction commit is occurring, it is possible for the meta page write to be corrupted in the storage device. Storage devices use ECC to detect (and sometimes recover from) these problems; if the error cannot be corrected then an attempt to read this sector will fail and the OS may tell the application that the read failed with an I/O error. In mdb_env_read_header() we currently attempt to read both header pages but completely fail the mdb_env_open() if an error occurs. Instead, we should always attempt to read both pages (assuming the file was not truncated, and both pages really were written before). If both pages exist but we only successfully read one, we should allow the env_open() to proceed in Read-Only mode, and return an error code to the caller indicating this situation. E.g., MDB_NEEDS_BACKUP. The point being, the user should use mdb_copy(1) to make a backup of the environment ASAP and should not be able to do anything else to the environment in the meantime. It's been suggested that LMDB should also use its own CRC on the meta page, to detect more subtle corruptions. We may consider adding this as well, but obviously this would be an on-disk format change. My personal view is this is what ECC DRAM is for. The primary argument for it is the possibility (again, during a power faiure) for the contents of the storage device's write buffer to be corrupted while writing to the meta page. I.e., ECC may have protected the data all the way from the host to the storage device, but if the device was in the middle of writing the sector when the power failure occurred, the write may have completed, but the buffer DRAM may have been losing charge while the write was happening. Again, I'm skeptical that corruptions of this sort would not be detected by the device's own ECC checks. While we're at it, it may be useful to include an env_open() flag explicitly requesting use of the older meta page. This flag would only be valid in conjunction with MDB_RDONLY. It would allow using mdb_copy to make a backup of the previous environment snapshot.

1 0

(ITS#7667) performance degradation when using MDB_INTEGERKEY
by romange＠gmail.com 18 Aug '13

18 Aug '13

Full_Name: Roman Gershman Version: OS: linux 3.8.0-25-generic URL: Submission from: (NULL) (212.150.97.210) The program writes into mdb database 100 million key,value pairs. All keys are 64bit integers. If we open the new database with mdb_dbi_open(txn, NULL, 0, &dbi); it has excellent performance - writes are done very quickly. However if we open it with "mdb_dbi_open(txn, NULL, MDB_INTEGERKEY, &dbi)" (and this is the only change in the code) its performance quickly deteriorates and after it writes several million items to the clean db the difference in write times becomes 2 orders of magnitude or even more compared to the previous setting. We used the source from git repository git://gitorious.org/mdb/mdb.git at commit id 214e9ed07d566307f22e16d0c1f1f57be9504a3b

1 0

Re: (ITS#7616) syncrepl enhancement: defer requests when refreshing
by hyc＠symas.com 14 Aug '13

14 Aug '13

hyc(a)symas.com wrote: > Michael Ströder wrote: >> hyc(a)symas.com wrote: >>> I was considering returning LDAP_BUSY for this case, but it may make more >>> sense to return a REFERRAL to the provider instead. (Although again, if we >>> have two MMR servers pointed at each other starting at the same time, they >>> would just refer to each other and clients would get nowhere until one of them >>> finishes its refresh.) >> >> IMO referrals are harmful. >> Just returning LDAP_BUSY seems best to me because if reliable HA is really >> important for a deployment you have decent load-balancers in front of your >> LDAP server which should do a proper health-check. > > Agreed. > >> Just a question: Is this database-specific? Maybe only one of several DBs is >> in this initial syncrepl phase and access to others should simply work. > > Overlays are db-specific. > A similar feature was already implemented, and never documented: commit 9e00b6cc6ce2857490b33218bdaf1339319c5f60 Author: Howard Chu <hyc(a)openldap.org> Date: Fri Apr 15 11:13:38 2011 -0700 Add strictrefresh syncrepl option Only affects delta-syncrepl - stop listening to clients while refresh is running. This is a bit more extreme though, it terminates all client connections and suspends the slapd listeners while a refresh is running. The solution discussed in this ITS would be preferable. -- -- 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#7666) segfault when searching regex minus than 3 characters over translucent
by theju3434＠gmail.com 14 Aug '13

14 Aug '13

--047d7b86f532b361c704e3e79cfd Content-Type: text/plain; charset=ISO-8859-1 Sorry, Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffb164d700 (LWP 18682)] 0x00007ffff678d0bc in ?? () from /lib/libc.so.6 (gdb) bt full #0 0x00007ffff678d0bc in ?? () from /lib/libc.so.6 No symbol table info available. #1 0x00000000005720a1 in avl_find (root=0xd13ea0, data=0x7fffb14cb0a0, fcmp=0x4da000 <bdb_rdn_cmp>) at avl.c:545 cmp = <value optimized out> #2 0x00000000004dae90 in bdb_cache_find_ndn (op=<value optimized out>, txn=<value optimized out>, ndn=0xb3cda0, res=0x7fffb164b5e8) at cache.c:443 bdb = 0x97bf20 ei = {bei_parent = 0x97bfa0, bei_id = 140736167981340, bei_lockpad = -20208, bei_state = -20148, bei_finders = 32767, bei_nrdn = {bv_len = 23, bv_val = 0x1b <Address 0x1b out of bounds>}, bei_e = 0x0, bei_kids = 0x0, bei_kids_mutex = {__data = {__lock = 270, __count = 0, __owner = 16, __nusers = 0, __kind = -1320374016, __spins = 32767, __list = {__prev = 0x7fffb14cb102, __next = 0x0}}, __size = "\016\001\000\000\000\000\000\000\020\000\000\000\000\000\000\000\000\261L\261\377\177\000\000\002\261L\261\377\177\000\000\000\000\000\000\000\000\000", __align = 270}, bei_lrunext = 0x633d646975330000, bei_lruprev = 0x69622e657269616c} eip = 0x97bfa0 ei2 = 0xa5eda0 rc = <value optimized out> ptr = 0x1b <Address 0x1b out of bounds> #3 0x00000000004db460 in bdb_cache_find_id (op=0xa652f0, tid=<value optimized out>, id=<value optimized out>, eip=0x7fffb164b5e8, flag=2, lock=0x7fffb164b570) at cache.c:923 bdb = 0x97bf20 ep = 0xb3cd88 rc = <value optimized out> load = <value optimized out> ei = {bei_parent = 0x0, bei_id = 1331, bei_lockpad = 0, bei_state = 0, bei_finders = 0, bei_nrdn = {bv_len = 0, bv_val = 0x0}, bei_e = 0x0, bei_kids = 0x0, bei_kids_mutex = { __data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, bei_lrunext = 0x0, bei_lruprev = 0x0} #4 0x000000000049b274 in bdb_search (op=0xa652f0, rs=0x7fffb164ca40) at search.c:737 scopeok = <value optimized out> bdb = 0x97bf20 id = <value optimized out> cursor = 1331 lastid = 18446744073709551615 candidates = {18446744073709551615, 1, 1358, 96, 130, 225, 243, 267, 305, 325, 402, 420, 430, 464, 494, 518, 585, 606, 683, 762, 774, 854, 904, 1006, 1010, 0 <repeats 131047 times>} scopes = {0 <repeats 64885 times>, 112, 0, 140737330949800, 0, 96, 30064771072, 140737330949744, 144, 30064771072, 0, 96, 140737330949696, 96, 140736169549664, 140736169549856, 18678, 140737327905904, 0, 96, 140736169554240, 140736169554064, 140736169549664, 140737328407145, 8589950976, 33022, 4857321309812969474, 140736169549712, 0, 0, 4295000064, 0, 72057594037927936, 140736169549760, 0, 140737328406892, 8589940736, 0, 10485842016695418880, 140736169549808, 0, 0, 4294969344, 0, 72058143793676288, 0, 0, 140737328406892, 562962838323220, 80222775637897, 4294967296, 65556, 0, 1688935776387072, 18446744073709551615, 2044404433372, 563035852767296, 80222775637897, 12842975242, 141828410114068, 18398981297188896768, 1688936890543102, 18446744073709551615, 2065879269857, 0 <repeats 265 times>, 140737346106200, 0, 0, 24, 140737346106200, 140736169552160, 0, 24, 140736169552272, 140736169552192, 0, 0, 0, 2050, 17, 1, 5909838, 0, 13733440, 17, 5910105, 0 <repeats 33 times>, 5709985, 140736169555760, 140736169560672, 140736169555920, 4603268, 12663952, 4597084, 0 <repeats 19 times>, 5709985, 140736169555968, 140736169560672, 140736169556192, 4603268, 140736169556112, 4597084, 140736169556144, 4603268, 140736169556120, 4597084, 0, 5709985, 140736169556064, 140736169556224, 12663576, 4603268, 140736169556232, 4597084, 0, 1, 5949064, 5949064, 0, 0, 0, 0, 140736169554320, 0, 5949054, 0, 140736169554752, 140736169554736, 7, 140736169555104, 140736169554752, 140737327689241, 140736169553280, 1, 6046159, 6046159, 140736169554416, 18446744073709551615, 12664240, 140736169554280, 140736169554464, 0, 6046156, 0, 140736169554896, 140736169554880, 3, 140736169555248, 140736169554896, 140737327689241, 140736169553424, 2, 5948970, 5948970, 140733193388032, 18446744069414584320, 115, 140736169554424, 140736169554608, 0, 5948966, 0, 0, 140736169554716...} e = 0xb3cd88 base = {e_id = 1, e_name = {bv_len = 140736169554992, bv_val = 0xa64a9a ""}, e_nname = {bv_len = 23, bv_val = 0xd18db0 "ou=people,dc=c,dc=fr"}, e_attrs = 0x7ffff69e2e40, e_ocflags = 0, e_bv = {bv_len = 10898074, bv_val = 0xa64aa0 ""}, e_private = 0xa659c0} e_root = <value optimized out> matched = 0x0 ei = 0x0 realbase = {bv_len = 23, bv_val = 0xd18db0 "ou=people,dc=c,dc=fr"} mask = <value optimized out> manageDSAit = <value optimized out> tentries = 1358 nentries = <value optimized out> idflag = 2 lock = {off = 0, ndx = 270, gen = 248, mode = DB_LOCK_READ} opinfo = 0x0 ltid = 0xa658b0 oex = <value optimized out> #5 0x0000000000489077 in overlay_op_walk (op=0xa652f0, rs=0x7fffb164ca40, which=<value optimized out>, oi=0x9b99a0, on=0x0) at backover.c:671 rc = 32768 #6 0x000000000055f546 in translucent_search (op=0xa652f0, rs=0x7fffb164ca40) at translucent.c:1122 on = 0x9b9b80 ov = 0x9b9d60 cb = {sc_next = 0x7fffb164b930, sc_response = 0x55f680 <translucent_search_cb>, sc_cleanup = 0, sc_private = 0x7fffb164b6c0} tc = {db = 0x7fffb164b7a0, on = 0x9b9b80, orig = 0xc13ce8, list = 0x0, step = 1, slimit = 500000, attrs = 0x0} fl = 0xc13da0 fr = 0x0 rc = 0 #7 0x0000000000488f8a in overlay_op_walk (op=0xa652f0, rs=0x7fffb164ca40, which=<value optimized out>, oi=0x9b99a0, on=0x9b9b80) at backover.c:661 rc = -1318794336 #8 0x0000000000489a57 in over_op_func (op=0xa652f0, rs=0x1b, which=23) at backover.c:723 oi = 0x48fa on = 0x97bfd8 be = 0x97bd80 db = {bd_info = 0x844bc0, bd_self = 0x97bd80, be_ctrls = "\000\000\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001", '\000' <repeats 15 times>, "\001", be_flags = 2315, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x97d380, be_nsuffix = 0x97d4b0, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = { bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 32, bv_val = 0x97d5c0 "cn=admin,ou=People,dc=c,dc=fr"}, be_rootndn = {bv_len = 32, bv_val = 0x97d610 "cn=admin,ou=people,dc=c,dc=fr"}, be_rootpw = {bv_len = 9, bv_val = 0x97d460 "password"}, be_max_deref_depth = 15, be_def_limit = { lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 500000, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x0, be_acl = 0x9bc820, be_dfltaccess = ACL_READ, be_extra_anlist = 0x0, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0xa5b830, be_pcl_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0x849580, be_private = 0x97bf20, be_next = {stqe_next = 0x9bd7c0}} cb = {sc_next = 0x0, sc_response = 0x488d00 <over_back_response>, sc_cleanup = 0, sc_private = 0x9b99a0} sc = <value optimized out> rc = 27 __PRETTY_FUNCTION__ = "over_op_func" #9 0x0000000000424151 in fe_op_search (op=0xa652f0, rs=0x7fffb164ca40) at search.c:402 bd = 0x851ca0 #10 0x000000000042497c in do_search (op=0xa652f0, rs=0x7fffb164ca40) at search.c:247 base = {bv_len = 23, bv_val = 0xd1bef7 "ou=People,dc=c,dc=fr"} siz = 0 i = 140736169560992 #11 0x0000000000421eb9 in connection_operation (ctx=0x7fffb164cba0, arg_v=<value optimized out>) at connection.c:1155 rc = <value optimized out> cancel = <value optimized out> op = 0xa652f0 rs = {sr_type = REP_SEARCH, sr_tag = 0, sr_msgid = 0, sr_err = 5, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = {sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 4, r_v2ref = 0x0}, sru_sasl = {r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}}, sr_flags = 0} tag = 99 opidx = SLAP_OP_SEARCH conn = 0x7ffff7f3fed0 memctx = 0xa64b10 memctx_null = 0x0 __PRETTY_FUNCTION__ = "connection_operation" #12 0x00000000004226a5 in connection_read_thread (ctx=<value optimized out>, argv=<value optimized out>) at connection.c:1291 s = 17 #13 0x0000000000576780 in ldap_int_thread_pool_wrapper (xpool=<value optimized out>) at tpool.c:688 pool = 0x9259b0 task = 0xa63430 work_list = <value optimized out> ctx = {ltu_id = 140736169563904, ltu_key = {{ltk_key = 0x420bb0, ltk_data = 0xa65740, ltk_free = 0x420c80 <conn_counter_destroy>}, {ltk_key = 0x474e80, ltk_data = 0xa64b10, ltk_free = 0x474ea0 <slap_sl_mem_destroy>}, {ltk_key = 0x435150, ltk_data = 0x0, ltk_free = 0x434f30 <slap_op_q_destroy>}, {ltk_key = 0xa5b850, ltk_data = 0xa658b0, ltk_free = 0x4d9810 <bdb_reader_free>}, {ltk_key = 0x499860, ltk_data = 0x7fffafe4c010, ltk_free = 0x499930 <search_stack_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 24 times>, {ltk_key = 0x0, ltk_data = 0x7ffff7850927, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}}} kctx = <value optimized out> keyslot = 74 hash = <value optimized out> __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #14 0x00007ffff784f8ca in start_thread () from /lib/libpthread.so.0 No symbol table info available. #15 0x00007ffff6754b6d in clone () from /lib/libc.so.6 No symbol table info available. #16 0x0000000000000000 in ?? () No symbol table info available. Thank you Ju --047d7b86f532b361c704e3e79cfd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div><div>Sorry, Program received signal SIGSEGV, S= egmentation fault. [Switching to Thread 0x7fffb164d700 (LWP 18682)] 0= x00007ffff678d0bc in ?? () from /lib/libc.so.6 (gdb)=A0 bt full #0=A0= 0x00007ffff678d0bc in ?? () from /lib/libc.so.6 No symbol table info available. #1=A0 0x00000000005720a1 in avl_find (ro= ot=3D0xd13ea0, data=3D0x7fffb14cb0a0, fcmp=3D0x4da000 <bdb_rdn_cmp>) = at avl.c:545 =A0=A0=A0=A0=A0=A0=A0 cmp =3D <value optimized out><b= r>#2=A0 0x00000000004dae90 in bdb_cache_find_ndn (op=3D<value optimized = out>, txn=3D<value optimized out>, ndn=3D0xb3cda0, res=3D0x7fffb16= 4b5e8) at cache.c:443 =A0=A0=A0=A0=A0=A0=A0 bdb =3D 0x97bf20 =A0=A0=A0=A0=A0=A0=A0 ei =3D {bei= _parent =3D 0x97bfa0, bei_id =3D 140736167981340, bei_lockpad =3D -20208, b= ei_state =3D -20148, bei_finders =3D 32767, bei_nrdn =3D {bv_len =3D 23, <b= r>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 bv_val =3D 0x1b <Address 0x1b out of= bounds>}, bei_e =3D 0x0, bei_kids =3D 0x0, bei_kids_mutex =3D {__data = =3D {__lock =3D 270, __count =3D 0, __owner =3D 16, __nusers =3D 0, =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 __kind =3D -1320374016, __spins =3D= 32767, __list =3D {__prev =3D 0x7fffb14cb102, __next =3D 0x0}}, =A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 __size =3D "\016\001\000\000\000\000\000\0= 00\020\000\000\000\000\000\000\000\000\261L\261\377\177\000\000\002\261L\26= 1\377\177\000\000\000\000\000\000\000\000\000", =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 __align =3D 270}, bei_lrunext =3D 0x633d6= 46975330000, bei_lruprev =3D 0x69622e657269616c} =A0=A0=A0=A0=A0=A0=A0 e= ip =3D 0x97bfa0 =A0=A0=A0=A0=A0=A0=A0 ei2 =3D 0xa5eda0 =A0=A0=A0=A0= =A0=A0=A0 rc =3D <value optimized out> =A0=A0=A0=A0=A0=A0=A0 ptr = =3D 0x1b <Address 0x1b out of bounds> #3=A0 0x00000000004db460 in bdb_cache_find_id (op=3D0xa652f0, tid=3D<val= ue optimized out>, id=3D<value optimized out>, eip=3D0x7fffb164b5e= 8, flag=3D2, lock=3D0x7fffb164b570) at cache.c:923 =A0=A0=A0=A0=A0=A0=A0= bdb =3D 0x97bf20 =A0=A0=A0=A0=A0=A0=A0 ep =3D 0xb3cd88 =A0=A0=A0=A0=A0=A0=A0 rc =3D <value optimized out> =A0=A0=A0=A0=A0= =A0=A0 load =3D <value optimized out> =A0=A0=A0=A0=A0=A0=A0 ei =3D= {bei_parent =3D 0x0, bei_id =3D 1331, bei_lockpad =3D 0, bei_state =3D 0, = bei_finders =3D 0, bei_nrdn =3D {bv_len =3D 0, bv_val =3D 0x0}, bei_e =3D 0= x0, bei_kids =3D 0x0, bei_kids_mutex =3D { =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 __data =3D {__lock =3D 0, __count =3D 0, = __owner =3D 0, __nusers =3D 0, __kind =3D 0, __spins =3D 0, __list =3D {__p= rev =3D 0x0, __next =3D 0x0}}, __size =3D '\000' <repeats 39 tim= es>, =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 __align =3D 0}, bei_lrunext = =3D 0x0, bei_lruprev =3D 0x0} #4=A0 0x000000000049b274 in bdb_search (op=3D0xa652f0, rs=3D0x7fffb164ca40)= at search.c:737 =A0=A0=A0=A0=A0=A0=A0 scopeok =3D <value optimized o= ut> =A0=A0=A0=A0=A0=A0=A0 bdb =3D 0x97bf20 =A0=A0=A0=A0=A0=A0=A0 i= d =3D <value optimized out> =A0=A0=A0=A0=A0=A0=A0 cursor =3D 1331<= br> =A0=A0=A0=A0=A0=A0=A0 lastid =3D 18446744073709551615 =A0=A0=A0=A0=A0=A0= =A0 candidates =3D {18446744073709551615, 1, 1358, 96, 130, 225, 243, 267, = 305, 325, 402, 420, 430, 464, 494, 518, 585, 606, 683, 762, 774, 854, 904, = 1006, 1010, =A0=A0=A0=A0=A0=A0=A0=A0=A0 0 <repeats 131047 times>}= =A0=A0=A0=A0=A0=A0=A0 scopes =3D {0 <repeats 64885 times>, 112, 0, 14= 0737330949800, 0, 96, 30064771072, 140737330949744, 144, 30064771072, 0, 96= , 140737330949696, 96, 140736169549664, =A0=A0=A0=A0=A0=A0=A0=A0=A0 140= 736169549856, 18678, 140737327905904, 0, 96, 140736169554240, 1407361695540= 64, 140736169549664, 140737328407145, 8589950976, 33022, 485732130981296947= 4, 140736169549712, =A0=A0=A0=A0=A0=A0=A0=A0=A0 0, 0, 4295000064, 0, 72057594037927936, 1407361= 69549760, 0, 140737328406892, 8589940736, 0, 10485842016695418880, 14073616= 9549808, 0, 0, 4294969344, 0, 72058143793676288, =A0=A0=A0=A0=A0=A0=A0= =A0=A0 0, 0, 140737328406892, 562962838323220, 80222775637897, 4294967296, = 65556, 0, 1688935776387072, 18446744073709551615, 2044404433372, 5630358527= 67296, 80222775637897, =A0=A0=A0=A0=A0=A0=A0=A0=A0 12842975242, 141828410114068, 18398981297188896= 768, 1688936890543102, 18446744073709551615, 2065879269857, 0 <repeats 2= 65 times>, 140737346106200, 0, 0, 24, =A0=A0=A0=A0=A0=A0=A0=A0=A0 14= 0737346106200, 140736169552160, 0, 24, 140736169552272, 140736169552192, 0,= 0, 0, 2050, 17, 1, 5909838, 0, 13733440, 17, 5910105, 0 <repeats 33 tim= es>, 5709985, =A0=A0=A0=A0=A0=A0=A0=A0=A0 140736169555760, 140736169560672, 1407361695559= 20, 4603268, 12663952, 4597084, 0 <repeats 19 times>, 5709985, 140736= 169555968, 140736169560672, 140736169556192, 4603268, =A0=A0=A0=A0=A0= =A0=A0=A0=A0 140736169556112, 4597084, 140736169556144, 4603268, 1407361695= 56120, 4597084, 0, 5709985, 140736169556064, 140736169556224, 12663576, 460= 3268, 140736169556232, 4597084, 0, =A0=A0=A0=A0=A0=A0=A0=A0=A0 1, 5949064, 5949064, 0, 0, 0, 0, 14073616955432= 0, 0, 5949054, 0, 140736169554752, 140736169554736, 7, 140736169555104, 140= 736169554752, 140737327689241, 140736169553280, 1, =A0=A0=A0=A0=A0=A0= =A0=A0=A0 6046159, 6046159, 140736169554416, 18446744073709551615, 12664240= , 140736169554280, 140736169554464, 0, 6046156, 0, 140736169554896, 1407361= 69554880, 3, 140736169555248, =A0=A0=A0=A0=A0=A0=A0=A0=A0 140736169554896, 140737327689241, 1407361695534= 24, 2, 5948970, 5948970, 140733193388032, 18446744069414584320, 115, 140736= 169554424, 140736169554608, 0, 5948966, 0, 0, =A0=A0=A0=A0=A0=A0=A0=A0= =A0 140736169554716...} =A0=A0=A0=A0=A0=A0=A0 e =3D 0xb3cd88 =A0=A0=A0=A0=A0=A0=A0 base =3D {e_id =3D 1, e_name =3D {bv_len =3D 14073616= 9554992, bv_val =3D 0xa64a9a ""}, e_nname =3D {bv_len =3D 23, bv_= val =3D 0xd18db0 "ou=3Dpeople,dc=3Dc,dc=3Dfr"}, e_attrs =3D 0x7ff= ff69e2e40, =A0=A0=A0=A0=A0=A0=A0=A0=A0 e_ocflags =3D 0, e_bv =3D {bv_le= n =3D 10898074, bv_val =3D 0xa64aa0 ""}, e_private =3D 0xa659c0}<= br> =A0=A0=A0=A0=A0=A0=A0 e_root =3D <value optimized out> =A0=A0=A0= =A0=A0=A0=A0 matched =3D 0x0 =A0=A0=A0=A0=A0=A0=A0 ei =3D 0x0 =A0=A0= =A0=A0=A0=A0=A0 realbase =3D {bv_len =3D 23, bv_val =3D 0xd18db0 "ou= =3Dpeople,dc=3Dc,dc=3Dfr"} =A0=A0=A0=A0=A0=A0=A0 mask =3D <value= optimized out> =A0=A0=A0=A0=A0=A0=A0 manageDSAit =3D <value optimized out> =A0=A0= =A0=A0=A0=A0=A0 tentries =3D 1358 =A0=A0=A0=A0=A0=A0=A0 nentries =3D &lt= ;value optimized out> =A0=A0=A0=A0=A0=A0=A0 idflag =3D 2 =A0=A0=A0= =A0=A0=A0=A0 lock =3D {off =3D 0, ndx =3D 270, gen =3D 248, mode =3D DB_LOC= K_READ} =A0=A0=A0=A0=A0=A0=A0 opinfo =3D 0x0 =A0=A0=A0=A0=A0=A0=A0 ltid =3D 0xa6= 58b0 =A0=A0=A0=A0=A0=A0=A0 oex =3D <value optimized out> #5=A0 = 0x0000000000489077 in overlay_op_walk (op=3D0xa652f0, rs=3D0x7fffb164ca40, = which=3D<value optimized out>, oi=3D0x9b99a0, on=3D0x0) at backover.c= :671 =A0=A0=A0=A0=A0=A0=A0 rc =3D 32768 #6=A0 0x000000000055f546 in transluce= nt_search (op=3D0xa652f0, rs=3D0x7fffb164ca40) at translucent.c:1122 =A0= =A0=A0=A0=A0=A0=A0 on =3D 0x9b9b80 =A0=A0=A0=A0=A0=A0=A0 ov =3D 0x9b9d60= =A0=A0=A0=A0=A0=A0=A0 cb =3D {sc_next =3D 0x7fffb164b930, sc_response = =3D 0x55f680 <translucent_search_cb>, sc_cleanup =3D 0, sc_private = =3D 0x7fffb164b6c0} =A0=A0=A0=A0=A0=A0=A0 tc =3D {db =3D 0x7fffb164b7a0, on =3D 0x9b9b80, orig = =3D 0xc13ce8, list =3D 0x0, step =3D 1, slimit =3D 500000, attrs =3D 0x0}<b= r>=A0=A0=A0=A0=A0=A0=A0 fl =3D 0xc13da0 =A0=A0=A0=A0=A0=A0=A0 fr =3D 0x0= =A0=A0=A0=A0=A0=A0=A0 rc =3D 0 #7=A0 0x0000000000488f8a in overlay_o= p_walk (op=3D0xa652f0, rs=3D0x7fffb164ca40, which=3D<value optimized out= >, oi=3D0x9b99a0, on=3D0x9b9b80) at backover.c:661 =A0=A0=A0=A0=A0=A0=A0 rc =3D -1318794336 #8=A0 0x0000000000489a57 in ove= r_op_func (op=3D0xa652f0, rs=3D0x1b, which=3D23) at backover.c:723 =A0= =A0=A0=A0=A0=A0=A0 oi =3D 0x48fa =A0=A0=A0=A0=A0=A0=A0 on =3D 0x97bfd8<b= r>=A0=A0=A0=A0=A0=A0=A0 be =3D 0x97bd80 =A0=A0=A0=A0=A0=A0=A0 db =3D {bd= _info =3D 0x844bc0, bd_self =3D 0x97bd80, be_ctrls =3D "\000\000\000\0= 01\001\001\000\001\000\000\001\000\000\001\001\000\001", '\000&#39= ; <repeats 15 times>, "\001", =A0=A0=A0=A0=A0=A0=A0=A0=A0 be_flags =3D 2315, be_restrictops =3D 0, be_req= uires =3D 0, be_ssf_set =3D {sss_ssf =3D 0, sss_transport =3D 0, sss_tls = =3D 0, sss_sasl =3D 0, sss_update_ssf =3D 0, sss_update_transport =3D 0, <b= r>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 sss_update_tls =3D 0, sss_update_sasl = =3D 0, sss_simple_bind =3D 0}, be_suffix =3D 0x97d380, be_nsuffix =3D 0x97d= 4b0, be_schemadn =3D {bv_len =3D 0, bv_val =3D 0x0}, be_schemandn =3D { =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 bv_len =3D 0, bv_val =3D 0x0}, be_rootdn = =3D {bv_len =3D 32, bv_val =3D 0x97d5c0 "cn=3Dadmin,ou=3DPeople,dc=3Dc= ,dc=3Dfr"}, be_rootndn =3D {bv_len =3D 32, =A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 bv_val =3D 0x97d610 "cn=3Dadmin,ou=3Dpeople,dc=3Dc,dc=3Df= r"}, be_rootpw =3D {bv_len =3D 9, bv_val =3D 0x97d460 "password&q= uot;}, be_max_deref_depth =3D 15, be_def_limit =3D { =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 lms_t_soft =3D 3600, lms_t_hard =3D 0, lm= s_s_soft =3D 500000, lms_s_hard =3D 0, lms_s_unchecked =3D -1, lms_s_pr =3D= 0, lms_s_pr_hide =3D 0, lms_s_pr_total =3D 0}, be_limits =3D 0x0, =A0= =A0=A0=A0=A0=A0=A0=A0=A0 be_acl =3D 0x9bc820, be_dfltaccess =3D ACL_READ, b= e_extra_anlist =3D 0x0, be_update_ndn =3D {bv_len =3D 0, bv_val =3D 0x0}, b= e_update_refs =3D 0x0, be_pending_csn_list =3D 0xa5b830, =A0=A0=A0=A0=A0=A0=A0=A0=A0 be_pcl_mutex =3D {__data =3D {__lock =3D 0, __c= ount =3D 0, __owner =3D 0, __nusers =3D 0, __kind =3D 0, __spins =3D 0, __l= ist =3D {__prev =3D 0x0, __next =3D 0x0}}, =A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 __size =3D '\000' <repeats 39 times>, __align =3D 0}, = be_syncinfo =3D 0x0, be_pb =3D 0x0, be_cf_ocs =3D 0x849580, be_private =3D = 0x97bf20, be_next =3D {stqe_next =3D 0x9bd7c0}} =A0=A0=A0=A0=A0=A0=A0 cb =3D {sc_next =3D 0x0, sc_response =3D 0x488d00 &lt= ;over_back_response>, sc_cleanup =3D 0, sc_private =3D 0x9b99a0} =A0= =A0=A0=A0=A0=A0=A0 sc =3D <value optimized out> =A0=A0=A0=A0=A0=A0= =A0 rc =3D 27 =A0=A0=A0=A0=A0=A0=A0 __PRETTY_FUNCTION__ =3D "over_o= p_func" #9=A0 0x0000000000424151 in fe_op_search (op=3D0xa652f0, rs=3D0x7fffb164ca4= 0) at search.c:402 =A0=A0=A0=A0=A0=A0=A0 bd =3D 0x851ca0 #10 0x000000= 000042497c in do_search (op=3D0xa652f0, rs=3D0x7fffb164ca40) at search.c:24= 7 =A0=A0=A0=A0=A0=A0=A0 base =3D {bv_len =3D 23, bv_val =3D 0xd1bef7 &qu= ot;ou=3DPeople,dc=3Dc,dc=3Dfr"} =A0=A0=A0=A0=A0=A0=A0 siz =3D 0 =A0=A0=A0=A0=A0=A0=A0 i =3D 140736169560= 992 #11 0x0000000000421eb9 in connection_operation (ctx=3D0x7fffb164cba0= , arg_v=3D<value optimized out>) at connection.c:1155 =A0=A0=A0=A0= =A0=A0=A0 rc =3D <value optimized out> =A0=A0=A0=A0=A0=A0=A0 cancel =3D <value optimized out> =A0=A0=A0= =A0=A0=A0=A0 op =3D 0xa652f0 =A0=A0=A0=A0=A0=A0=A0 rs =3D {sr_type =3D R= EP_SEARCH, sr_tag =3D 0, sr_msgid =3D 0, sr_err =3D 5, sr_matched =3D 0x0, = sr_text =3D 0x0, sr_ref =3D 0x0, sr_ctrls =3D 0x0, sr_un =3D {sru_search = =3D {r_entry =3D 0x0, =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 r_attr_flags =3D 0, r_operational_a= ttrs =3D 0x0, r_attrs =3D 0x0, r_nentries =3D 4, r_v2ref =3D 0x0}, sru_sasl= =3D {r_sasldata =3D 0x0}, sru_extended =3D {r_rspoid =3D 0x0, =A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 r_rspdata =3D 0x0}}, sr_flags =3D 0} =A0=A0=A0=A0=A0=A0=A0 tag =3D 99 =A0=A0=A0=A0=A0=A0=A0 opidx =3D SLAP_OP= _SEARCH =A0=A0=A0=A0=A0=A0=A0 conn =3D 0x7ffff7f3fed0 =A0=A0=A0=A0=A0= =A0=A0 memctx =3D 0xa64b10 =A0=A0=A0=A0=A0=A0=A0 memctx_null =3D 0x0 = =A0=A0=A0=A0=A0=A0=A0 __PRETTY_FUNCTION__ =3D "connection_operation&qu= ot; #12 0x00000000004226a5 in connection_read_thread (ctx=3D<value op= timized out>, argv=3D<value optimized out>) at connection.c:1291<b= r> =A0=A0=A0=A0=A0=A0=A0 s =3D 17 #13 0x0000000000576780 in ldap_int_thread= _pool_wrapper (xpool=3D<value optimized out>) at tpool.c:688 =A0= =A0=A0=A0=A0=A0=A0 pool =3D 0x9259b0 =A0=A0=A0=A0=A0=A0=A0 task =3D 0xa6= 3430 =A0=A0=A0=A0=A0=A0=A0 work_list =3D <value optimized out> =A0=A0=A0=A0=A0=A0=A0 ctx =3D {ltu_id =3D 140736169563904, ltu_key =3D {{lt= k_key =3D 0x420bb0, ltk_data =3D 0xa65740, ltk_free =3D 0x420c80 <conn_c= ounter_destroy>}, {ltk_key =3D 0x474e80, ltk_data =3D 0xa64b10, =A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ltk_free =3D 0x474ea0 <slap_sl_mem_= destroy>}, {ltk_key =3D 0x435150, ltk_data =3D 0x0, ltk_free =3D 0x434f3= 0 <slap_op_q_destroy>}, {ltk_key =3D 0xa5b850, ltk_data =3D 0xa658b0,= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ltk_free =3D 0x4d9810 <bdb_reade= r_free>}, {ltk_key =3D 0x499860, ltk_data =3D 0x7fffafe4c010, ltk_free = =3D 0x499930 <search_stack_free>}, {ltk_key =3D 0x0, ltk_data =3D 0x0= , =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ltk_free =3D 0} <repeats 2= 4 times>, {ltk_key =3D 0x0, ltk_data =3D 0x7ffff7850927, ltk_free =3D 0}= , {ltk_key =3D 0x0, ltk_data =3D 0x0, ltk_free =3D 0}, {ltk_key =3D 0x0, <b= r> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ltk_data =3D 0x0, ltk_free =3D 0}}}= =A0=A0=A0=A0=A0=A0=A0 kctx =3D <value optimized out> =A0=A0=A0= =A0=A0=A0=A0 keyslot =3D 74 =A0=A0=A0=A0=A0=A0=A0 hash =3D <value opt= imized out> =A0=A0=A0=A0=A0=A0=A0 __PRETTY_FUNCTION__ =3D "ldap_= int_thread_pool_wrapper" #14 0x00007ffff784f8ca in start_thread () from /lib/libpthread.so.0 No s= ymbol table info available. #15 0x00007ffff6754b6d in clone () from /lib= /libc.so.6 No symbol table info available. #16 0x0000000000000000 in = ?? () No symbol table info available. </div>Thank you </div>Ju <= /div> --047d7b86f532b361c704e3e79cfd--

1 0

Re: (ITS#7666) segfault when searching regex minus than 3 characters over translucent
by theju3434＠gmail.com 14 Aug '13

14 Aug '13

--001a11339f3813188a04e3e76889 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable # schema.perso/c.schema attributetype ( 1.3.6.1.4.1.10000.13.2.20 NAME 'Application' DESC 'Acces sur les application' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) objectclass ( 1.3.6.1.4.1.10013.2.2.1.0.0 NAME 'cPerson' SUP 'inetOrgPerson' STRUCTURAL MUST ( uid ) MAY ( Application) ) #slapd.conf 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.perso/c.schema pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args loglevel 2 allow bind_v2 # 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 1 database bdb # The base of your directory in database #1 suffix "ou=3DPeople,dc=3Dc,dc=3Dfr" # rootdn directive for specifying a superuser on the database. This is needed # for syncrepl. rootdn "cn=3Dadmin,ou=3DPeople,dc=3Dc,dc=3Dfr" 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 index objectClass eq,pres index ou,cn,mail,surname,givenname eq,pres,sub index uid eq,pres index Application eq,pres,sub overlay translucent # on demande que les resultats des 2 annuaires soient merg=E9s translucent_no_glue off translucent_strict off #liste des attribut a chercher sur l'overlay translucent_local Application #liste des attributs a chercher sur le master translucent_remote sn,GivenName,mail,street,Postalcode,l,uid,facsimileTelephoneNumber #activation du bind local translucent_bind_local on # activation de la possibilit=E9 de changer le mot de passe translucent_pwmod_local on uri ldap://ldapr.c.fr lastmod off acl-bind binddn=3D"cn=3Dadmin,ou=3DPeople,dc=3Dc,dc=3Dfr" credentials=3D"password" access to attrs=3DuserPassword,shadowLastChange by dn=3D"cn=3Dadmin,ou=3DPeople,dc=3Dc,dc=3Dfr" write by anonymous auth by self write by * none access to dn.base=3D"" by * read Ex user : dn: uid=3Dw.k.1,ou=3Dc,ou=3DPeople,dc=3Dc,dc=3Dfr displayName: K W givenName: W postalCode: 44095 objectClass: cPerson uid: w.k.1 mail: w.k(a)mail.fr cn: K W telephoneNumber: 06 06 06 06 06 o: C l: MON sn: KNAP Application: contrat:ABC221:082534 2013/8/14 Howard Chu <hyc(a)symas.com> > theju3434(a)gmail.com wrote: > >> --047d7b34397049627604e3e73688 >> Content-Type: text/plain; charset=3DISO-8859-1 >> >> >> Here is the stack: >> >> >> gdb slapd >> GNU gdb (GDB) 7.0.1-debian >> Copyright (C) 2009 Free Software Foundation, Inc. >> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.= * >> *html <http://gnu.org/licenses/gpl.html> >> >>> >>> This is free software: you are free to change and redistribute it. >> There is NO WARRANTY, to the extent permitted by law. Type "show copyin= g" >> and "show warranty" for details. >> This GDB was configured as "x86_64-linux-gnu". >> For bug reporting instructions, please see: >> <http://www.gnu.org/software/**gdb/bugs/<http://www.gnu.org/software/gdb= /bugs/> >> >... >> Reading symbols from /usr/sbin/slapd...(no debugging symbols >> found)...done. >> > > This trace is useless since it doesn't have any symbols. Please reread th= e > FAQ article in my previous reply. > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/**project/<http://ww= w.openldap.org/project/> > --001a11339f3813188a04e3e76889 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"># schema.perso/c.schema attributetype ( 1.3.6.1.4.1= .10000.13.2.20 =A0=A0=A0=A0=A0=A0=A0 NAME 'Application' =A0= =A0=A0=A0=A0=A0=A0 DESC 'Acces sur les application' =A0=A0=A0=A0= =A0=A0=A0 EQUALITY caseIgnoreMatch =A0=A0=A0=A0=A0=A0=A0 SUBSTR caseIgno= reSubstringsMatch =A0=A0=A0=A0=A0=A0=A0 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) objectc= lass (=A0 1.3.6.1.4.1.10013.2.2.1.0.0 =A0=A0=A0=A0=A0=A0=A0 NAME 'cP= erson' =A0=A0=A0=A0=A0=A0=A0 SUP 'inetOrgPerson' =A0=A0= =A0=A0=A0=A0=A0 STRUCTURAL =A0=A0=A0=A0=A0=A0=A0 MUST (=A0 uid ) =A0= =A0=A0=A0=A0=A0=A0 MAY ( Application) ) #slapd.conf include=A0=A0=A0=A0=A0=A0=A0=A0 /etc/openlda= p/schema/core.schema include=A0=A0=A0=A0=A0=A0=A0=A0 /etc/openldap/schem= a/cosine.schema include=A0=A0=A0=A0=A0=A0=A0=A0 /etc/openldap/schema/nis= .schema include=A0=A0=A0=A0=A0=A0=A0=A0 /etc/openldap/schema/inetorgpers= on.schema include=A0=A0=A0=A0=A0=A0=A0=A0 /etc/openldap/schema.perso/c.schema = pidfile=A0=A0=A0=A0=A0=A0=A0=A0 /var/run/slapd/slapd.pid argsfile=A0=A0= =A0=A0=A0=A0=A0 /var/run/slapd/slapd.args loglevel=A0=A0=A0=A0=A0 2 <= br>allow bind_v2 # The maximum number of entries that is returned fo= r a search operation sizelimit=A0=A0=A0=A0=A0=A0 500000 # The tool-threads parameter sets= the actual amount of cpu's that is used # for indexing. tool-thr= eads=A0=A0=A0 1 database=A0=A0=A0=A0=A0=A0=A0 bdb # The b= ase of your directory in database #1 suffix=A0=A0=A0=A0=A0=A0=A0=A0=A0 "ou=3DPeople,dc=3Dc,dc=3Dfr"<br= > # rootdn directive for specifying a superuser on the database. This is= needed # for syncrepl. rootdn=A0=A0=A0=A0=A0=A0=A0=A0=A0 "cn=3D= admin,ou=3DPeople,dc=3Dc,dc=3Dfr" rootpw=A0=A0=A0=A0=A0=A0=A0=A0=A0= "password" # Where the database file are physically stored for database #1 = directory=A0=A0=A0=A0=A0=A0 "/var/lib/ldap-people" dbconfi= g set_cachesize 0 536870912 0 dbconfig set_flags=A0=A0=A0 DB_LOG_AUTOREM= OVE dbconfig set_lk_max_objects 1500 dbconfig set_lk_max_locks 1500 dbconfig set_lk_max_lockers 1500 <= br>index objectClass=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 eq,pres index ou,cn,mail,surname,givenname=A0=A0=A0=A0=A0 e= q,pres,sub index uid=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 eq,pres index Application=A0=A0=A0 =A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 eq,pres,sub <= br> overlay=A0=A0=A0=A0=A0=A0=A0=A0 translucent # on demande que = les resultats des 2 annuaires soient merg=E9s translucent_no_glue off<br= >translucent_strict off #liste des attribut a chercher sur l'ove= rlay translucent_local Application #liste des attributs a chercher sur le mas= ter translucent_remote sn,GivenName,mail,street,Postalcode,l,uid,facsimi= leTelephoneNumber #activation du bind local translucent_bind_loca= l on # activation de la possibilit=E9 de changer le mot de passe transluc= ent_pwmod_local on uri=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ldap://<a= href=3D"http://ldapr.c.fr">ldapr.c.fr</a> lastmod=A0=A0=A0=A0=A0=A0=A0= =A0 off acl-bind=A0=A0=A0=A0=A0=A0=A0 binddn=3D"cn=3Dadmin,ou=3DPeo= ple,dc=3Dc,dc=3Dfr" credentials=3D"password" access to attrs=3DuserPassword,shadowLastChange =A0=A0=A0=A0=A0=A0= =A0 by dn=3D"cn=3Dadmin,ou=3DPeople,dc=3Dc,dc=3Dfr" write =A0= =A0=A0=A0=A0=A0=A0 by anonymous auth =A0=A0=A0=A0=A0=A0=A0 by self write= =A0=A0=A0=A0=A0=A0=A0 by * none access to dn.base=3D""= =A0=A0=A0=A0=A0=A0=A0 by * read Ex user : dn: uid=3Dw.k.= 1,ou=3Dc,ou=3DPeople,dc=3Dc,dc=3Dfr displayName: K W givenName: W = postalCode: 44095 objectClass: cPerson uid: w.k.1 mail: <a href=3D= "mailto:w.k@mail.fr">w.k(a)mail.fr</a> cn: K W telephoneNumber: 06 06 06 06 06 o: C l: MON sn: KNAP<br= >Application: contrat:ABC221:082534 </div><div class=3D"gmail_extra"><br= > <div class=3D"gmail_quote">2013/8/14 Howard Chu <= <a href=3D"mailto:hyc@symas.com" target=3D"_blank">hyc(a)symas.com</a>></s= pan> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><a href=3D"mailto:theju3434@gmail.com" targe= t=3D"_blank">theju3434(a)gmail.com</a> wrote: <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> --047d7b34397049627604e3e73688 Content-Type: text/plain; charset=3DISO-8859-1<div class=3D"im"> Here is the stack: gdb slapd GNU gdb (GDB) 7.0.1-debian Copyright (C) 2009 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <<a href=3D"http://gnu.org/li= censes/gpl.html" target=3D"_blank">http://gnu.org/licenses/gpl.html<= /a> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> </blockquote> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. =A0Type "show co= pying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". For bug reporting instructions, please see: <<a href=3D"http://www.gnu.org/software/gdb/bugs/" target=3D"_blank">htt= p://www.gnu.org/software/gdb/bugs/</a>>... Reading symbols from /usr/sbin/slapd...(no debugging symbols found)...done.= </div></blockquote> This trace is useless since it doesn't have any symbols. Please reread = the FAQ article in my previous reply. -- =A0 -- Howard Chu =A0 CTO, Symas Corp. =A0 =A0 =A0 =A0 =A0 <a href=3D"http://www.symas.com" t= arget=3D"_blank">http://www.symas.com</a> =A0 Director, Highland Sun =A0 =A0 <a href=3D"http://highlandsun.com/hyc/" = target=3D"_blank">http://highlandsun.com/hyc/</a> =A0 Chief Architect, OpenLDAP =A0<a href=3D"http://www.openldap.org/project= /" target=3D"_blank">http://www.openldap.org/project/</a> </blockquote></div> </div> --001a11339f3813188a04e3e76889--

1 0

Re: (ITS#7666) segfault when searching regex minus than 3 characters over translucent
by hyc＠symas.com 14 Aug '13

14 Aug '13

theju3434(a)gmail.com wrote: > --047d7b34397049627604e3e73688 > Content-Type: text/plain; charset=ISO-8859-1 > > Here is the stack: > > > gdb slapd > GNU gdb (GDB) 7.0.1-debian > Copyright (C) 2009 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html >> > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show copying" > and "show warranty" for details. > This GDB was configured as "x86_64-linux-gnu". > For bug reporting instructions, please see: > <http://www.gnu.org/software/gdb/bugs/>... > Reading symbols from /usr/sbin/slapd...(no debugging symbols found)...done. This trace is useless since it doesn't have any symbols. Please reread the FAQ article in my previous reply. -- -- 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#7666) segfault when searching regex minus than 3 characters over translucent
by theju3434＠gmail.com 14 Aug '13

14 Aug '13

--047d7b34397049627604e3e73688 Content-Type: text/plain; charset=ISO-8859-1 Here is the stack: gdb slapd GNU gdb (GDB) 7.0.1-debian Copyright (C) 2009 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html > This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /usr/sbin/slapd...(no debugging symbols found)...done. (gdb) run -d0 Starting program: /usr/sbin/slapd -d0 [Thread debugging using libthread_db enabled] [New Thread 0x7fffb1e4e700 (LWP 18590)] [New Thread 0x7fffb164d700 (LWP 18592)] --->>> search ldap here Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffb164d700 (LWP 18592)] 0x00007ffff678d0bc in ?? () from /lib/libc.so.6 (gdb) bt full #0 0x00007ffff678d0bc in ?? () from /lib/libc.so.6 No symbol table info available. #1 0x00000000005720a1 in ?? () No symbol table info available. #2 0x00000000004dae90 in ?? () No symbol table info available. #3 0x00000000004db460 in ?? () No symbol table info available. #4 0x000000000049b274 in ?? () No symbol table info available. #5 0x0000000000489077 in ?? () No symbol table info available. #6 0x000000000055f546 in ?? () No symbol table info available. #7 0x0000000000488f8a in ?? () No symbol table info available. #8 0x0000000000489a57 in ?? () No symbol table info available. #9 0x0000000000424151 in ?? () No symbol table info available. #10 0x000000000042497c in ?? () No symbol table info available. #11 0x0000000000421eb9 in ?? () No symbol table info available. #12 0x00000000004226a5 in ?? () No symbol table info available. #13 0x0000000000576780 in ?? () No symbol table info available. #14 0x00007ffff784f8ca in start_thread () from /lib/libpthread.so.0 No symbol table info available. #15 0x00007ffff6754b6d in clone () from /lib/libc.so.6 No symbol table info available. #16 0x0000000000000000 in ?? () No symbol table info available. (gdb) (gdb) thread apply all bt Thread 3 (Thread 0x7fffb164d700 (LWP 18592)): #0 0x00007ffff678d0bc in ?? () from /lib/libc.so.6 #1 0x00000000005720a1 in ?? () #2 0x00000000004dae90 in ?? () #3 0x00000000004db460 in ?? () #4 0x000000000049b274 in ?? () #5 0x0000000000489077 in ?? () #6 0x000000000055f546 in ?? () #7 0x0000000000488f8a in ?? () #8 0x0000000000489a57 in ?? () #9 0x0000000000424151 in ?? () #10 0x000000000042497c in ?? () #11 0x0000000000421eb9 in ?? () #12 0x00000000004226a5 in ?? () #13 0x0000000000576780 in ?? () #14 0x00007ffff784f8ca in start_thread () from /lib/libpthread.so.0 #15 0x00007ffff6754b6d in clone () from /lib/libc.so.6 #16 0x0000000000000000 in ?? () Thread 2 (Thread 0x7fffb1e4e700 (LWP 18590)): #0 0x00007ffff6755163 in epoll_wait () from /lib/libc.so.6 #1 0x000000000041f1ea in ?? () #2 0x00007ffff784f8ca in start_thread () from /lib/libpthread.so.0 #3 0x00007ffff6754b6d in clone () from /lib/libc.so.6 #4 0x0000000000000000 in ?? () Thread 1 (Thread 0x7ffff7fef700 (LWP 18587)): #0 0x00007ffff7850c75 in pthread_join () from /lib/libpthread.so.0 #1 0x000000000041c5d9 in ?? () #2 0x0000000000408d6b in ?? () #3 0x00007ffff66a3c8d in __libc_start_main () from /lib/libc.so.6 #4 0x00000000004075f9 in ?? () #5 0x00007fffffffe8b8 in ?? () #6 0x000000000000001c in ?? () #7 0x0000000000000002 in ?? () #8 0x00007fffffffeb01 in ?? () #9 0x00007fffffffeb11 in ?? () #10 0x0000000000000000 in ?? () --047d7b34397049627604e3e73688 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Here is the stack: gdb slapd=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 GNU gdb (GDB) 7.0.1-debian Copyright (C) 2009 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <<a href=3D"http://gnu.org/li= censes/gpl.html">http://gnu.org/licenses/gpl.html</a>> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law.=A0 Type "show co= pying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". For bug reporting instructions, please see: <<a href=3D"http://www.gnu.org/software/gdb/bugs/">http://www.gnu.org/so= ftware/gdb/bugs/</a>>... Reading symbols from /usr/sbin/slapd...(no debugging symbols found)...done.= (gdb) run -d0 Starting program: /usr/sbin/slapd -d0 [Thread debugging using libthread_db enabled] [New Thread 0x7fffb1e4e700 (LWP 18590)] [New Thread 0x7fffb164d700 (LWP 18592)] --->>> search ldap here Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffb164d700 (LWP 18592)] 0x00007ffff678d0bc in ?? () from /lib/libc.so.6 (gdb) bt full #0=A0 0x00007ffff678d0bc in ?? () from /lib/libc.so.6 No symbol table info available. #1=A0 0x00000000005720a1 in ?? () No symbol table info available. #2=A0 0x00000000004dae90 in ?? () No symbol table info available. #3=A0 0x00000000004db460 in ?? () No symbol table info available. #4=A0 0x000000000049b274 in ?? () No symbol table info available. #5=A0 0x0000000000489077 in ?? () No symbol table info available. #6=A0 0x000000000055f546 in ?? () No symbol table info available. #7=A0 0x0000000000488f8a in ?? () No symbol table info available. #8=A0 0x0000000000489a57 in ?? () No symbol table info available. #9=A0 0x0000000000424151 in ?? () No symbol table info available. #10 0x000000000042497c in ?? () No symbol table info available. #11 0x0000000000421eb9 in ?? () No symbol table info available. #12 0x00000000004226a5 in ?? () No symbol table info available. #13 0x0000000000576780 in ?? () No symbol table info available. #14 0x00007ffff784f8ca in start_thread () from /lib/libpthread.so.0 No symbol table info available. #15 0x00007ffff6754b6d in clone () from /lib/libc.so.6 No symbol table info available. #16 0x0000000000000000 in ?? () No symbol table info available. (gdb) (gdb) thread apply all bt Thread 3 (Thread 0x7fffb164d700 (LWP 18592)): #0=A0 0x00007ffff678d0bc in ?? () from /lib/libc.so.6 #1=A0 0x00000000005720a1 in ?? () #2=A0 0x00000000004dae90 in ?? () #3=A0 0x00000000004db460 in ?? () #4=A0 0x000000000049b274 in ?? () #5=A0 0x0000000000489077 in ?? () #6=A0 0x000000000055f546 in ?? () #7=A0 0x0000000000488f8a in ?? () #8=A0 0x0000000000489a57 in ?? () #9=A0 0x0000000000424151 in ?? () #10 0x000000000042497c in ?? () #11 0x0000000000421eb9 in ?? () #12 0x00000000004226a5 in ?? () #13 0x0000000000576780 in ?? () #14 0x00007ffff784f8ca in start_thread () from /lib/libpthread.so.0 #15 0x00007ffff6754b6d in clone () from /lib/libc.so.6 #16 0x0000000000000000 in ?? () Thread 2 (Thread 0x7fffb1e4e700 (LWP 18590)): #0=A0 0x00007ffff6755163 in epoll_wait () from /lib/libc.so.6 #1=A0 0x000000000041f1ea in ?? () #2=A0 0x00007ffff784f8ca in start_thread () from /lib/libpthread.so.0 #3=A0 0x00007ffff6754b6d in clone () from /lib/libc.so.6 #4=A0 0x0000000000000000 in ?? () Thread 1 (Thread 0x7ffff7fef700 (LWP 18587)): #0=A0 0x00007ffff7850c75 in pthread_join () from /lib/libpthread.so.0 #1=A0 0x000000000041c5d9 in ?? () #2=A0 0x0000000000408d6b in ?? () #3=A0 0x00007ffff66a3c8d in __libc_start_main () from /lib/libc.so.6 #4=A0 0x00000000004075f9 in ?? () #5=A0 0x00007fffffffe8b8 in ?? () #6=A0 0x000000000000001c in ?? () #7=A0 0x0000000000000002 in ?? () #8=A0 0x00007fffffffeb01 in ?? () #9=A0 0x00007fffffffeb11 in ?? () #10 0x0000000000000000 in ?? () </div> --047d7b34397049627604e3e73688--

1 0

Re: (ITS#7666) segfault when searching regex minus than 3 characters over translucent
by hyc＠symas.com 14 Aug '13

14 Aug '13

theju(a)yopmail.com wrote: > Full_Name: Ju > Version: openldap-2.4.35 > OS: debian 6.0.7 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (193.49.133.163) > > > Server crash with a segfault error 4 in libc-2.11.3.so when searching with > expression like "(attr=*123*)" over translucent (minus than 3 characteres) Please provide the full stack trace from the crash. http://www.openldap.org/faq/data/cache/59.html I see no crash here, please provide a more complete slapd.conf and sample LDIF to reproduce the crash. > I have custom attributes providen by translucent : > > slapd.conf : > [...] > index Application eq,pres,sub > > overlay translucent > translucent_no_glue off > translucent_strict off > translucent_local Application > > [..] > > Schema : > > attributetype ( 1.3.6.1.4.1.10000.13.2.20 > NAME 'Application' > DESC 'Acces sur les application' > EQUALITY caseIgnoreMatch > SUBSTR caseIgnoreSubstringsMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) > > > ex : > ldapserch "(application=*1234*) -> OK > ldapserch "(application=*123*) -> Segfault > ldapserch "(application=*12*) -> Segfault > ldapserch "(application=*1*) -> Segfault > > > I'm I commited a misake or is there really a bug ? > > Thank you > Ju > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#7666) segfault when searching regex minus than 3 characters over translucent
by theju＠yopmail.com 14 Aug '13

14 Aug '13

Full_Name: Ju Version: openldap-2.4.35 OS: debian 6.0.7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.49.133.163) Server crash with a segfault error 4 in libc-2.11.3.so when searching with expression like "(attr=*123*)" over translucent (minus than 3 characteres) I have custom attributes providen by translucent : slapd.conf : [...] index Application eq,pres,sub overlay translucent translucent_no_glue off translucent_strict off translucent_local Application [..] Schema : attributetype ( 1.3.6.1.4.1.10000.13.2.20 NAME 'Application' DESC 'Acces sur les application' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) ex : ldapserch "(application=*1234*) -> OK ldapserch "(application=*123*) -> Segfault ldapserch "(application=*12*) -> Segfault ldapserch "(application=*1*) -> Segfault I'm I commited a misake or is there really a bug ? Thank you Ju

1 0

Re: (ITS#7665) LMDB: Documentation issue or mistake: MDB_NOMETASYNC vs MDB_CREATE
by sog＠msg.com.mx 14 Aug '13

14 Aug '13

Hi Hallvard, I want to thank you so much for your timely responses. I'm very glad to interact with a so responsible team. Changing MDB_CREATE is clearer, indeed allows separate both sets with a simple mask. Talking about the documentation, I think that should be stressed somewhere that when using named databases, the main one (unnamed) should not be used for regular work without special care and some constraints. Maybe that a remark in mdb_dbi_open would be sufficient. Regards and thanks again. Salvador. On 08/14/2013 02:06 AM, Hallvard B Furuseth wrote: > The code is OK, it would be sufficient to change > "Values do not overlap Database Flags." > to "stored Database Flags" or something, and to > note under MDB_CREATE that is not stored. > > Might be clearer to change MDB_CREATE in addition.

1 0

(ITS#7665) LMDB: Documentation issue or mistake: MDB_NOMETASYNC vs MDB_CREATE
by sog＠msg.com.mx 13 Aug '13

13 Aug '13

Full_Name: Salvador Ortiz Version: OS: URL: Submission from: (NULL) (187.162.45.111) The documentation states that the Environment's flags should not overlap with the Database's ones, but MDB_NOMETASYNC and MDB_CREATE share the same value. There is unused bits in the low word. We are still at time to change MDB_CREATE?

1 0

Re: (ITS#7664) LMDB: Opening a non existing environment with MDB_RDONLY leaves a stale lock file
by hyc＠symas.com 13 Aug '13

13 Aug '13

sog(a)msg.com.mx wrote: > Full_Name: Salvador Ortiz > Version: 24 > OS: Linux > URL: > Submission from: (NULL) (187.162.45.111) > > > Trying to open a non existent environment using MDB_RDONLY, fails with ENOENT as > expected, but the lock file is created and is preserved, an issue of pollution > IMHO. > > The problem lies in the unconditional use of O_CREATE in mdb_env_setup_locks. > I'm not sure what is the best solution. > > Fixed now in mdb.master, thanks for the report. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#7664) LMDB: Opening a non existing environment with MDB_RDONLY leaves a stale lock file
by sog＠msg.com.mx 13 Aug '13

13 Aug '13

Full_Name: Salvador Ortiz Version: 24 OS: Linux URL: Submission from: (NULL) (187.162.45.111) Trying to open a non existent environment using MDB_RDONLY, fails with ENOENT as expected, but the lock file is created and is preserved, an issue of pollution IMHO. The problem lies in the unconditional use of O_CREATE in mdb_env_setup_locks. I'm not sure what is the best solution.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs