- openldap-bugs - openldap.org

Re: (ITS#7198) slapd coredumps when Master server unavailable
by michael＠stroeder.com 05 Mar '12

05 Mar '12

This is a cryptographically signed message in MIME format. --------------ms080906060103080409010309 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable andre.cardinal(a)bell.ca wrote: > Full_Name: Andre Cardinal > Version: 2.4.24 > OS: Oracle (Solaris) 10 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (206.47.249.246) > > > Our Openldap Master server crashed with a hardware memory error and the= > slave/replica, which is read only, coredumped 2 hours later, and would= coredump > 4 minutes after restarting slapd thereafter. Can you check whether that also happens with recent release 2.4.30? If ye= s, it=20 would be helpful if you install OpenLDAP with debug symbols and grab a st= ack=20 trace etc. See "What information should I provide when reporting an issue (bug)?": http://www.openldap.org/faq/data/cache/59.html Ciao, Michael. --------------ms080906060103080409010309 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFOzCC BTcwggMfoAMCAQICAwl4kDANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDEx MTcxNTQzMzFaFw0xMjExMTYxNTQzMzFaMD8xGDAWBgNVBAMUD01pY2hhZWwgU3Ry9mRlcjEj MCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDo2SKth5GhtaDrCyfGtyUG+/hAAa/J52L0NFN4SSRvTtdGf9HfWwwd NCtgae0TVGWk2lKDbXA9d5vmyIiRhuwxd90H6FLErhRBeB9G67qtw87E8WUoXt2DwPQEUTWV hqHpPadlmgFw3+i3TGQQTe3O3W9MMMd4GJNhObem2VGRuCD37OXnzBksTcq0FPJgcWAhe3d/ 0ItOkNWBqgq8Mf3p7WFBhaQ0a27BC/mKtH8fI3kPcS305imPRja69Msq3EwUZBc9ToVp6FRQ NYKjfOBybDUzVkmRZl3H8xutQP2w8Zxb8m5f7Q1BfLLrIFScfYvIDgOERxTCd4lab8+/09XH AgMBAAGjggEAMIH9MAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3Vy IG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNl cnQub3JnMEAGA1UdJQQ5MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYKKwYB BAGCNwoDAwYJYIZIAYb4QgQBMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDov L29jc3AuY2FjZXJ0Lm9yZzAfBgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTANBgkq hkiG9w0BAQUFAAOCAgEANPf/aLF41eQlvN5dEg3CFnlN//qQK7+EPIXLnHprNWLb4nBwgdPj /E+qa1umT7px4Py3VS0UTKqLmMdWftwid8MOMHWalZwrfx0Z8U3He+EdJhOSnn9vdd/ug7Xd dI/hRjLaBSq9ZhCczEUgL6vTxCYPlIoHF56y/oxSJw59vRBjvRFKXvpBZWseeRkcGACQduNH SNdWC1IqHAbQlgOS9VWQUYlm//BdaLkezRxqnQp5+KJMAcZzHpdNJ3G4SqCJ02Z3n4kk8IKZ AjgiWxisDFNsfXKDb9Ng5ntnnH2ouxrgPoNnW445tgkz50VKHstylx9s5O3G7uUTtg0J+z63 TA8xbN6kzRx7RgAUkEXhl6WEdW+3EVj5tYY38Uy8vleP+gYZfphKEmQJgIQqy9D2+gesbolT QdWYgbUYY2AHJOshskMW7pahYnFX2pZmn/ayaPc+JFJlCEqO0+DcYQjYuv6sntQgZGkok7yZ R4xMbyCp61pTrfGWOufZs/FiScJZg1IWY5qb4URH4VZZjLNMR2pFMRuE4LvgkkMRasbUv7Yv n3Lzv34lTfJKUqYW6nx//L2NS4rN63o0taPwRygnuBK4kp7EYEcwtLeanJhQoIu4b6If9rwy D7CFAp51wIewV9VtZ1Is0irNBcMVyhJogIcuIn+VWY1ff1RxySD/djMxggOUMIIDkAIBATCB gDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcx IjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1 cHBvcnRAY2FjZXJ0Lm9yZwIDCXiQMAkGBSsOAwIaBQCgggHoMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDMwNTE1MTYxNFowIwYJKoZIhvcNAQkEMRYE FKAKYri2D9e4IJCdixF14t7Nk/MyMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoG CCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggq hkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGDMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAc BgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5n IEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwgZMG CyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6 Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEh MB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwDQYJKoZIhvcNAQEBBQAE ggEAoUCDo8hQNS6bro13hDJb4XbtSNMWvrlHx6haTIwDJbarSKJlBo8TVnax1cCdgC6SByGB 6wIejSS1yfC0Lh+yg+kQebnXY975kCMKjvUcDdjAIuEfYT6NCa1MxWzakprkkIH2YPDyILNx Tc5wqNn/EZX/2aMLrMlvvaGiN3nlqp0IgRzpMTMibOD/oX2oIm4vd5cJqCNBc9N0LTbHhoAK VoD/knw3ELQnQ+Kmi7Q6cJDVQRrIeUK6UqIP1edIMKT/UsYXucZziE8SzGmoTmv+EQwnefEx Y/FVgQ2ETRu3e5iwIYOMZorSTjUsw++yIuIDXz/mT7BA+ZHX+1w7tsyLxQAAAAAAAA== --------------ms080906060103080409010309--

1 0

(ITS#7198) slapd coredumps when Master server unavailable
by andre.cardinal＠bell.ca 05 Mar '12

05 Mar '12

Full_Name: Andre Cardinal Version: 2.4.24 OS: Oracle (Solaris) 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (206.47.249.246) Our Openldap Master server crashed with a hardware memory error and the slave/replica, which is read only, coredumped 2 hours later, and would coredump 4 minutes after restarting slapd thereafter. Disabling syncrepl stopped the coredumps. (i.e. commenting out all the lines in the syncrepl portion of slapd.conf in the replica. See following. Text in <> is sanitized for obvious reasons. # # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # include /usr/local/etc/openldap/schema/core.schema include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/inetorgperson.schema include /usr/local/etc/openldap/schema/misc.schema include /usr/local/etc/openldap/schema/ces.schema # Define global ACLs to disable default read access. # Do not enable referrals until AFTER you have a working directory # service AND an understanding of referrals. #referral ldap://root.openldap.org pidfile /usr/local/var/openldap-run/slapd.pid argsfile /usr/local/var/openldap-run/slapd.args # Load dynamic backend modules: # modulepath /usr/local/libexec/openldap # moduleload back_bdb.la # moduleload back_hdb.la # moduleload back_ldap.la allow bind_v2 loglevel 256 #loglevel 4095 #logfile /var/log/ldap.log # The next three lines allow use of TLS for encrypting connections using a # test certificate #TLSCACertificateFile /usr/local/etc/openldap/certs/test_with_ca.pem #TLSCertificateFile /usr/local/etc/openldap/certs/test_with_ca.pem #TLSCertificateKeyFile /usr/local/etc/openldap/certs/test_with_ca.pem #ICM Certs for PROD TLSCACertificateFile /usr/local/etc/openldap/certs/Slave-ICM.pem TLSCertificateFile /usr/local/etc/openldap/certs/Slave-ICM.pem TLSCertificateKeyFile /usr/local/etc/openldap/certs/Slave-ICM.pem # Sample security restrictions # Require integrity protection (prevent hijacking) # Require 112-bit (3DES or better) encryption for updates # Require 63-bit encryption for simple bind # security ssf=1 update_ssf=112 simple_bind=64 # Sample access control policy: # Root DSE: allow anyone to read it # Subschema (sub)entry DSE: allow anyone to read it # Other DSEs: # Allow self write access # Allow authenticated users read access # Allow anonymous users to authenticate # Directives needed to implement policy: # access to dn.base="" by * read # access to dn.base="cn=Subschema" by * read # access to * # by self write # by users read # by anonymous auth # # if no access controls are present, the default policy # allows anyone and everyone to read anything but restricts # updates to rootdn. (e.g., "access to * by * read") # # rootdn can always read and write EVERYTHING! #configure timelimits and sizelimits sizelimit unlimited timelimit unlimited ####################################################################### # BDB database definitions ####################################################################### database bdb suffix "<suffix>" rootdn "<Root DN>" # Cleartext passwords, especially for the rootdn, should # be avoid. See slappasswd(8) and slapd.conf(5) for details. # Use of strong authentication encouraged. rootpw {SSHA}<encrypted password> # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory /usr/local/var/openldap-data #directory /data/openldap # Indices to maintain index objectClass eq index cesSubjectDN eq,pres index cn eq # #Equality Indexing for Replication # index entryCSN,entryUUID eq syncrepl rid=123 provider=ldap://<Master Server> type=refreshAndPersist interval=00:00:00:10 retry="30 +" searchbase="<suffix>" filter="(objectClass=*)" scope=sub attrs="*" schemachecking=off bindmethod=simple binddn="cn=<bindDN>" credentials=<password>

1 0

(ITS#7197) olcTLSVerifyClient missing options
by quanah＠OpenLDAP.org 04 Mar '12

04 Mar '12

Full_Name: Quanah Gibson-Mount Version: 2.4.30 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.108.184.39) >From the manual page: olcTLSVerifyClient: <level> Specifies what checks to perform on client certificates in an incoming TLS session, if any. The <level> can be specified as one of the following keywords: never This is the default. slapd will not ask the client for a certificate. allow The client certificate is requested. If no certificate is provided, the session proceeds normally. If a bad certificate is provided, it will be ignored and the ses- sion proceeds normally. try The client certificate is requested. If no certificate is provided, the session proceeds normally. If a bad certificate is provided, the session is immediately ter- minated. demand | hard | true These keywords are all equivalent, for compatibility rea- sons. The client certificate is requested. If no cer- tificate is provided, or a bad certificate is provided, the session is immediately terminated. Note that a valid client certificate is required in order to use the SASL EXTERNAL authentication mechanism with a TLS session. As such, a non-default olcTLSVerifyClient setting must be chosen to enable SASL EXTERNAL authenti- cation. However, the code has: static slap_verbmasks vfykeys[] = { { BER_BVC("never"), LDAP_OPT_X_TLS_NEVER }, { BER_BVC("demand"), LDAP_OPT_X_TLS_DEMAND }, { BER_BVC("try"), LDAP_OPT_X_TLS_TRY }, { BER_BVC("hard"), LDAP_OPT_X_TLS_HARD }, { BER_BVNULL, 0 } }; Which means: a) allow is missing b) true is missing c) demand and hard set different flags. Not sure if that means any difference functionality wise, but according to the manual page, demand/true/hard are supposed to be the same behavior.

1 0

(ITS#7196) libmdb: MDB_COMMIT_PAGES greater than IOV_MAX causes mdb_txn_commit failures
by roy.keene＠us.army.mil 03 Mar '12

03 Mar '12

Full_Name: Roy Keene Version: 2.4.30 OS: Solaris 10 URL: Submission from: (NULL) (140.194.193.14) libmdb uses writev() to write data to a file descriptor, however it can request that writev() write more blocks than IOV_MAX causing mdb txn errors to be reported to the LDAP client. MDB_COMMIT_PAGES should not be defined to be greater than IOV_MAX. IOV_MAX on Solaris 10 is 16.

1 0

Re: (ITS#7195) delta-syncrepl fails to fallback on some errors
by hyc＠symas.com 02 Mar '12

02 Mar '12

ebackes(a)symas.com wrote: > Full_Name: Emily Backes > Version: 2.4 > OS: any > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (98.155.30.248) > > > The delta-syncrepl code checks an explicit list of failure codes for cases that > merit falling back to syncrepl to regain syncronization. This list is missing a > few; in particular, rc=66 (Not a leaf!) slips through and creates a retry loop. Thanks, fixed in git 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

(ITS#7195) delta-syncrepl fails to fallback on some errors
by ebackes＠symas.com 02 Mar '12

02 Mar '12

Full_Name: Emily Backes Version: 2.4 OS: any URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (98.155.30.248) The delta-syncrepl code checks an explicit list of failure codes for cases that merit falling back to syncrepl to regain syncronization. This list is missing a few; in particular, rc=66 (Not a leaf!) slips through and creates a retry loop.

1 0

Re: (ITS#7191) libmdb: Alignment of MDB_db members
by roy.s.keene＠usace.army.mil 02 Mar '12

02 Mar '12

Hallvard, This also works. My naive approach was due to working out what the issue was with the original assigment and then trying to determine which members were not aligned correctly. Thanks, Roy Keene On Fri, 2 Mar 2012, Hallvard B Furuseth wrote: > On Fri, 2 Mar 2012 08:03:00 GMT, roy.keene(a)us.army.mil wrote: >> Breaking the assignment into an assignment of its members and using >> the existing COPY_PGNO() alleviates this fault. > > memcpy would be simpler, if it is 'db' which is unaligned. > Try this instead. > > --- mdb.c~ 2012-03-02 11:23:21 > +++ mdb.c 2012-03-02 11:25:06 > @@ -4699,4 +4699,3 @@ mdb_xcursor_init1(MDB_cursor *mc, MDB_no > if (node->mn_flags & F_SUBDATA) { > - MDB_db *db = NODEDATA(node); > - mx->mx_db = *db; > + memcpy(&mx->mx_db, NODEDATA(node), sizeof(MDB_db)); > mx->mx_cursor.mc_snum = 0; > > -- (U) Roy Keene (U) US Army Corps of Engineers IT (ACE-IT) (U) Contractor

1 0

(ITS#7193)
by barlone＠yandex.ru 02 Mar '12

02 Mar '12

Good day! I found problem: function under macro BACKSQL_STR2ID incorrectly work with 'zerofilled' values/fields (for example "000009") ------------------------------------------ Best regards, mailto:barlone@yandex.ru

1 0

(ITS#7193)
by barlone＠yandex.ru 02 Mar '12

02 Mar '12

Good day! I found some hint: if define BACKSQL_ARBITRARY_KEY in back-sql.h, then all records presents in search result, BUT LDAP entry do not contain any attribute! Just empty. Maybe it is another bug? ------------------------------------------ Best regards, mailto:barlone@yandex.ru

1 0

(ITS#7194) tlso_session_chkhost issue for OpenSSL TLS
by dimosthenis.pettas＠nsn.com 02 Mar '12

02 Mar '12

Full_Name: Dimosthenis Pettas Version: 2.4.23 OS: SOLARIS URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (62.159.77.167) I use OpenLDAP version 2.4.23 client to connect via TLS to an LDAP server(slapd). i initialize connection with an IPV6 address using url ldap://[fd00:1111:1111:72:20c:29ff:fec5:4ade]:389 and then try to extend connection to TLS with calling ldap_start_tls_s. when trying to match client-server certificates hosts inside tlso_session_chkhost in tls_o.c we try to determine client host type(IS_DNS,IS_IP4,IS_IP6) but for IPV6 it expects to find "[" at first position and "]" at latst one to determine IPV6 address: #ifdef LDAP_PF_INET6 if (name[0] == '[' && strchr(name, ']')) { char *n2 = ldap_strdup(name+1); *strchr(n2, ']') = 0; if (inet_pton(AF_INET6, n2, &addr)) ntype = IS_IP6; LDAP_FREE(n2); } else but it seems that [] have been removed inside ldap_url_parse_ext in Url.c: /* If [ip address]:port syntax, url is [ip and we skip the [ */ ludp->lud_host = LDAP_STRDUP( url + is_v6 ); So name is not [fd00:1111:1111:72:20c:29ff:fec5:4ade] but fd00:1111:1111:72:20c:29ff:fec5:4ade and code above fails to determine ntype = IS_IP6. i modified code to: #ifdef LDAP_PF_INET6 if (inet_pton(AF_INET6, name, &addr)) { ntype = IS_IP6; } else #endif if ((ptr = strrchr(name, '.')) && isdigit((unsigned char)ptr[1])) { if (inet_aton(name, (struct in_addr *)&addr)) { ntype = IS_IP4; } } letting functions inet_pton and inet_aton determing IP type.Scenario worked. Let me know if i miss anything or this should be corrected. Sorry for submitting again ,i wanted to correct email address

1 0

(ITS#7193) SQL backend lost part of data on request
by barlone＠yandex.ru 02 Mar '12

02 Mar '12

Full_Name: barlone Version: 2.4.30 OS: FreeBSD 7.3 URL: Submission from: (NULL) (217.12.195.21) Good day. I have MySQL database (server 5.5.20) which contain data about peoples and organizations. (Dump of this database and others files I have place on our ftp server: ftp://46.28.65.114 user: alien password: neversaynever - read only access). We need to get from LDAP accounts of peoples and organizations which have email (to Mozilla Thunderbird mail client). I setup OpenLDAP server with SQL backend, unixODBC etc. This bridge work, but have serious problem - slapd gives not all objects. I record to openldap.log full trace of loading slapd, connection of LDAP browser (Apache Directory Studio) and searching the request with base: "dc=ffsua,dc=com" and filter: "(mail=*@*)". At line #1432 backend-sql construct and run such query: SELECT DISTINCT ldap_entries.id, orgs.id, 'ffsOrganization' AS objectClass, ldap_entries.dn AS dn FROM ldap_entries, orgs WHERE orgs.id = ldap_entries.keyval AND ldap_entries.oc_map_id = 2 AND 9 = 9 AND orgs.omail IS NOT NULL AND (upper(orgs.omail) LIKE '%@%') Further in the log can be seen that backend-sql retrieves 19 records, but really in database - 22 suitable records (records with id=83,92,93 losted, look to file sql_query_result.csv). But if we watch in LDAP browser, we seen 17(!) records - look to file ldap_search_result.csv, lines with o=... I can not understand the principle on which the records drop out... Please answer, what are your opportunity to address this problem. If you have not - I'd rather know about it immediately - I will have to deal with the source. P.S. Sorry for my English...

1 0

Re: (ITS#7191) libmdb: Alignment of MDB_db members
by h.b.furuseth＠usit.uio.no 02 Mar '12

02 Mar '12

On Fri, 2 Mar 2012 08:03:00 GMT, roy.keene(a)us.army.mil wrote: > Breaking the assignment into an assignment of its members and using > the existing COPY_PGNO() alleviates this fault. memcpy would be simpler, if it is 'db' which is unaligned. Try this instead. --- mdb.c~ 2012-03-02 11:23:21 +++ mdb.c 2012-03-02 11:25:06 @@ -4699,4 +4699,3 @@ mdb_xcursor_init1(MDB_cursor *mc, MDB_no if (node->mn_flags & F_SUBDATA) { - MDB_db *db = NODEDATA(node); - mx->mx_db = *db; + memcpy(&mx->mx_db, NODEDATA(node), sizeof(MDB_db)); mx->mx_cursor.mc_snum = 0; -- Hallvard

1 0

(ITS#7191) libmdb: Alignment of MDB_db members
by roy.keene＠us.army.mil 02 Mar '12

02 Mar '12

Full_Name: Roy Keene Version: 2.4.30 OS: Solaris 10 URL: ftp://ftp.openldap.org/incoming/openldap-2.4.30-mdb-alignment-1rsk.diff Submission from: (NULL) (140.194.193.14) Several members of the MDB_db members are not aligned in the "db" or "mx->mx_db" objects. This causes a SIGBUS upon assignment. Breaking the assignment into an assignment of its members and using the existing COPY_PGNO() alleviates this fault. Patch attached is a naive approach.

1 0

(ITS#7190) back-mdb database corruption
by quanah＠OpenLDAP.org 01 Mar '12

01 Mar '12

Full_Name: Quanah Gibson-Mount Version: 2.4.29 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.108.184.39) Thread 6 (Thread 1115703648 (LWP 3574)): #0 0x0000002a9785dac7 in mdb_dup_compare (usrkey=0x42803020, curkey=0x42800bb0) at dn2id.c:65 un = (diskNode *) 0x2a984a82b8 cn = (diskNode *) 0x38a64d8480 rc = 0 nrlen = 32799 #1 0x0000002a97868719 in mdb_node_search (mc=0xb5dae8, key=0x42803020, exactp=0x42800c18) at ../../../libraries/libmdb/mdb.c:3027 i = 3402 nkeys = 6804 low = 1 high = 6803 rc = 0 mp = (MDB_page *) 0x3254934000 node = (MDB_node *) 0x3254937932 nodekey = {mv_size = 7977944, mv_data = 0x38a64d8480} cmp = (MDB_cmp_func *) 0x2a9785da94 <mdb_dup_compare> __PRETTY_FUNCTION__ = "mdb_node_search" #2 0x0000002a97868afe in mdb_page_search_root (mc=0xb5dae8, key=0x42803020, modify=0) at ../../../libraries/libmdb/mdb.c:3193 exact = 0 node = (MDB_node *) 0x32549cdb14 i = 17 mp = (MDB_page *) 0x3254934000 rc = 0 __PRETTY_FUNCTION__ = "mdb_page_search_root" #3 0x0000002a97868ed4 in mdb_page_search (mc=0xb5dae8, key=0x42803020, modify=0) at ../../../libraries/libmdb/mdb.c:3309 rc = 0 root = 3223 __PRETTY_FUNCTION__ = "mdb_page_search" #4 0x0000002a97869c5b in mdb_cursor_set (mc=0xb5dae8, key=0x42803020, data=0x0, op=MDB_SET_RANGE, exactp=0x42800f18) at ../../../libraries/libmdb/mdb.c:3651 rc = 0 mp = (MDB_page *) 0x32549ca000 leaf = (MDB_node *) 0x32549caf5c __PRETTY_FUNCTION__ = "mdb_cursor_set" #5 0x0000002a97869e8c in mdb_cursor_set (mc=0xb5d960, key=0x42803030, data=0x42803020, op=MDB_GET_BOTH, exactp=0x42800f8c) at ../../../libraries/libmdb/mdb.c:3699 ex2 = 0 ex2p = (int *) 0x42800f18 rc = 0 mp = (MDB_page *) 0x32549ca000 leaf = (MDB_node *) 0x32549caf5c __PRETTY_FUNCTION__ = "mdb_cursor_set" #6 0x0000002a9786a538 in mdb_cursor_get (mc=0xb5d960, key=0x42803030, data=0x42803020, op=MDB_GET_BOTH) at ../../../libraries/libmdb/mdb.c:3844 rc = -1739947303 exact = 1 __PRETTY_FUNCTION__ = "mdb_cursor_get" #7 0x0000002a9785e3d2 in mdb_dn2id (op=0x428037b0, txn=0xb7cfd0, mc=0xb5d960, in=0x428037e8, id=0x428030f8, matched=0x428030e0, nmatched=0x428030d0) at dn2id.c:317 mdb = (struct mdb_info *) 0x7c0e80 cursor = (MDB_cursor *) 0xb5d960 dbi = 3 key = {mv_size = 8, mv_data = 0x42800ff8} data = {mv_size = 43, mv_data = 0x2a984a82b8} rc = 0 nrlen = 32 d = (diskNode *) 0x2a984a82b8 ptr = 0x2a984a82d9 "" dn = "p?\177@\000\000\000\000@\200J\230*", '\0' <repeats 11 times>, "?\000\000\000\000\000?\000\000\000\000\000\030\000\000\000\000\000\000\000\0201\200B\000\000\000\000??\205\227*", '\0' <repeats 31 times>, "\f\000\000\000\f\000\000\000\000\000\000\000?>{\000\000\000\000\000\001", '\0' <repeats 6751 times>, "\235?N\000\000\000\000\000\2201\200B\000\000\000\000\017\000\000\000\000\000\000\000\020?\000\000\000\000\000\224?N\000\000\000\000\000\000\000\000\0002\000\000\000\000\000\234T2\000\000\000?-\200B\000\000\000\0000\030?\000\000\000\000\000p-\200B\000\000\000\000 -\200B\000\000\000\000?\216\206\227*", '\0' <repeats 11 times>... pid = 1 nid = 1 tmp = {bv_len = 31, bv_val = 0xb5eb10 "reqStart=20120222211913.000001Z,cn=accesslog"} #8 0x0000002a9785d991 in mdb_dn2entry (op=0x428037b0, tid=0xb7cfd0, m2=0xb5d960, dn=0x428037e8, e=0x428032f8, matched=0) at dn2entry.c:50 mdb = (struct mdb_info *) 0x7c0e80 rc = 0 rc2 = 0 id = 18446744073709551615 mbv = {bv_len = 12, bv_val = 0x42802ff1 "cn=accesslog"} nmbv = {bv_len = 0, bv_val = 0xb5eb30 "cn=accesslog"} mc = (MDB_cursor *) 0xb5dce0 #9 0x0000002a9784e0f8 in mdb_delete (op=0x428037b0, rs=0x42803730) at delete.c:171 mdb = (struct mdb_info *) 0x7c0e80 pdn = {bv_len = 12, bv_val = 0xb5eb30 "cn=accesslog"} e = (Entry *) 0x0 p = (Entry *) 0x2a984a80c0 manageDSAit = 0 children = (AttributeDescription *) 0x6c9970 entry = (AttributeDescription *) 0x6c96c0 txn = (MDB_txn *) 0xb7cfd0 mc = (MDB_cursor *) 0xb5d960 opinfo = {moi_oe = {oe_next = {sle_next = 0x0}, oe_key = 0x7c0e80}, moi_txn = 0xb7cfd0, moi_ref = 1, moi_flag = 0 '\0'} moi = (mdb_op_info *) 0x428032a0 preread_ctrl = (LDAPControl **) 0x0 ctrls = {0x0, 0x42803661, 0x4280365e, 0x428038f8, 0x42803340, 0x2a97abcb0b} num_ctrls = 0 parent_is_glue = 0 parent_is_leaf = 0 __PRETTY_FUNCTION__ = "mdb_delete" #10 0x00000000004c2539 in overlay_op_walk (op=0x428037b0, rs=0x42803730, which=op_delete, oi=0x7af320, on=0x0) at backover.c:671 func = (BI_op_bind **) 0x2a97979178 rc = 32768 #11 0x00000000004c2701 in over_op_func (op=0x428037b0, rs=0x42803730, which=op_delete) at backover.c:723 oi = (slap_overinfo *) 0x7af320 on = (slap_overinst *) 0x7b8cf0 be = (BackendDB *) 0x7b1d60 db = {bd_info = 0x2a97979120, bd_self = 0x7b1d60, be_ctrls = "\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001\000\000\001", '\0' <repeats 14 times>, "\001", be_flags = 2312, 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 = 0x7b03d0, be_nsuffix = 0x717690, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = {bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 9, bv_val = 0x7a0190 "cn=config"}, be_rootndn = {bv_len = 9, bv_val = 0x7a1f40 "cn=config"}, be_rootpw = {bv_len = 0, bv_val = 0x0}, be_max_deref_depth = 15, be_def_limit = {lms_t_soft = -1, lms_t_hard = 0, lms_s_soft = -1, 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 = 0x7a1e40, 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 = 0xb416f0, be_pcl_mutex = {__m_reserved = 0, __m_count = 0, __m_owner = 0x0, __m_kind = 0, __m_lock = {__status = 0, __spinlock = 0}}, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0x2a97978f20, be_private = 0x7c0e80, be_next = {stqe_next = 0x7b7d20}} cb = {sc_next = 0x2a97ccf5e0, sc_response = 0x4c16b8 <over_back_response>, sc_cleanup = 0, sc_private = 0x7af320} sc = (slap_callback **) 0x428038e8 rc = 32768 __PRETTY_FUNCTION__ = "over_op_func" #12 0x00000000004c2890 in over_op_delete (op=0x428037b0, rs=0x42803730) at backover.c:780 No locals. #13 0x0000002a97bc6e96 in accesslog_purge (ctx=0x42803ea0, arg=0x7b2690) at accesslog.c:689 i = 0 rtask = (struct re_s *) 0x7b2690 li = (struct log_info *) 0x7b2960 conn = {c_struct_state = SLAP_C_UNINITIALIZED, c_conn_state = SLAP_C_INVALID, c_conn_idx = -1, c_sd = 0, c_close_reason = 0x0, c_mutex = {__m_reserved = 0, __m_count = 0, __m_owner = 0x0, __m_kind = 0, __m_lock = {__status = 0, __spinlock = 0}}, c_sb = 0x0, c_starttime = 0, c_activitytime = 0, c_connid = 18446744073709551615, c_peer_domain = { bv_len = 0, bv_val = 0x4e5d30 ""}, c_peer_name = {bv_len = 0, bv_val = 0x4e5d30 ""}, c_listener = 0x4edca0, c_sasl_bind_mech = {bv_len = 0, bv_val = 0x0}, c_sasl_dn = {bv_len = 0, bv_val = 0x0}, c_sasl_authz_dn = {bv_len = 0, bv_val = 0x0}, c_authz_backend = 0x0, c_authz_cookie = 0x0, c_authz = {sai_method = 0, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = { bv_len = 0, bv_val = 0x0}, sai_ndn = {bv_len = 0, bv_val = 0x0}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, c_protocol = 0, c_ops = {stqh_first = 0x0, stqh_last = 0x0}, c_pending_ops = {stqh_first = 0x0, stqh_last = 0x0}, c_write1_mutex = {__m_reserved = 0, __m_count = 0, __m_owner = 0x0, __m_kind = 0, __m_lock = {__status = 0, __spinlock = 0}}, c_write1_cv = {__c_lock = {__status = 0, __spinlock = 0}, __c_waiting = 0x0, __padding = '\0' <repeats 15 times>, __align = 0}, c_write2_mutex = {__m_reserved = 0, __m_count = 0, __m_owner = 0x0, __m_kind = 0, __m_lock = {__status = 0, __spinlock = 0}}, c_write2_cv = {__c_lock = {__status = 0, __spinlock = 0}, __c_waiting = 0x0, __padding = '\0' <repeats 15 times>, __align = 0}, c_currentber = 0x0, c_writers = 0, c_writing = 0 '\0', c_sasl_bind_in_progress = 0 '\0', c_writewaiter = 0 '\0', c_is_tls = 0 '\0', c_needs_tls_accept = 0 '\0', c_sasl_layers = 0 '\0', c_sasl_done = 0 '\0', c_sasl_authctx = 0x0, c_sasl_sockctx = 0x0, c_sasl_extra = 0x0, c_sasl_bindop = 0x0, c_pagedresults_state = { ps_be = 0x0, ps_size = 0, ps_count = 0, ps_cookie = 0, ps_cookieval = {bv_len = 0, bv_val = 0x0}}, c_n_ops_received = 0, c_n_ops_executing = 0, c_n_ops_pending = 0, c_n_ops_completed = 0, c_n_get = 0, c_n_read = 0, c_n_write = 0, c_extensions = 0x0, c_clientfunc = 0, c_clientarg = 0x0, c_send_ldap_result = 0x44d934 <slap_send_ldap_result>, c_send_search_entry = 0x44e703 <slap_send_search_entry>, c_send_search_reference = 0x4506a4 <slap_send_search_reference>, c_send_ldap_extended = 0x44e22d <slap_send_ldap_extended>, c_send_ldap_intermediate = 0x44e4e0 <slap_send_ldap_intermediate>} opbuf = {ob_op = {o_hdr = 0x42803920, o_tag = 74, o_time = 1330639543, o_tincr = 4, o_bd = 0x428033d0, o_req_dn = {bv_len = 44, bv_val = 0xb4c7a0 "reqStart=20120222211913.000001Z,cn=accesslog"}, o_req_ndn = {bv_len = 44, bv_val = 0xb5eb10 "reqStart=20120222211913.000001Z,cn=accesslog"}, o_request = { oq_add = {rs_modlist = 0x1, rs_e = 0xffffffffffffffff}, oq_bind = {rb_method = 1, rb_cred = {bv_len = 18446744073709551615, bv_val = 0x0}, rb_edn = {bv_len = 1, bv_val = 0x649420 "\003"}, rb_ssf = 1115698928, rb_mech = {bv_len = 27, bv_val = 0x2a984a8018 "?3\200B"}}, oq_compare = {rs_ava = 0x1}, oq_modify = {rs_mods = {rs_modlist = 0x1, rs_no_opattrs = -1 '?'}, rs_increment = 0}, oq_modrdn = {rs_mods = {rs_modlist = 0x1, rs_no_opattrs = -1 '?'}, rs_deleteoldrdn = 0, rs_newrdn = {bv_len = 1, bv_val = 0x649420 "\003"}, rs_nnewrdn = {bv_len = 1115698928, bv_val = 0x1b <Address 0x1b out of bounds>}, rs_newSup = 0x2a984a8018, rs_nnewSup = 0x0}, oq_search = { rs_scope = 1, rs_deref = 0, rs_slimit = -1, rs_tlimit = -1, rs_limit = 0x0, rs_attrsonly = 1, rs_attrs = 0x649420, rs_filter = 0x428036f0, rs_filterstr = {bv_len = 27, bv_val = 0x2a984a8018 "?3\200B"}}, oq_abandon = {rs_msgid = 1}, oq_cancel = {rs_msgid = 1}, oq_extended = {rs_reqoid = {bv_len = 1, bv_val = 0xffffffffffffffff <Address 0xffffffffffffffff out of bounds>}, rs_flags = 0, rs_reqdata = 0x1}, oq_pwdexop = {rs_extended = {rs_reqoid = {bv_len = 1, bv_val = 0xffffffffffffffff <Address 0xffffffffffffffff out of bounds>}, rs_flags = 0, rs_reqdata = 0x1}, rs_old = {bv_len = 6591520, bv_val = 0x428036f0 "?"}, rs_new = { bv_len = 27, bv_val = 0x2a984a8018 "?3\200B"}, rs_mods = 0x0, rs_modtail = 0x0}}, o_abandon = 0, o_cancel = 0, o_groups = 0x0, o_do_not_cache = 0 '\0', o_is_auth_check = 0 '\0', o_dont_replicate = 1 '\001', o_acl_priv = ACL_NONE, o_nocaching = 0 '\0', o_delete_glue_parent = 0 '\0', o_no_schema_check = 0 '\0', o_no_subordinate_glue = 0 '\0', o_ctrlflag = '\0' <repeats 31 times>, o_controls = 0x42803a68, o_authz = {sai_method = 0, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 9, bv_val = 0x7a0190 "cn=config"}, sai_ndn = {bv_len = 9, bv_val = 0x7a1f40 "cn=config"}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, o_ber = 0x0, o_res_ber = 0x0, o_callback = 0x2a984a8018, o_ctrls = 0x0, o_csn = {bv_len = 40, bv_val = 0x42803640 "20120223220228.083128Z#000000#000#000000"}, o_private = 0x0, o_extra = {slh_first = 0x428032a0}, o_next = {stqe_next = 0x0}}, ob_hdr = {oh_opid = 0, oh_connid = 18446744073709551615, oh_conn = 0x42803b70, oh_msgid = 0, oh_protocol = 0, oh_tid = 1115703648, oh_threadctx = 0x42803ea0, oh_tmpmemctx = 0xb5bdf0, oh_tmpmfuncs = 0x6499c0, oh_counters = 0x64cde0, oh_log_prefix = "conn=-1 op=0", '\0' <repeats 243 times>}, ob_controls = { 0x0 <repeats 32 times>}} op = (Operation *) 0x428037b0 rs = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = {sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}, sru_sasl = {r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}}, sr_flags = 0} cb = {sc_next = 0x0, sc_response = 0x2a97bc686c <log_old_lookup>, sc_cleanup = 0, sc_private = 0x428036a0} f = {f_choice = 166, f_un = {f_un_result = 1115698896, f_un_desc = 0x428036d0, f_un_ava = 0x428036d0, f_un_ssa = 0x428036d0, f_un_mra = 0x428036d0, f_un_complex = 0x428036d0}, f_next = 0x0} ava = {aa_desc = 0x71f2e0, aa_value = {bv_len = 15, bv_val = 0x42803680 "20120223220543Z"}} pd = {slots = 1300, used = 1218, dn = 0xb864c0, ndn = 0xb90690, csn = {bv_len = 40, bv_val = 0x42803640 "20120223220228.083128Z#000000#000#000000"}} timebuf = "20120223220543Z\000\000\000\000\000\000" csnbuf = "20120223220228.083128Z#000000#000#000000", '\0' <repeats 23 times> old = 1330034743 __PRETTY_FUNCTION__ = "accesslog_purge" #14 0x0000002a9556992e in ldap_int_thread_pool_wrapper (xpool=0x6ce550) at tpool.c:688 pool = (struct ldap_int_thread_pool_s *) 0x6ce550 task = (ldap_int_thread_task_t *) 0xb5bcb0 work_list = (ldap_int_tpool_plist_t *) 0x6ce5e8 ctx = {ltu_id = 1115703648, ltu_key = {{ltk_key = 0x4a4a80, ltk_data = 0xb5bdf0, ltk_free = 0x4a48b0 <slap_sl_mem_destroy>}, {ltk_key = 0x2a981a4010, ltk_data = 0xb5c070, ltk_free = 0x2a9786039f <mdb_reader_free>}, {ltk_key = 0x2a97856c53, ltk_data = 0x2a988aa010, ltk_free = 0x2a97856c33 <search_stack_free>}, {ltk_key = 0x2a978549bd, ltk_data = 0x2a985a9010, ltk_free = 0x2a97854978 <scope_chunk_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>}} kctx = (ldap_int_thread_userctx_t *) 0x0 i = 32 keyslot = 299 hash = 3142175019 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #15 0x0000003252c0610a in start_thread () from /lib64/tls/libpthread.so.0 No symbol table info available. #16 0x00000032523c6003 in clone () from /lib64/tls/libc.so.6 No symbol table info available. #17 0x0000000000000000 in ?? () No symbol table info available. Thread 5 (Thread 1107310944 (LWP 3573)): #0 0x0000003252c089aa in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/tls/libpthread.so.0 No symbol table info available. #1 0x0000002a9556ae8c in ldap_pvt_thread_cond_wait (cond=0x6ce580, mutex=0x6ce558) at thr_posix.c:277 No locals. #2 0x0000002a955698af in ldap_int_thread_pool_wrapper (xpool=0x6ce550) at tpool.c:675 pool = (struct ldap_int_thread_pool_s *) 0x6ce550 task = (ldap_int_thread_task_t *) 0x0 work_list = (ldap_int_tpool_plist_t *) 0x6ce5e8 ctx = {ltu_id = 1107310944, ltu_key = {{ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 32 times>}} kctx = (ldap_int_thread_userctx_t *) 0x0 i = 32 keyslot = 155 hash = 3239160987 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #3 0x0000003252c0610a in start_thread () from /lib64/tls/libpthread.so.0 No symbol table info available. #4 0x00000032523c6003 in clone () from /lib64/tls/libc.so.6 No symbol table info available. #5 0x0000000000000000 in ?? () No symbol table info available. Thread 4 (Thread 1098918240 (LWP 3572)): #0 0x0000003252c089aa in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/tls/libpthread.so.0 No symbol table info available. #1 0x0000002a9556ae8c in ldap_pvt_thread_cond_wait (cond=0x6ce580, mutex=0x6ce558) at thr_posix.c:277 No locals. #2 0x0000002a955698af in ldap_int_thread_pool_wrapper (xpool=0x6ce550) at tpool.c:675 pool = (struct ldap_int_thread_pool_s *) 0x6ce550 task = (ldap_int_thread_task_t *) 0x0 work_list = (ldap_int_tpool_plist_t *) 0x6ce5e8 ctx = {ltu_id = 1098918240, ltu_key = {{ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 32 times>}} kctx = (ldap_int_thread_userctx_t *) 0x0 i = 32 keyslot = 138 hash = 468719754 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #3 0x0000003252c0610a in start_thread () from /lib64/tls/libpthread.so.0 No symbol table info available. #4 0x00000032523c6003 in clone () from /lib64/tls/libc.so.6 No symbol table info available. #5 0x0000000000000000 in ?? () No symbol table info available. Thread 3 (Thread 1090525536 (LWP 3571)): #0 0x0000003252c089aa in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/tls/libpthread.so.0 No symbol table info available. #1 0x0000002a9556ae8c in ldap_pvt_thread_cond_wait (cond=0x6ce580, mutex=0x6ce558) at thr_posix.c:277 No locals. #2 0x0000002a955698af in ldap_int_thread_pool_wrapper (xpool=0x6ce550) at tpool.c:675 pool = (struct ldap_int_thread_pool_s *) 0x6ce550 task = (ldap_int_thread_task_t *) 0x0 work_list = (ldap_int_tpool_plist_t *) 0x6ce5e8 ctx = {ltu_id = 1090525536, ltu_key = {{ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 32 times>}} kctx = (ldap_int_thread_userctx_t *) 0x0 i = 32 keyslot = 1018 hash = 565705722 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #3 0x0000003252c0610a in start_thread () from /lib64/tls/libpthread.so.0 No symbol table info available. #4 0x00000032523c6003 in clone () from /lib64/tls/libc.so.6 No symbol table info available. #5 0x0000000000000000 in ?? () No symbol table info available. Thread 2 (Thread 1082132832 (LWP 3570)): #0 0x00000032523c63dc in epoll_wait () from /lib64/tls/libc.so.6 No symbol table info available. #1 0x0000000000434488 in slapd_daemon_task (ptr=0x7fbffff6e4) at daemon.c:2539 ns = 1 at = 0 nfds = 6 revents = (struct epoll_event *) 0x6a4b90 tvp = (struct timeval *) 0x40800170 cat = {tv_sec = 1330639843, tv_usec = 0} i = 1 nwriters = 0 now = 1330639543 tv = {tv_sec = 300, tv_usec = 0} tdelta = 1 rtask = (struct re_s *) 0x798870 l = 5 last_idle_check = 1330639543 ebadf = 0 tid = 0 #2 0x0000003252c0610a in start_thread () from /lib64/tls/libpthread.so.0 No symbol table info available. #3 0x00000032523c6003 in clone () from /lib64/tls/libc.so.6 No symbol table info available. #4 0x0000000000000000 in ?? () No symbol table info available. Thread 1 (Thread 182905778400 (LWP 3567)): #0 0x0000003252c06ffb in pthread_join () from /lib64/tls/libpthread.so.0 No symbol table info available. #1 0x0000002a9556ade4 in ldap_pvt_thread_join (thread=1082132832, thread_return=0x0) at thr_posix.c:197 No locals. #2 0x00000000004355fe in slapd_daemon () at daemon.c:2930 i = 0 rc = 0 listener_tid = (ldap_pvt_thread_t *) 0x7b2720 #3 0x000000000041500a in main (argc=11, argv=0x7fbffff8d8) at main.c:1012 i = 11 no_detach = 1 rc = 0 urls = 0x69e030 "ldap:/// ldaps:/// ldapi:///" username = 0x69e010 "localhost" groupname = 0x0 sandbox = 0x0 syslogUser = 128 pid = 1376822842 waitfds = {0, 0} g_argc = 11 g_argv = (char **) 0x7fbffff8d8 configfile = 0x0 configdir = 0x69e060 "/opt/zimbra/data/ldap/config" serverName = 0x7fbffffb3f "slapd" serverMode = 1 scp = (struct sync_cookie *) 0x0 scp_entry = (struct sync_cookie *) 0x0 debug_unknowns = (char **) 0x0 syslog_unknowns = (char **) 0x0 serverNamePrefix = 0x4e5845 "" l = 0 slapd_pid_file_unlink = 1 slapd_args_file_unlink = 1 firstopt = 0 __PRETTY_FUNCTION__ = "main"

1 0

Re: (ITS#7189) OPEN LDAP - Bug
by quanah＠zimbra.com 01 Mar '12

01 Mar '12

--On Thursday, March 01, 2012 2:51 PM +0000 jose.gomez(a)cafedecolombia.com wrote: > Full_Name: Jose Alberto G?mez Ruiz > Version: OpenLDAP: pkg/ldap/servers/slapd/schema/openldap.schema,v > 1.24.2.4 This is not a valid OpenLDAP version. > deleting entry > cn=1093735269,ou=ServicioExtension,ou=Usuarios,dc=fnc-federacion,dc=com > ldap_delete: Unknown error > ldap_delete: additional info: could not locate parent of entry This message says you somehow deleted the parent of the entry without deleting this entry first, leaving it orphaned. I would suggest you use slapcat & slapadd to fix your database. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7189) OPEN LDAP - Bug
by jose.gomez＠cafedecolombia.com 01 Mar '12

01 Mar '12

Full_Name: Jose Alberto Gómez Ruiz Version: OpenLDAP: pkg/ldap/servers/slapd/schema/openldap.schema,v 1.24.2.4 OS: Solaris 10 10/08 s10s_u6wos_07b SPARC URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (200.3.164.196) Hello, I have a problem with OPEN LDAP V.2.4 : I am trying to add the th following entry by console : -bash-3.00$ ldapadd -f empleado-103.txt -v -D "cn=Manager,dc=fnc-federacion,dc=com" -w password ldapadd: started Wed Feb 29 16:56:24 2012 ldap_init( localhost, 389 ) add cn: 1093735269 add sn: ROCHEL ORTEGA ELIZABETH add mail: add userPassword: 1093735269 add objectclass: inetOrgPerson FNCPerson adding new entry cn=1093735269,ou=ServicioExtension,ou=Usuarios,dc=fnc-federacion,dc=com ldap_add: Already exists The entry exists agree with the message. Then I want search thy entry : -bash-3.00$ ldapsearch -x -b 'dc=fnc-federacion,dc=com' '(cn=1093735269*)' -bash-3.00$ I do not get the data from this input. Then I cant delete the same entry: -bash-3.00$ ldapmodify -D "cn=Manager,dc=fnc-federacion,dc=com" -w password dn: cn=1093735269,ou=ServicioExtension,ou=Usuarios,dc=fnc-federacion,dc=com changetype: delete deleting entry cn=1093735269,ou=ServicioExtension,ou=Usuarios,dc=fnc-federacion,dc=com ldap_delete: Unknown error ldap_delete: additional info: could not locate parent of entry I Can't modify or delete this entry, Please, I need help to fix this error. Thanks in advance

1 0

(ITS#7188) slapschema.8 manpage formatting problems
by peb＠mppmu.mpg.de 01 Mar '12

01 Mar '12

Full_Name: Peter Breitenlohner Version: 2.4.30 OS: Linux.GNU URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (134.107.24.63) The slapschema.8 manpage exhibits some formatting problems (already present in 2.4.23 and maybe earlier): In line 30 a font change '\fR' is misspelled as '\FR' Line 56 ought to end after the word 'slapschema'; the rest should be on a separate line.

1 0

(ITS#7182) back-ldap monitoring improvements
by ondrej.kuznik＠acision.com 28 Feb '12

28 Feb '12

Full_Name: Ondrej Kuznik Version: HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20120228-back-ldap-monitoring… Submission from: (NULL) (62.168.56.1) I have prepared some patches to back-ldap (and one to back-monitor) that expose operation and connection monitoring information from a running back-ldap database and I would like to see this or similar functionality included in the OpenLDAP codebase. The url above contains a patchset against HEAD for review. The following things are yet to be resolved: - there is no monitoring of completed operations yet, only operations initiated against the remote database(s). - the binds performed by the ldap_back_default_rebind function are not counted - slapo-chain has not been tested yet - test suite integration: back-ldap looks excluded from the test suite - better connection handling (connections should have stable identifiers) The obligatory license clause follows: The attached file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Acision. Acision has not assigned rights and/or interest in this work to any party. I, Ondrej Kuznik am authorized by Acision, my employer, to release this work under the following terms. The attached modifications to OpenLDAP Software are subject to the following notice: Copyright 2012 Acision Redistribution and use in source and binary forms, with or without modification, are permitted only as authorized by the OpenLDAP Public License.

1 0

RE: (ITS#7102) slapd segfaults on slapo-dds refresh with syncprov enabled
by Petteri.Stenius＠ubisecure.com 27 Feb '12

27 Feb '12

Hello, I run into this same issue. However the segfault only happens if the dds overlay is defined before the syncprov overlay in slapd.conf. Br, Petteri Stenius -----Original Message----- From: openldap-bugs-bounces(a)OpenLDAP.org [mailto:openldap-bugs-bounces@OpenLDAP.org] On Behalf Of dieter(a)dkluenter.de Sent: 30. marraskuuta 2011 12:12 To: openldap-its(a)openldap.org Subject: (ITS#7102) slapd segfaults on slapo-dds refresh with syncprov enabled Full_Name: Dieter Kluenter Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (141.38.5.243) slapd crashes with segmentation fault on a slapo-dds refresh operation, if syncprov is enabled and configured (gdb) bt #0 0x00000000004dd429 in slap_get_commit_csn (op=0x7f01d8013530, maxcsn=0x7f01e6a346d0, foundit=0x7f01e6a346cc) at ctxcsn.c:59 #1 0x00007f01f0d0a401 in syncprov_op_response (op=0x7f01d8013530, rs=0x7f01e6a34a30) at syncprov.c:1793 #2 0x000000000045cbff in slap_response_play (op=0x7f01d8013530, rs=0x7f01e6a34a30) at result.c:505 #3 0x000000000045ce24 in send_ldap_response (op=0x7f01d8013530, rs=0x7f01e6a34a30) at result.c:580 #4 0x000000000045e292 in slap_send_ldap_extended (op=0x7f01d8013530, rs=0x7f01e6a34a30) at result.c:915 #5 0x000000000048aedb in fe_extended (op=0x7f01d8013530, rs=0x7f01e6a34a30) at extended.c:237 #6 0x000000000048ab57 in do_extended (op=0x7f01d8013530, rs=0x7f01e6a34a30) at extended.c:177 #7 0x0000000000446a15 in connection_operation (ctx=0x7f01e6a34b60, arg_v=0x7f01d8013530) at connection.c:1138 #8 0x0000000000446fb3 in connection_read_thread (ctx=0x7f01e6a34b60, argv=0x10) at connection.c:1274 #9 0x00007f01f5929fc0 in ldap_int_thread_pool_wrapper (xpool=0x91d540) at tpool.c:685 #10 0x00007f01f48f0a3f in start_thread (arg=0x7f01e6a35700) at pthread_create.c:297 #11 0x00007f01f3c1166d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 #12 0x0000000000000000 in ?? () (gdb) frame 0 #0 0x00000000004dd429 in slap_get_commit_csn (op=0x7f01d8013530, maxcsn=0x7f01e6a346d0, foundit=0x7f01e6a346cc) at ctxcsn.c:59 59 LDAP_TAILQ_FOREACH( csne, be->be_pending_csn_list, ce_csn_link ) { (gdb) frame 1 #1 0x00007f01f0d0a401 in syncprov_op_response (op=0x7f01d8013530, rs=0x7f01e6a34a30) at syncprov.c:1793 1793 slap_get_commit_csn( op, &maxcsn, &foundit ); (gdb) frame 2 #2 0x000000000045cbff in slap_response_play (op=0x7f01d8013530, rs=0x7f01e6a34a30) at result.c:505 505 rc = op->o_callback->sc_response( op, rs ); (gdb) frame 3 #3 0x000000000045ce24 in send_ldap_response (op=0x7f01d8013530, rs=0x7f01e6a34a30) at result.c:580 580 rc = slap_response_play( op, rs ); (gdb) -Dieter

1 0

Re: (ITS#7181) off by 2 error in --ldif-wrap
by hyc＠symas.com 26 Feb '12

26 Feb '12

Hallvard B Furuseth wrote: > On Sat, 25 Feb 2012 00:19:11 GMT, hyc(a)symas.com wrote: >> h.b.furuseth(a)usit.uio.no wrote: >>> The client option --ldif-wrap=N outputs lines of N+2 columns. >>> E.g. 'ldapsearch -o ldif-wrap=20 ...' gives 22-column output. >> >> Not a bug. See libldap/ldif.c:490. > > That's old an internal matter, exposed as default wrap width 78 > instead of rfc2849's max 76. > > This ITS is about the new --ldif-wrap option. The tools can just > subtract 2 from the input value and otherwise keep the current code. But then the tools will be wrong when we fix the library. > (I do think we should throw away the old bug-compat code and > fix the default 78 to 76, but not in RE24. And I note the bug- > compat comment claims it's off by 1 while it's actually 2:) Sure, I'd like to throw that all out too. But in the meantime, I'd rather not have the tools' functionality change twice over the same issue. (I.e., fix the tools now, then fix the libraries later and have to re-fix the tools.) -- -- 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#7181) off by 2 error in --ldif-wrap
by h.b.furuseth＠usit.uio.no 25 Feb '12

25 Feb '12

On Sat, 25 Feb 2012 00:19:11 GMT, hyc(a)symas.com wrote: > h.b.furuseth(a)usit.uio.no wrote: >> The client option --ldif-wrap=N outputs lines of N+2 columns. >> E.g. 'ldapsearch -o ldif-wrap=20 ...' gives 22-column output. > > Not a bug. See libldap/ldif.c:490. That's old an internal matter, exposed as default wrap width 78 instead of rfc2849's max 76. This ITS is about the new --ldif-wrap option. The tools can just subtract 2 from the input value and otherwise keep the current code. (I do think we should throw away the old bug-compat code and fix the default 78 to 76, but not in RE24. And I note the bug- compat comment claims it's off by 1 while it's actually 2:) -- Hallvard

1 0

Re: (ITS#7181) off by 2 error in --ldif-wrap
by hyc＠symas.com 25 Feb '12

25 Feb '12

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: 2.4.29 > OS: Linux x86_64 > URL: > Submission from: (NULL) (195.1.106.125) > Submitted by: hallvard > > > The client option --ldif-wrap=N outputs lines of N+2 columns. > E.g. 'ldapsearch -o ldif-wrap=20 ...' gives 22-column output. Not a bug. See libldap/ldif.c:490. -- -- 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#7180) libmdb assertion error on slapadd
by quanah＠zimbra.com 24 Feb '12

24 Feb '12

--On Thursday, February 23, 2012 5:42 PM +0000 quanah(a)OpenLDAP.org wrote: >#################### 100.00% eta none elapsed none fast! > slapadd: ../../../libraries/libmdb/mdb.c:3827: mdb_cursor_get: Assertion > `mc' failed. > Aborted This is specifically triggered the flags used with slapadd: /opt/zimbra/openldap/sbin/slapadd -q -w -b '' -F /opt/zimbra/data/ldap/config -cv -l /tmp/ldap.bak Specifically the "-w" flag is what triggers it. No error occurs without -w. Thread 1 (Thread 0x7ffff7fef700 (LWP 25466)): #0 0x00007ffff6372a75 in raise () from /lib/libc.so.6 No symbol table info available. #1 0x00007ffff63765c0 in abort () from /lib/libc.so.6 No symbol table info available. #2 0x00007ffff636b941 in __assert_fail () from /lib/libc.so.6 No symbol table info available. #3 0x00007ffff38432d0 in mdb_cursor_get (mc=0x0, key=0x7ffff3a53eb0, data=0x7ffff3a53ec0, op=MDB_SET) at ../../../libraries/libmdb/mdb.c:3827 rc = 1301783142 exact = 0 __PRETTY_FUNCTION__ = "mdb_cursor_get" #4 0x00007ffff381c4db in mdb_tool_entry_get_int (be=0x8ff470, id=0, ep=0x7fffffffe568) at tools.c:323 op = {o_hdr = 0x0, o_tag = 0, o_time = 0, o_tincr = 0, o_bd = 0x0, o_req_dn = {bv_len = 0, bv_val = 0x0}, o_req_ndn = {bv_len = 0, bv_val = 0x0}, o_request = {oq_add = { rs_modlist = 0x0, rs_e = 0x0}, oq_bind = {rb_method = 0, rb_cred = {bv_len = 0, bv_val = 0x0}, rb_edn = {bv_len = 0, bv_val = 0x0}, rb_ssf = 0, rb_mech = {bv_len = 0, bv_val = 0x0}}, oq_compare = {rs_ava = 0x0}, oq_modify = {rs_mods = {rs_modlist = 0x0, rs_no_opattrs = 0 '\000'}, rs_increment = 0}, oq_modrdn = {rs_mods = { rs_modlist = 0x0, rs_no_opattrs = 0 '\000'}, rs_deleteoldrdn = 0, rs_newrdn = {bv_len = 0, bv_val = 0x0}, rs_nnewrdn = {bv_len = 0, bv_val = 0x0}, rs_newSup = 0x0, rs_nnewSup = 0x0}, oq_search = {rs_scope = 0, rs_deref = 0, rs_slimit = 0, rs_tlimit = 0, rs_limit = 0x0, rs_attrsonly = 0, rs_attrs = 0x0, rs_filter = 0x0, rs_filterstr = { bv_len = 0, bv_val = 0x0}}, oq_abandon = {rs_msgid = 0}, oq_cancel = {rs_msgid = 0}, oq_extended = {rs_reqoid = {bv_len = 0, bv_val = 0x0}, rs_flags = 0, rs_reqdata = 0x0}, oq_pwdexop = {rs_extended = {rs_reqoid = {bv_len = 0, bv_val = 0x0}, rs_flags = 0, rs_reqdata = 0x0}, rs_old = {bv_len = 0, bv_val = 0x0}, rs_new = { bv_len = 0, bv_val = 0x0}, rs_mods = 0x0, rs_modtail = 0x0}}, o_abandon = 0, o_cancel = 0, o_groups = 0x0, o_do_not_cache = 0 '\000', o_is_auth_check = 0 '\000', o_dont_replicate = 0 '\000', o_acl_priv = ACL_NONE, o_nocaching = 0 '\000', o_delete_glue_parent = 0 '\000', o_no_schema_check = 0 '\000', o_no_subordinate_glue = 0 '\000', o_ctrlflag = '\000' <repeats 31 times>, o_controls = 0x0, o_authz = {sai_method = 0, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 0, bv_val = 0x0}, sai_ndn = { bv_len = 0, bv_val = 0x0}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, o_ber = 0x0, o_res_ber = 0x0, o_callback = 0x0, o_ctrls = 0x0, o_csn = { bv_len = 0, bv_val = 0x0}, o_private = 0x0, o_extra = {slh_first = 0x0}, o_next = {stqe_next = 0x0}} ohdr = {oh_opid = 0, oh_connid = 0, oh_conn = 0x0, oh_msgid = 0, oh_protocol = 0, oh_tid = 0, oh_threadctx = 0x0, oh_tmpmemctx = 0x0, oh_tmpmfuncs = 0x0, oh_counters = 0x0, oh_log_prefix = '\000' <repeats 255 times>} e = 0x0 dn = {bv_len = 0, bv_val = 0x0} ndn = {bv_len = 0, bv_val = 0x0} rc = 32767 __PRETTY_FUNCTION__ = "mdb_tool_entry_get_int" #5 0x00007ffff381c72d in mdb_tool_entry_get (be=0x8ff470, id=0) at tools.c:373 e = 0x0 #6 0x00000000004db69a in slap_tool_update_ctxcsn (progname=0x51a020 "slapadd", sid=18446744073709551615, bvtext=0x7fffffffe6c0) at slapcommon.c:1004 ctxdn = {bv_len = 0, bv_val = 0x8d1c50 ""} ctxcsn_id = 0 ctxcsn_e = 0x75ff68 rc = 0 __PRETTY_FUNCTION__ = "slap_tool_update_ctxcsn" #7 0x00000000004d8ecb in slapadd (argc=10, argv=0x7fffffffea18) at slapadd.c:472 textbuf = '\000' <repeats 255 times> textlen = 256 erec = {e = 0x7ebf68, lineno = 2857, nextline = 2857} bvtext = {bv_len = 256, bv_val = 0x7fffffffe700 ""} thr = 0 id = 73 ldifrc = 0 rc = 0 stat_buf = {st_dev = 64256, st_ino = 1441881, st_nlink = 1, st_mode = 33184, st_uid = 1001, st_gid = 1001, __pad0 = 0, st_rdev = 0, st_size = 115070, st_blksize = 4096, st_blocks = 232, st_atim = {tv_sec = 1330122358, tv_nsec = 391982437}, st_mtim = {tv_sec = 1330122344, tv_nsec = 272000000}, st_ctim = {tv_sec = 1330122346, tv_nsec = 832002048}, __unused = {0, 0, 0}} #8 0x0000000000415910 in main (argc=10, argv=0x7fffffffea18) at main.c:410 i = 0 no_detach = 0 rc = 1 urls = 0x0 username = 0x0 groupname = 0x0 sandbox = 0x0 syslogUser = 160 pid = 0 waitfds = {3817984, 0} g_argc = 10 g_argv = 0x7fffffffea18 configfile = 0x0 configdir = 0x0 serverName = 0x7fffffffec9d "slapadd" serverMode = 1 scp = 0x0 scp_entry = 0x0 debug_unknowns = 0x0 syslog_unknowns = 0x0 serverNamePrefix = 0x4f95e8 "" l = 140737488349422 slapd_pid_file_unlink = 0 slapd_args_file_unlink = 0 firstopt = 1 __PRETTY_FUNCTION__ = "main" (gdb) -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7181) off by 2 error in --ldif-wrap
by h.b.furuseth＠usit.uio.no 24 Feb '12

24 Feb '12

Full_Name: Hallvard B Furuseth Version: 2.4.29 OS: Linux x86_64 URL: Submission from: (NULL) (195.1.106.125) Submitted by: hallvard The client option --ldif-wrap=N outputs lines of N+2 columns. E.g. 'ldapsearch -o ldif-wrap=20 ...' gives 22-column output.

1 0

Re: (ITS#7177) [PATCH] various manpage fixes
by hyc＠symas.com 23 Feb '12

23 Feb '12

h.b.furuseth(a)usit.uio.no wrote: > On Thu, 23 Feb 2012 20:31:09 GMT, hyc(a)symas.com wrote: >> It seems unnecessary to document ldif-wrap in all of the commands, >> since only ldapsearch actually produces LDIF output. > > No, controls can also request LDIF output. E.g. > ldapmodify -e preread -o ldif-wrap=20 > wraps after column... 22?? New ITS coming up. > OK, in that case I don't see any reason to tweak that part of the patch. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs