- openldap-bugs - openldap.org

Re: (ITS#6402) Mismatched parentheses in LBER_INVALID macro
by h.b.furuseth＠usit.uio.no 27 Nov '09

27 Nov '09

julianfoad(a)btopenworld.com writes: > The definition of the macro LBER_INVALID in 'include/lber.h' has > mismatched (unbalanced) parentheses, meaning that it cannot be used as > a valid C expression by itself. Wow. You are the first to notice for 10 years. The test is incomplete too. I guess I can come up with bit hack for a better test is anyone is interested, but otherwise we can just delete it. The macro only existed without a parse error for one month in 1999, in revision 1.17 through 1.30. Next revision broke it with commit message "Fix bad LBER_INVALID macro":-) -- Hallvard

1 0

(ITS#6402) Mismatched parentheses in LBER_INVALID macro
by julianfoad＠btopenworld.com 27 Nov '09

27 Nov '09

Full_Name: Julian Foad Version: CVS head (include/lber.h r1.111) OS: Linux URL: ftp://ftp.openldap.org/incoming/julian-foad-091127.patch Submission from: (NULL) (217.169.20.120) The definition of the macro LBER_INVALID in 'include/lber.h' has mismatched (unbalanced) parentheses, meaning that it cannot be used as a valid C expression by itself. This error was noticed when parsing the file with 'ctypesgen' as part of building the ctypes-python bindings of Subversion. The patch to fix it, in Unidiff format, looks like this: #define LBER_INVALID(t) (((t) & (ber_tag_t) 0x080UL) \ - && (((t) & (ber_tag_t) ~ 0x0FF)) + && ((t) & (ber_tag_t) ~ 0x0FF)) I uploaded the patch file; URL is filled in below. The macro is not used within the openldap source, so this problem and this fix makes no difference to the building and testing of openldap itself.

1 0

Re: (ITS#6365) Bad slapcat output when slapd running
by hyc＠symas.com 25 Nov '09

25 Nov '09

masarati(a)aero.polimi.it wrote: >> Howard Chu wrote: >>> Of course, no one is saying for certain that this is the explanation, >>> yet. >> >> It sounds reasonable to me :) > Based on my *very incomplete and possibly wrong* analysis, the problem > would be automatically cured by using back-bdb. Also, fixing back-hdb *if > it's broken at all* should be possible. Quite certain this is not the explanation, since syncrepl will call syncrepl_add_glue() whenever it needs to store an entry that doesn't yet have its parent. -- -- 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#6401) openldap doesn't start......
by quanah＠zimbra.com 24 Nov '09

24 Nov '09

--On Tuesday, November 24, 2009 6:20 PM +0000 luisvm87(a)gmail.com wrote: > Full_Name: Luis Vargas Mieles > Version: 2.4.19 > OS: centOS > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (200.93.195.131) > slapd starting > ........ and slapd never start -.- I don't know where the mistake is... I > checked the configuration files slapd.conf, odbc.ini, odbcinst.ini and I > can't find the mistake, please help me =) How are you checking on whether or not slapd ever "started"? Is there a slapd process? Maybe it is waiting on a connection to the mysql server. In any case, the ITS system is not for questions about how to use/configure OpenLDAP. Please direct such questions to the openldap-software(a)openldap.org mailing list. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6401) openldap doesn't start......
by luisvm87＠gmail.com 24 Nov '09

24 Nov '09

Full_Name: Luis Vargas Mieles Version: 2.4.19 OS: centOS URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (200.93.195.131) Hello when I started the slapd, it generates these sentences... [root@localhost ~]# /usr/local/libexec/slapd -d 1 @(#) $OpenLDAP: slapd 2.4.19 (Nov 23 2009 19:03:54) $ root@localhost.localdomain:/usr/src/openldap-2.4.19/servers/slapd ldap_pvt_gethostbyname_a: host=localhost.localdomain, r=0 daemon_init: listen on ldap:/// daemon_init: 1 listeners to open... ldap_url_parse_ext(ldap:///) daemon: listener initialized ldap:/// daemon_init: 2 listeners opened ldap_create slapd init: initiated server. slap_sasl_init: initialized! bdb_back_initialize: initialize BDB backend bdb_back_initialize: Berkeley DB 4.8.24: (August 14, 2009) hdb_back_initialize: initialize HDB backend hdb_back_initialize: Berkeley DB 4.8.24: (August 14, 2009) ==>sql_back_initialize() <==sql_back_initialize() ==>backsql_db_init() ==>backsql_init_db_env() <==backsql_init_db_env()=0 <==backsql_db_init() >>> dnPrettyNormal: <o=sql,c=RU> <<< dnPrettyNormal: <o=sql,c=RU>, <o=sql,c=ru> >>> dnPrettyNormal: <cn=root,o=sql,c=RU> <<< dnPrettyNormal: <cn=root,o=sql,c=RU>, <cn=root,o=sql,c=ru> ==>backsql_db_config() <==backsql_db_config(): dbname=example ==>backsql_db_config() <==backsql_db_config(): dbuser=root ==>backsql_db_config() <==backsql_db_config(): dbpasswd=xxxx ==>backsql_db_config() <==backsql_db_config(): subtree_cond=ldap_entries.dn LIKE CONCAT('%',?) ==>backsql_db_config() <==backsql_db_config(): insentry_stmt=INSERT INTO ldap_entries (dn,oc_map_id,parent,keyval) VALUES (?,?,?,?) ==>backsql_db_config() <==backsql_db_config(): has_ldapinfo_dn_ru=no >>> dnNormalize: <cn=Subschema> <<< dnNormalize: <cn=subschema> matching_rule_use_init 1.2.840.113556.1.4.804 (integerBitOrMatch): matchingRuleUse: ( 1.2.840.113556.1.4.804 NAME 'integerBitOrMatch' APPLIES ( supportedLDAPVersion $ entryTtl $ uidNumber $ gidNumber $ olcConcurrency $ olcConnMaxPending $ olcConnMaxPendingAuth $ olcIdleTimeout $ olcIndexSubstrIfMinLen $ olcIndexSubstrIfMaxLen $ olcIndexSubstrAnyLen $ olcIndexSubstrAnyStep $ olcIndexIntLen $ olcLocalSSF $ olcMaxDerefDepth $ olcReplicationInterval $ olcSockbufMaxIncoming $ olcSockbufMaxIncomingAuth $ olcThreads $ olcToolThreads $ olcWriteTimeout $ olcDbCacheFree $ olcDbCacheSize $ olcDbDNcacheSize $ olcDbIDLcacheSize $ olcDbSearchStack $ olcDbShmKey $ olcSpSessionlog $ mailPreferenceOption ) ) 1.2.840.113556.1.4.803 (integerBitAndMatch): matchingRuleUse: ( 1.2.840.113556.1.4.803 NAME 'integerBitAndMatch' APPLIES ( supportedLDAPVersion $ entryTtl $ uidNumber $ gidNumber $ olcConcurrency $ olcConnMaxPending $ olcConnMaxPendingAuth $ olcIdleTimeout $ olcIndexSubstrIfMinLen $ olcIndexSubstrIfMaxLen $ olcIndexSubstrAnyLen $ olcIndexSubstrAnyStep $ olcIndexIntLen $ olcLocalSSF $ olcMaxDerefDepth $ olcReplicationInterval $ olcSockbufMaxIncoming $ olcSockbufMaxIncomingAuth $ olcThreads $ olcToolThreads $ olcWriteTimeout $ olcDbCacheFree $ olcDbCacheSize $ olcDbDNcacheSize $ olcDbIDLcacheSize $ olcDbSearchStack $ olcDbShmKey $ olcSpSessionlog $ mailPreferenceOption ) ) 1.3.6.1.4.1.1466.109.114.2 (caseIgnoreIA5Match): matchingRuleUse: ( 1.3.6.1.4.1.1466.109.114.2 NAME 'caseIgnoreIA5Match' APPLIES ( altServer $ olcDbConfig $ c $ mail $ dc $ associatedDomain $ email $ aRecord $ mDRecord $ mXRecord $ nSRecord $ sOARecord $ cNAMERecord $ janetMailbox ) ) 1.3.6.1.4.1.1466.109.114.1 (caseExactIA5Match): matchingRuleUse: ( 1.3.6.1.4.1.1466.109.114.1 NAME 'caseExactIA5Match' APPLIES ( altServer $ olcDbConfig $ c $ mail $ dc $ associatedDomain $ email $ aRecord $ mDRecord $ mXRecord $ nSRecord $ sOARecord $ cNAMERecord $ janetMailbox ) ) 2.5.13.39 (certificateListMatch): 2.5.13.38 (certificateListExactMatch): matchingRuleUse: ( 2.5.13.38 NAME 'certificateListExactMatch' APPLIES ( authorityRevocationList $ certificateRevocationList $ deltaRevocationList ) ) 2.5.13.35 (certificateMatch): 2.5.13.34 (certificateExactMatch): matchingRuleUse: ( 2.5.13.34 NAME 'certificateExactMatch' APPLIES ( userCertificate $ cACertificate ) ) 2.5.13.30 (objectIdentifierFirstComponentMatch): matchingRuleUse: ( 2.5.13.30 NAME 'objectIdentifierFirstComponentMatch' APPLIES ( supportedControl $ supportedExtension $ supportedFeatures $ ldapSyntaxes $ supportedApplicationContext ) ) 2.5.13.29 (integerFirstComponentMatch): matchingRuleUse: ( 2.5.13.29 NAME 'integerFirstComponentMatch' APPLIES ( supportedLDAPVersion $ entryTtl $ uidNumber $ gidNumber $ olcConcurrency $ olcConnMaxPending $ olcConnMaxPendingAuth $ olcIdleTimeout $ olcIndexSubstrIfMinLen $ olcIndexSubstrIfMaxLen $ olcIndexSubstrAnyLen $ olcIndexSubstrAnyStep $ olcIndexIntLen $ olcLocalSSF $ olcMaxDerefDepth $ olcReplicationInterval $ olcSockbufMaxIncoming $ olcSockbufMaxIncomingAuth $ olcThreads $ olcToolThreads $ olcWriteTimeout $ olcDbCacheFree $ olcDbCacheSize $ olcDbDNcacheSize $ olcDbIDLcacheSize $ olcDbSearchStack $ olcDbShmKey $ olcSpSessionlog $ mailPreferenceOption ) ) 2.5.13.27 (generalizedTimeMatch): matchingRuleUse: ( 2.5.13.27 NAME 'generalizedTimeMatch' APPLIES ( createTimestamp $ modifyTimestamp ) ) 2.5.13.24 (protocolInformationMatch): matchingRuleUse: ( 2.5.13.24 NAME 'protocolInformationMatch' APPLIES protocolInformation ) 2.5.13.23 (uniqueMemberMatch): matchingRuleUse: ( 2.5.13.23 NAME 'uniqueMemberMatch' APPLIES uniqueMember ) 2.5.13.22 (presentationAddressMatch): matchingRuleUse: ( 2.5.13.22 NAME 'presentationAddressMatch' APPLIES presentationAddress ) 2.5.13.20 (telephoneNumberMatch): matchingRuleUse: ( 2.5.13.20 NAME 'telephoneNumberMatch' APPLIES ( telephoneNumber $ homePhone $ mobile $ pager ) ) 2.5.13.17 (octetStringMatch): matchingRuleUse: ( 2.5.13.17 NAME 'octetStringMatch' APPLIES ( userPassword $ olcDbCryptKey ) ) 2.5.13.16 (bitStringMatch): matchingRuleUse: ( 2.5.13.16 NAME 'bitStringMatch' APPLIES x500UniqueIdentifier ) 2.5.13.14 (integerMatch): matchingRuleUse: ( 2.5.13.14 NAME 'integerMatch' APPLIES ( supportedLDAPVersion $ entryTtl $ uidNumber $ gidNumber $ olcConcurrency $ olcConnMaxPending $ olcConnMaxPendingAuth $ olcIdleTimeout $ olcIndexSubstrIfMinLen $ olcIndexSubstrIfMaxLen $ olcIndexSubstrAnyLen $ olcIndexSubstrAnyStep $ olcIndexIntLen $ olcLocalSSF $ olcMaxDerefDepth $ olcReplicationInterval $ olcSockbufMaxIncoming $ olcSockbufMaxIncomingAuth $ olcThreads $ olcToolThreads $ olcWriteTimeout $ olcDbCacheFree $ olcDbCacheSize $ olcDbDNcacheSize $ olcDbIDLcacheSize $ olcDbSearchStack $ olcDbShmKey $ olcSpSessionlog $ mailPreferenceOption ) ) 2.5.13.13 (booleanMatch): matchingRuleUse: ( 2.5.13.13 NAME 'booleanMatch' APPLIES ( hasSubordinates $ olcAddContentAcl $ olcGentleHUP $ olcHidden $ olcLastMod $ olcMirrorMode $ olcMonitoring $ olcReadOnly $ olcReverseLookup $ olcDbChecksum $ olcDbNoSync $ olcDbDirtyRead $ olcDbLinearIndex $ olcSpNoPresent $ olcSpReloadHint ) ) 2.5.13.11 (caseIgnoreListMatch): matchingRuleUse: ( 2.5.13.11 NAME 'caseIgnoreListMatch' APPLIES ( postalAddress $ registeredAddress $ homePostalAddress ) ) 2.5.13.8 (numericStringMatch): matchingRuleUse: ( 2.5.13.8 NAME 'numericStringMatch' APPLIES ( x121Address $ internationaliSDNNumber ) ) 2.5.13.7 (caseExactSubstringsMatch): matchingRuleUse: ( 2.5.13.7 NAME 'caseExactSubstringsMatch' APPLIES ( serialNumber $ destinationIndicator $ dnQualifier ) ) 2.5.13.6 (caseExactOrderingMatch): matchingRuleUse: ( 2.5.13.6 NAME 'caseExactOrderingMatch' APPLIES ( serialNumber $ destinationIndicator $ dnQualifier ) ) 2.5.13.5 (caseExactMatch): matchingRuleUse: ( 2.5.13.5 NAME 'caseExactMatch' APPLIES ( supportedSASLMechanisms $ vendorName $ vendorVersion $ ref $ name $ cn $ uid $ labeledURI $ description $ olcConfigFile $ olcConfigDir $ olcAccess $ olcAllows $ olcArgsFile $ olcAttributeOptions $ olcAttributeTypes $ olcAuthIDRewrite $ olcAuthzPolicy $ olcAuthzRegexp $ olcBackend $ olcDatabase $ olcDisallows $ olcDitContentRules $ olcInclude $ olcLdapSyntaxes $ olcLimits $ olcLogFile $ olcLogLevel $ olcModuleLoad $ olcModulePath $ olcObjectClasses $ olcObjectIdentifier $ olcOverlay $ olcPasswordCryptSaltFormat $ olcPasswordHash $ olcPidFile $ olcPlugin $ olcPluginLogFile $ olcReferral $ olcReplica $ olcReplicaArgsFile $ olcReplicaPidFile $ olcReplogFile $ olcRequires $ olcRestrict $ olcRootDSE $ olcRootPW $ olcSaslAuxprops $ olcSaslHost $ olcSaslRealm $ olcSaslSecProps $ olcSecurity $ olcServerID $ olcSizeLimit $ olcSortVals $ olcSubordinate $ olcSyncrepl $ olcTCPBuffer $ olcTimeLimit $ olcTLSCACertificateFile $ olcTLSCACertificatePath $ olcTLSCertificateFile $ olcTLSCertificateKeyFile $ olcTLSCipherSuite $ olcTLSCRLCheck $ olcTLSCRLFile $ olcTLSRandFile $ olcTLSVerifyClient $ olcTLSDHParamFile $ olcTLSProtocolMin $ olcUpdateRef $ olcDbDirectory $ olcDbCheckpoint $ olcDbCryptFile $ olcDbPageSize $ olcDbIndex $ olcDbLockDetect $ olcDbMode $ olcSpCheckpoint $ knowledgeInformation $ sn $ serialNumber $ c $ l $ st $ street $ o $ ou $ title $ businessCategory $ postalCode $ postOfficeBox $ physicalDeliveryOfficeName $ destinationIndicator $ givenName $ initials $ generationQualifier $ dnQualifier $ houseIdentifier $ dmdName $ pseudonym $ textEncodedORAddress $ info $ drink $ roomNumber $ userClass $ host $ documentIdentifier $ documentTitle $ documentVersion $ documentLocation $ personalTitle $ co $ uniqueIdentifier $ organizationalStatus $ buildingName $ documentPublisher $ carLicense $ departmentNumber $ displayName $ employeeNumber $ employeeType $ preferredLanguage ) ) 2.5.13.4 (caseIgnoreSubstringsMatch): matchingRuleUse: ( 2.5.13.4 NAME 'caseIgnoreSubstringsMatch' APPLIES ( serialNumber $ destinationIndicator $ dnQualifier ) ) 2.5.13.3 (caseIgnoreOrderingMatch): matchingRuleUse: ( 2.5.13.3 NAME 'caseIgnoreOrderingMatch' APPLIES ( serialNumber $ destinationIndicator $ dnQualifier ) ) 2.5.13.2 (caseIgnoreMatch): matchingRuleUse: ( 2.5.13.2 NAME 'caseIgnoreMatch' APPLIES ( supportedSASLMechanisms $ vendorName $ vendorVersion $ ref $ name $ cn $ uid $ labeledURI $ description $ olcConfigFile $ olcConfigDir $ olcAccess $ olcAllows $ olcArgsFile $ olcAttributeOptions $ olcAttributeTypes $ olcAuthIDRewrite $ olcAuthzPolicy $ olcAuthzRegexp $ olcBackend $ olcDatabase $ olcDisallows $ olcDitContentRules $ olcInclude $ olcLdapSyntaxes $ olcLimits $ olcLogFile $ olcLogLevel $ olcModuleLoad $ olcModulePath $ olcObjectClasses $ olcObjectIdentifier $ olcOverlay $ olcPasswordCryptSaltFormat $ olcPasswordHash $ olcPidFile $ olcPlugin $ olcPluginLogFile $ olcReferral $ olcReplica $ olcReplicaArgsFile $ olcReplicaPidFile $ olcReplogFile $ olcRequires $ olcRestrict $ olcRootDSE $ olcRootPW $ olcSaslAuxprops $ olcSaslHost $ olcSaslRealm $ olcSaslSecProps $ olcSecurity $ olcServerID $ olcSizeLimit $ olcSortVals $ olcSubordinate $ olcSyncrepl $ olcTCPBuffer $ olcTimeLimit $ olcTLSCACertificateFile $ olcTLSCACertificatePath $ olcTLSCertificateFile $ olcTLSCertificateKeyFile $ olcTLSCipherSuite $ olcTLSCRLCheck $ olcTLSCRLFile $ olcTLSRandFile $ olcTLSVerifyClient $ olcTLSDHParamFile $ olcTLSProtocolMin $ olcUpdateRef $ olcDbDirectory $ olcDbCheckpoint $ olcDbCryptFile $ olcDbPageSize $ olcDbIndex $ olcDbLockDetect $ olcDbMode $ olcSpCheckpoint $ knowledgeInformation $ sn $ serialNumber $ c $ l $ st $ street $ o $ ou $ title $ businessCategory $ postalCode $ postOfficeBox $ physicalDeliveryOfficeName $ destinationIndicator $ givenName $ initials $ generationQualifier $ dnQualifier $ houseIdentifier $ dmdName $ pseudonym $ textEncodedORAddress $ info $ drink $ roomNumber $ userClass $ host $ documentIdentifier $ documentTitle $ documentVersion $ documentLocation $ personalTitle $ co $ uniqueIdentifier $ organizationalStatus $ buildingName $ documentPublisher $ carLicense $ departmentNumber $ displayName $ employeeNumber $ employeeType $ preferredLanguage ) ) 1.2.36.79672281.1.13.3 (rdnMatch): 2.5.13.1 (distinguishedNameMatch): matchingRuleUse: ( 2.5.13.1 NAME 'distinguishedNameMatch' APPLIES ( creatorsName $ modifiersName $ subschemaSubentry $ entryDN $ namingContexts $ aliasedObjectName $ dynamicSubtrees $ distinguishedName $ seeAlso $ olcDefaultSearchBase $ olcRootDN $ olcSchemaDN $ olcSuffix $ olcUpdateDN $ olcRelay $ member $ owner $ roleOccupant $ manager $ documentAuthor $ secretary $ associatedName $ dITRedirect ) ) 2.5.13.0 (objectIdentifierMatch): matchingRuleUse: ( 2.5.13.0 NAME 'objectIdentifierMatch' APPLIES ( supportedControl $ supportedExtension $ supportedFeatures $ supportedApplicationContext ) ) slapd startup: initiated. backend_startup_one: starting "cn=config" config_back_db_open config_build_entry: "cn=config" config_build_entry: "cn=schema" config_build_entry: "cn={0}core" config_build_entry: "cn={1}cosine" config_build_entry: "cn={2}inetorgperson" config_build_entry: "olcDatabase={-1}frontend" config_build_entry: "olcDatabase={0}config" WARNING: No dynamic config support for database sql. config_build_entry: "olcDatabase={1}sql" backend_startup_one: starting "o=sql,c=RU" ==>backsql_db_open(): testing RDBMS connection backsql_db_open(): concat func not specified (use "concat_pattern" directive in slapd.conf) backsql_db_open(): children search SQL condition not specified (use "children_cond" directive in slapd.conf); preparing default backsql_db_open(): setting "ldap_entries.dn LIKE CONCAT('%,',?)" as default "children_cond" backsql_db_open(): DN match search SQL condition not specified (use "dn_match_cond" directive in slapd.conf); preparing default backsql_db_open(): setting "ldap_entries.dn=?" as default "dn_match_cond" backsql_db_open(): objectclass mapping SQL statement not specified (use "oc_query" directive in slapd.conf) backsql_db_open(): setting "SELECT id,name,keytbl,keycol,create_proc,delete_proc,expect_return FROM ldap_oc_mappings" by default backsql_db_open(): attribute mapping SQL statement not specified (use "at_query" directive in slapd.conf) backsql_db_open(): setting "SELECT name,sel_expr,from_tbls,join_where,add_proc,delete_proc,param_order,expect_return,sel_expr_u FROM ldap_attr_mappings WHERE oc_map_id=?" by default backsql_db_open(): entry deletion SQL statement not specified (use "delentry_stmt" directive in slapd.conf) backsql_db_open(): setting "DELETE FROM ldap_entries WHERE id=?" by default backsql_db_open(): entry deletion SQL statement not specified (use "renentry_stmt" directive in slapd.conf) backsql_db_open(): setting "UPDATE ldap_entries SET dn=?,parent=?,keyval=? WHERE id=?" by default backsql_db_open(): objclasses deletion SQL statement not specified (use "delobjclasses_stmt" directive in slapd.conf) backsql_db_open(): setting "DELETE FROM ldap_entry_objclasses WHERE entry_id=?" by default ==>backsql_get_db_conn() ==>backsql_open_db_handle() <==backsql_open_db_handle() <==backsql_get_db_conn() ==>backsql_load_schema_map() backsql_load_schema_map(): oc_query "SELECT id,name,keytbl,keycol,create_proc,delete_proc,expect_return FROM ldap_oc_mappings" objectClass: id="1" name="inetOrgPerson" keytbl="persons" keycol="id" create_proc="" create_keyval="" delete_proc="" expect_return="0"create_hint="" backsql_load_schema_map(): objectClass "inetOrgPerson": keytbl="persons" keycol="id" expect_return: add=0, del=0; attributes: objectClass: id="2" name="document" keytbl="documents" keycol="id" create_proc="" create_keyval="" delete_proc="" expect_return="0"create_hint="" backsql_load_schema_map(): objectClass "document": keytbl="documents" keycol="id" expect_return: add=0, del=0; attributes: objectClass: id="3" name="organization" keytbl="institutes" keycol="id" create_proc="" create_keyval="" delete_proc="" expect_return="0"create_hint="" backsql_load_schema_map(): objectClass "organization": keytbl="institutes" keycol="id" expect_return: add=0, del=0; attributes: objectClass: id="4" name="referral" keytbl="referrals" keycol="id" create_proc="" create_keyval="" delete_proc="" expect_return="0"create_hint="" backsql_load_schema_map(): objectClass "referral": keytbl="referrals" keycol="id" expect_return: add=0, del=0; attributes: backsql_load_schema_map(): at_query "SELECT name,sel_expr,from_tbls,join_where,add_proc,delete_proc,param_order,expect_return,sel_expr_u FROM ldap_attr_mappings WHERE oc_map_id=?" backsql_oc_get_attr_mapping(): executing at_query "SELECT name,sel_expr,from_tbls,join_where,add_proc,delete_proc,param_order,expect_return,sel_expr_u FROM ldap_attr_mappings WHERE oc_map_id=?" for objectClass "document" with param oc_id="2" attributeType: name="description" sel_expr="documents.abstract" from="documents" join_where="" add_proc="" delete_proc="" sel_expr_u="" backsql_oc_get_attr_mapping(): preconstructed query "SELECT documents.abstract AS description FROM documents WHERE documents.id=? ORDER BY description" attributeType: name="documentTitle" sel_expr="documents.title" from="documents" join_where="" add_proc="" delete_proc="" sel_expr_u="" backsql_oc_get_attr_mapping(): preconstructed query "SELECT documents.title AS documentTitle FROM documents WHERE documents.id=? ORDER BY documentTitle" attributeType: name="documentAuthor" sel_expr="documentAuthor.dn" from="ldap_entries AS documentAuthor,documents,authors_docs,persons" join_where="documentAuthor.keyval=persons.id AND documentAuthor.oc_map_id=1 AND authors_docs.doc_id=documents.id AND aut backsql_oc_get_attr_mapping(): preconstructed query "SELECT documentAuthor.dn AS documentAuthor FROM ldap_entries AS documentAuthor,documents,authors_docs,persons WHERE documents.id=? AND documentAuthor.keyval=persons.id AND documentAuthor.oc_map_id=1 AND authors_docs.doc_id=documents.id AND authors_docs.pers_id=persons.id ORDER BY documentAuthor" attributeType: name="documentIdentifier" sel_expr="concat('document ',documents.id)" from="documents" join_where="documentAuthor.keyval=persons.id AND documentAuthor.oc_map_id=1 AND authors_docs.doc_id=documents.id AND authors_docs.pers_id=persons.id" add backsql_oc_get_attr_mapping(): preconstructed query "SELECT concat('document ',documents.id) AS documentIdentifier FROM documents WHERE documents.id=? ORDER BY documentIdentifier" backsql_load_schema_map("document"): autoadding 'objectClass' and 'ref' mappings backsql_oc_get_attr_mapping(): executing at_query "SELECT name,sel_expr,from_tbls,join_where,add_proc,delete_proc,param_order,expect_return,sel_expr_u FROM ldap_attr_mappings WHERE oc_map_id=?" for objectClass "referral" with param oc_id="4" attributeType: name="ou" sel_expr="referrals.name" from="referrals" join_where="" add_proc="" delete_proc="" sel_expr_u="" backsql_oc_get_attr_mapping(): preconstructed query "SELECT referrals.name AS ou FROM referrals WHERE referrals.id=? ORDER BY ou" attributeType: name="ref" sel_expr="referrals.url" from="referrals" join_where="" add_proc="" delete_proc="" sel_expr_u="" backsql_oc_get_attr_mapping(): preconstructed query "SELECT referrals.url AS ref FROM referrals WHERE referrals.id=? ORDER BY ref" backsql_load_schema_map("referral"): autoadding 'objectClass' and 'ref' mappings backsql_oc_get_attr_mapping(): executing at_query "SELECT name,sel_expr,from_tbls,join_where,add_proc,delete_proc,param_order,expect_return,sel_expr_u FROM ldap_attr_mappings WHERE oc_map_id=?" for objectClass "organization" with param oc_id="3" attributeType: name="o" sel_expr="institutes.name" from="institutes" join_where="" add_proc="" delete_proc="" sel_expr_u="" backsql_oc_get_attr_mapping(): preconstructed query "SELECT institutes.name AS o FROM institutes WHERE institutes.id=? ORDER BY o" attributeType: name="dc" sel_expr="lower(institutes.name)" from="institutes,ldap_entries AS dcObject,ldap_entry_objclasses as auxObjectClass" join_where="institutes.id=dcObject.keyval AND dcObject.oc_map_id=3 AND dcObject.id=auxObjectClass.entry_id AND au backsql_oc_get_attr_mapping(): preconstructed query "SELECT lower(institutes.name) AS dc FROM institutes,ldap_entries AS dcObject,ldap_entry_objclasses AS auxObjectClass WHERE institutes.id=? AND institutes.id=dcObject.keyval AND dcObject.oc_map_id=3 AND dcObject.id=auxObjectClass.entry_id AND auxObjectClass.oc_name='dcObject' ORDER BY dc" backsql_load_schema_map("organization"): autoadding 'objectClass' and 'ref' mappings backsql_oc_get_attr_mapping(): executing at_query "SELECT name,sel_expr,from_tbls,join_where,add_proc,delete_proc,param_order,expect_return,sel_expr_u FROM ldap_attr_mappings WHERE oc_map_id=?" for objectClass "inetOrgPerson" with param oc_id="1" attributeType: name="cn" sel_expr="concat(persons.name,' ',persons.surname)" from="persons" join_where="" add_proc="" delete_proc="" sel_expr_u="" backsql_oc_get_attr_mapping(): preconstructed query "SELECT concat(persons.name,' ',persons.surname) AS cn FROM persons WHERE persons.id=? ORDER BY cn" attributeType: name="telephoneNumber" sel_expr="phones.phone" from="persons,phones" join_where="phones.pers_id=persons.id" add_proc="" delete_proc="" sel_expr_u="" backsql_oc_get_attr_mapping(): preconstructed query "SELECT phones.phone AS telephoneNumber FROM persons,phones WHERE persons.id=? AND phones.pers_id=persons.id ORDER BY telephoneNumber" attributeType: name="givenName" sel_expr="persons.name" from="persons" join_where="phones.pers_id=persons.id" add_proc="" delete_proc="" sel_expr_u="" backsql_oc_get_attr_mapping(): preconstructed query "SELECT persons.name AS givenName FROM persons WHERE persons.id=? ORDER BY givenName" attributeType: name="sn" sel_expr="persons.surname" from="persons" join_where="phones.pers_id=persons.id" add_proc="" delete_proc="" sel_expr_u="" backsql_oc_get_attr_mapping(): preconstructed query "SELECT persons.surname AS sn FROM persons WHERE persons.id=? ORDER BY sn" attributeType: name="userPassword" sel_expr="persons.password" from="persons" join_where="persons.password IS NOT NULL" add_proc="" delete_proc="" sel_expr_u="" backsql_oc_get_attr_mapping(): preconstructed query "SELECT persons.password AS userPassword FROM persons WHERE persons.id=? AND persons.password IS NOT NULL ORDER BY userPassword" attributeType: name="seeAlso" sel_expr="seeAlso.dn" from="ldap_entries AS seeAlso,documents,authors_docs,persons" join_where="seeAlso.keyval=documents.id AND seeAlso.oc_map_id=2 AND authors_docs.doc_id=documents.id AND authors_docs.pers_id=persons.id" add backsql_oc_get_attr_mapping(): preconstructed query "SELECT seeAlso.dn AS seeAlso FROM ldap_entries AS seeAlso,documents,authors_docs,persons WHERE persons.id=? AND seeAlso.keyval=documents.id AND seeAlso.oc_map_id=2 AND authors_docs.doc_id=documents.id AND authors_docs.pers_id=persons.id ORDER BY seeAlso" attributeType: name="userCertificate" sel_expr="certs.cert" from="persons,certs" join_where="certs.pers_id=persons.id" add_proc="" delete_proc="" sel_expr_u="" backsql_oc_get_attr_mapping(): preconstructed query "SELECT certs.cert AS userCertificate FROM persons,certs WHERE persons.id=? AND certs.pers_id=persons.id ORDER BY userCertificate" backsql_load_schema_map("inetOrgPerson"): autoadding 'objectClass' and 'ref' mappings <==backsql_load_schema_map() ==>backsql_free_db_conn() ==>backsql_close_db_handle(0x932e428) <==backsql_close_db_handle(0x932e428) <==backsql_free_db_conn() <==backsql_db_open(): test succeeded, schema map loaded slapd starting ........ and slapd never start -.- I don't know where the mistake is... I checked the configuration files slapd.conf, odbc.ini, odbcinst.ini and I can't find the mistake, please help me =) here we have the configuration files +++++slapd.conf+++++++ # $OpenLDAP: /servers/slapd/back-sql/rdbms_depend/mysql/slapd.conf,v 1.5.2.1 2005/01/20 18:04:03 kurt Exp $ # # 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 # 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/run/slapd.pid argsfile /usr/local/var/run/slapd.args ####################################################################### # sql database definitions ####################################################################### database sql suffix "o=sql,c=RU" rootdn "cn=root,o=sql,c=RU" rootpw {SSHA}J3tV8vA0ouDU6LfnaPraZDPebsQdIrqe dbname example dbuser root dbpasswd admin subtree_cond "ldap_entries.dn LIKE CONCAT('%',?)" insentry_stmt "INSERT INTO ldap_entries (dn,oc_map_id,parent,keyval) VALUES (?,?,?,?)" has_ldapinfo_dn_ru no +++++++odbc.ini+++++++ [example] Description = Example for OpenLDAP's back-sql Driver = MySQL #Trace = No Database = example Server = localhost Port = 3306 Socket = /var/lib/mysql/mysql.sock User = root Password = admin #ReadOnly = No #RowVersioning = No #ShowSystemTables = No #ShowOidColumn = No #FakeOidIndex = No #ConnSettings = +++++++odbcinst.ini++++++++ # Example driver definitinions # # # Included in the unixODBC package [PostgreSQL] Description = ODBC for PostgreSQL Driver = /usr/lib/libodbcpsql.so Setup = /usr/lib/libodbcpsqlS.so FileUsage = 1 # Driver from the MyODBC package # Setup from the unixODBC package #[MySQL] #Description = ODBC for MySQL #Driver = /usr/lib/libmyodbc.so #Setup = /usr/lib/libodbcmyS.so #FileUsage = 1 [MySQL] Description = ODBC for MySQL Driver = /usr/lib/libmyodbc3.so Setup = /usr/lib/libodbcmyS.so FileUsage = 1 +++++++++++++++++++++++++++++++++++++++++++++++ thanks for your attention :)

1 0

Re: (ITS#6395) Web site release readme needs BDB version compatibility update
by quanah＠zimbra.com 24 Nov '09

24 Nov '09

--On Monday, November 23, 2009 5:39 AM +0000 battery(a)writeme.com wrote: > Full_Name: Matt Kassawara > Version: 2.4.18 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (24.56.179.224) > > > The release readme posted on the OpenLDAP web site doesn't explicitly > indicate compatibility with BDB 4.8. > > http://www.openldap.org/software/release/readme.html This will be addressed automatically when 2.4.20 is released, as this was fixed a while ago in CVS. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6399) Documentation error for "referral" result code 10
by hyc＠symas.com 24 Nov '09

24 Nov '09

chris.czub(a)gmail.com wrote: > Full_Name: Chris Czub > Version: 2.4 > OS: CentOS > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (208.82.64.120) > > > http://www.openldap.org/doc/admin24/appendix-ldap-result-codes.html#{{refer… > > The referral section refers to section 4.1.10, which is non-existent in the > documentation. This appendix is apparently a copy/paste from RFC4511; this then seems to be a reference to 4.1.10 in that RFC. -- -- 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#6400) Different-sized CSNs confuse accesslog
by h.b.furuseth＠usit.uio.no 23 Nov '09

23 Nov '09

Full_Name: Hallvard B Furuseth Version: OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard Given CSNs of different lengths, overlays/accesslog.c:log_old_lookup() remembers truncated versions of the longer CSNs as "max CSN". The remembered length shrinks but never grows as CSNs change. I think the test if ( len > pd->csn.bv_len ) len = pd->csn.bv_len; should be if ( len > LDAP_PVT_CSNSTR_BUFSIZE ) len = LDAP_PVT_CSNSTR_BUFSIZE; since as far as I can tell pd->csn.bv_val is always csnbuf from accesslog_purge(). The compare just below must be fixed to match. It is buggy now anyway, CSNs of different lengths can compare equal.

1 0

Re: (ITS#6398) quiet valgrind (tool -F parsing)
by h.b.furuseth＠usit.uio.no 23 Nov '09

23 Nov '09

richton(a)nbcs.rutgers.edu writes: > Quiets a valgrind "definitely lost" leak complaint. > I submit this patch as public domain. Thanks. Fixed in HEAD. -- Hallvard

1 0

Re: (ITS#6397) accesslog + syncprov crash
by h.b.furuseth＠usit.uio.no 23 Nov '09

23 Nov '09

Poking a bit more in the backtrace (with a new coredump, sorry) shows that the filter given to test_filter() is NULL because *ss = { s_base = {bv_len = 6, bv_val = 0x1f94c5a0 "cn=log"}, s_eid = 1, s_op = 0x1f948310 { o_hdr = 0x1f948480 {all nulls}, o_controls = 0x1f9485c8 [(void *) 0x0]}, s_rid = 1, s_sid = -1, s_flags = 1, s_inuse = 1, <fields with null values omitted> } in frame 1, syncprov_matchops (op=0x42ec6690, opc=0x1f958ca0, saveit=1) at syncprov.c:1304: rc = test_filter( &op2, e, ss->s_op->ors_filter ); I have ss == si->si_ops != sm->sm_op. *si = { si_ops = 0x1f951c20, si_ctxcsn = 0x1f74fa70, si_contextdn = {bv_len = 6, bv_val = 0x1f4e4310 "cn=log"}, si_sids = 0x1f74fae0 [0], si_numcsns = 1, si_numops = 49, si_nopres = 1, si_usehint = 1, si_mods = 0x1fa615b0 {avl_data = 0x1fa61d20}, si_ops_mutex = { __data = {__lock = 1, __owner = 26790, __nusers = 1}, __size = "\001\000\000\000\000\000\000\000\246h\000\000\001", '\0' <repeats 26 times>, __align = 1}} Following si->si_mods: sml_mod.sm_type is garbage, is that relevant? *((modtarget *) si->si_mods->avl_data)->mt_mods->mi_op = { o_hdr = 0x42ec6800, o_tag = 102 <LDAP_REQ_MODIFY>, o_time = 1259003422, o_tincr = 0, o_bd = 0x42ec62d0, o_req_dn = {bv_len = 6, bv_val = 0x1f4e4400 "cn=log"}, o_req_ndn = {bv_len = 6, bv_val = 0x1f4e4310 "cn=log"}, o_request.oq_modify = { rs_mods = { rs_modlist = 0x42ec64c0 { sml_mod = { sm_desc = 0x1f4a46e0 <entryCSN>, sm_values = 0x42ec6500 &[ {bv_len = 40, bv_val = 0x42ec6530 "20091123191016.381756Z#000000#000#000000\311_\214\031="}, BER_BVNULL], sm_numvals = 1, sm_op = 2, sm_flags = 1, sm_type = {bv_len = 4222451713, bv_val = 0x42ec6680 ""}}}, rs_no_opattrs = 1 '\001'}}, o_no_schema_check = 1 '\001', o_ctrlflag = '\0' <repeats 14 times>, "\002", '\0' <repeats 16 times>, o_controls = 0x42ec6948 &[(void *) 0x0], o_authz = { sai_dn = {bv_len = 28, bv_val = 0x1f4e46f0 "cn=Manager,dc=example,dc=com"}, sai_ndn = {bv_len = 28, bv_val = 0x1f4e4d90 "cn=manager,dc=example,dc=com"}}, o_callback = 0x1f958c80, o_csn = {bv_len = 40, bv_val = 0x42ec6530 "20091123191016.381756Z#000000#000#000000\311_\214\031="}, o_extra = {slh_first = 0x1f958d28}} (gdb) backtrace #0 0x0000000000452066 in test_filter (op=0x42ec5bf0, e=0x1f577e48, f=0x0) at filterentry.c:69 #1 0x0000000000529cd1 in syncprov_matchops (op=0x42ec6690, opc=0x1f958ca0, saveit=1) at syncprov.c:1304 #2 0x000000000052c524 in syncprov_op_mod (op=0x42ec6690, rs=0x42ec6620) at syncprov.c:2064 #3 0x00000000004b3f0f in overlay_op_walk (op=0x42ec6690, rs=0x42ec6620, which=op_modify, oi=0x1f4e47e0, on=0x1f4e49c0) at backover.c:659 #4 0x00000000004b41a1 in over_op_func (op=0x42ec6690, rs=0x42ec6620, which=op_modify) at backover.c:721 #5 0x00000000004b42b7 in over_op_modify (op=0x42ec6690, rs=0x42ec6620) at backover.c:760 #6 0x0000000000521c67 in accesslog_purge (ctx=0x42ec6d60, arg=0x1f4e4760) at accesslog.c:699 #7 0x00000000005478ed in ldap_int_thread_pool_wrapper (xpool=0x1f4ae8a0) at tpool.c:685 #8 0x0000003d1a4064a7 in start_thread () from /lib64/libpthread.so.0 #9 0x0000003d198d3c2d in clone () from /lib64/libc.so.6 -- Hallvard

1 0

(ITS#6399) Documentation error for "referral" result code 10
by chris.czub＠gmail.com 23 Nov '09

23 Nov '09

Full_Name: Chris Czub Version: 2.4 OS: CentOS URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (208.82.64.120) http://www.openldap.org/doc/admin24/appendix-ldap-result-codes.html#{{refer… The referral section refers to section 4.1.10, which is non-existent in the documentation.

1 0

Re: (ITS#6396) slow reads on slaves after many changes in master
by quanah＠zimbra.com 23 Nov '09

23 Nov '09

--On Monday, November 23, 2009 8:38 PM +0200 rolnas(a)gmail.com wrote: > I raised (twice) to: > > cachesize 20000 > idlcachesize 100000 Ok, make sure dncachesize is set to zero as well. ;) > BDB software is 4.6.21.4 (from FreeBSD ports as OpenLDAP itself). > > I have no time (sorry) to try compile and run current CVS version. Well, as I said, there are a number of known problems with the entry cache in 2.4.19 which are fixed in CVS. So when you find the time, I'd suggest building the CVS version and using it instead. If it still occurs there, the developers will probably want additional information. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6396) slow reads on slaves after many changes in master
by rolnas＠gmail.com 23 Nov '09

23 Nov '09

On 2009.11.23, at 20:12, Quanah Gibson-Mount wrote: > --On Monday, November 23, 2009 8:09 PM +0200 rolnas(a)gmail.com wrote: >=20 >> P.S. I found myself cachesize < total number of entries. Probably I >> lowered it trying to workaround this problem. >=20 > Yes, please raise it. Also, please try the current CVS as I noted. = Also, what BDB version of software are you using? I raised (twice) to: cachesize 20000 idlcachesize 100000 but it didn't help. My test (ldapsearch of entire DB) usually takes ~2s, after changes (the = same sequence of deletes/adds) - ~18s on master, ~60s on mirror, ~140s = on slave. After restart, again ~2s. BDB software is 4.6.21.4 (from FreeBSD ports as OpenLDAP itself). I have no time (sorry) to try compile and run current CVS version. Regards, Rolandas Naujikas > Thanks! >=20 > --Quanah >=20 > -- >=20 > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6396) slow reads on slaves after many changes in master
by quanah＠zimbra.com 23 Nov '09

23 Nov '09

--On Monday, November 23, 2009 8:09 PM +0200 rolnas(a)gmail.com wrote: > P.S. I found myself cachesize < total number of entries. Probably I > lowered it trying to workaround this problem. Yes, please raise it. Also, please try the current CVS as I noted. Also, what BDB version of software are you using? Thanks! --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6398) quiet valgrind (tool -F parsing)
by richton＠nbcs.rutgers.edu 23 Nov '09

23 Nov '09

Full_Name: Aaron Richton Version: HEAD OS: irrelevant URL: Submission from: (NULL) (128.6.31.135) Quiets a valgrind "definitely lost" leak complaint. I submit this patch as public domain. --- slapcommon.c~ 2009-11-23 11:22:05.000000000 -0500 +++ slapcommon.c 2009-11-23 11:22:37.000000000 -0500 @@ -763,6 +763,11 @@ conffile = NULL; } + if ( confdir != NULL ) { + ch_free( confdir ); + confdir = NULL; + } + if ( ldiffile != NULL ) { ch_free( ldiffile ); ldiffile = NULL;

1 0

Re: (ITS#6396) slow reads on slaves after many changes in master
by rolnas＠gmail.com 23 Nov '09

23 Nov '09

> ... > Can you reproduce this behavior with current CVS checkout of the = OPENLDAP_REL_ENG_2_4 branch? I'll note that the entry cache has been = broken for most of RE2.4, and it is specifically fixed in CVS and will = be in the upcoming 2.4.20 release. >=20 > You fail to note in this ITS any of the following information, which = would be useful: Sorry, It was my first submission. > (a) Total number of entries in the database ~15000 (14738) >=20 >> =46rom slapd.conf/cn=3Dconfig: > (b) cachesize 10000 > (c) idlcachesize 50000 > (d) dncachesize Not set, I found somewhere to better don't touch it. >> =46rom the BDB database: >=20 > (e) output of du -c -h *.bdb in the database directory 448K associatedDomain.bdb 288K carLicense.bdb 7.9M cn.bdb 7.1M displayName.bdb 4.4M dn2id.bdb 320K employeeNumber.bdb 528K entryCSN.bdb 544K entryUUID.bdb 464K gidNumber.bdb 3.1M givenName.bdb 30M id2entry.bdb 52K ipHostNumber.bdb 8.0K ipNetworkNumber.bdb 8.0K krb5PrincipalName.bdb 44K macAddress.bdb 336K mail.bdb 120K member.bdb 132K memberUid.bdb 1.3M objectClass.bdb 16K ou.bdb 8.0K sambaDomainName.bdb 60K sambaGroupType.bdb 336K sambaPrimaryGroupSID.bdb 11M sambaSID.bdb 3.7M sn.bdb 20K st.bdb 3.7M uid.bdb 304K uidNumber.bdb 75M total > (f) Contents of your DB_CONFIG file # 100MB cache set_cachesize 0 104857600 1 # 1MB cache for tables and index file names set_lg_regionmax 1048576 # 10MB log files (> 4*set_lg_bsize) set_lg_max 10485760 # 2MB memory cache for log files set_lg_bsize 2097152 # autoremove old log files set_flags DB_LOG_AUTOREMOVE I want add more to this info, if it is relevant: checkpoint 10240 5 cachefree 1000 overlay syncprov syncprov-checkpoint 1000 5 syncprov-sessionlog 10000 Regards, Rolandas Naujikas P.S. I found myself cachesize < total number of entries. Probably I = lowered it trying to workaround this problem. > Thanks, > Quanah >=20 > -- >=20 > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6396) slow reads on slaves after many changes in master
by quanah＠zimbra.com 23 Nov '09

23 Nov '09

--On Monday, November 23, 2009 9:02 AM +0000 rolnas(a)gmail.com wrote: > Full_Name: Rolandas Naujikas > Version: 2.4.19 > OS: FreeBSD 7.1 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (217.147.36.211) > > > We have a setup of 3 slapd: 2 of them running in mirror mode and last one > as a read-only slave. All entries could fit in the cache (my goal is good > read performance). > > Usually when master receive only small changes (modify + several adds) - > read performance is OK. > > When I do ~5% content change (doing a lot of deletes and adds in short > period), then read performance drops sharply - on master not so much > (2x), on slaves 10-20x. In the same time CPU load on slaves when doing > read is becoming high (almost 100%), on master - normal. > > It rests in such situation until I restart slave instances, after that > all such performance problems disappears. > > By comparison version 2.4.16 didn't show such behavior and for some time > (until 2.4.19 was not declared stable) we used this older version. > Can you reproduce this behavior with current CVS checkout of the OPENLDAP_REL_ENG_2_4 branch? I'll note that the entry cache has been broken for most of RE2.4, and it is specifically fixed in CVS and will be in the upcoming 2.4.20 release. You fail to note in this ITS any of the following information, which would be useful: (a) Total number of entries in the database >From slapd.conf/cn=config: (b) cachesize (c) idlcachesize (d) dncachesize >From the BDB database: (e) output of du -c -h *.bdb in the database directory (f) Contents of your DB_CONFIG file Thanks, Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6397) accesslog + syncprov crash
by h.b.furuseth＠usit.uio.no 23 Nov '09

23 Nov '09

Full_Name: Hallvard B Furuseth Version: HEAD, RE24 OS: Linux URL: ftp://ftp.openldap.org/incoming/Hallvard-Furuseth-091123.tgz Submission from: (NULL) (129.240.6.233) Submitted by: hallvard slapd dumps core in test043-delta-syncrepl with this patch to excite accesslog. While I didn't expect good behavior with that change, I didn't expect a coredump either. --- tests/data/slapd-deltasync-master.conf~ 2009-04-06 17:26:37 +0200 +++ tests/data/slapd-deltasync-master.conf 2009-11-23 15:09:56 +0100 @@ -40,4 +40,5 @@ directory @TESTDIR@/db.1.b rootdn "cn=Manager,dc=example,dc=com" +index reqStart eq #bdb#index objectClass eq #bdb#index entryUUID,entryCSN eq @@ -78,4 +79,5 @@ logops writes logsuccess true +logpurge 00:00:05 00:00:03 #monitor#database monitor Happens ca every 2nd test043 run with RE24 --enable-accesslog. Output with backtrace and testrun/ attached.

1 0

(ITS#6396) slow reads on slaves after many changes in master
by rolnas＠gmail.com 23 Nov '09

23 Nov '09

Full_Name: Rolandas Naujikas Version: 2.4.19 OS: FreeBSD 7.1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (217.147.36.211) We have a setup of 3 slapd: 2 of them running in mirror mode and last one as a read-only slave. All entries could fit in the cache (my goal is good read performance). Usually when master receive only small changes (modify + several adds) - read performance is OK. When I do ~5% content change (doing a lot of deletes and adds in short period), then read performance drops sharply - on master not so much (2x), on slaves 10-20x. In the same time CPU load on slaves when doing read is becoming high (almost 100%), on master - normal. It rests in such situation until I restart slave instances, after that all such performance problems disappears. By comparison version 2.4.16 didn't show such behavior and for some time (until 2.4.19 was not declared stable) we used this older version.

1 0

Re: (ITS#6390) test020 seg faults
by rhafer＠suse.de 23 Nov '09

23 Nov '09

Am Freitag 20 November 2009 19:45:53 schrieb quanah(a)zimbra.com: > --On Friday, November 20, 2009 3:53 PM +0000 quanah(a)zimbra.com wrote: > > --On Friday, November 20, 2009 12:35 PM +0000 rhafer(a)suse.de wrote: > >> Hm, I get the following warning during the make run: > >> > >> =2E./../../servers/slapd/syncrepl.c:2861 is: > >> comma =3D ber_bvrchr( &ptr, ',' ); > >> with ber_bvrchr being a macro around memrchr(). So it seems that > >> memrchr() = is=20 > >> undefined in syncrepl.c. > > > > Please don't add secondary issues to an ITS. File a new one. > > Unless you're saying that is the issue, which isn't clear to me in what you > wrote. :P I thought sending my mails against this ITS would be sufficient to show that I am talking about this issue :). I'll try to make that a bit more obvious next time. -- regards, Ralf

1 0

(ITS#6395) Web site release readme needs BDB version compatibility update
by battery＠writeme.com 23 Nov '09

23 Nov '09

Full_Name: Matt Kassawara Version: 2.4.18 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (24.56.179.224) The release readme posted on the OpenLDAP web site doesn't explicitly indicate compatibility with BDB 4.8. http://www.openldap.org/software/release/readme.html

1 0

Re: (ITS#6300) Add kqueue support to slapd
by hyc＠symas.com 23 Nov '09

23 Nov '09

bduncan(a)apple.com wrote: > On Sep 22, 2009, at 1:02 PM, Quanah Gibson-Mount wrote: > >> --On Tuesday, September 22, 2009 7:23 PM +0000 bduncan(a)apple.com >> wrote: >> >>> Subject should have been: "PATCH - Added kqueue support to slapd" to >>> make clear this ITS tracks a patch that has been submitted. >> >> What OS(es) has this kqueue support been tested with? For example, >> the last time I looked at kqueue on OSX 10.5, it was very marginal, >> and missing most of the important pieces, which meant it wouldn't >> work for OpenLDAP or Postfix, etc. > > It was tested on OS X 10.6. Should work on all BSDs; nothing OSX- > specific about the kqueue usage in the patch. As far as kqueue > support in OS X 10.5, from what I see, most everything is there. > Certainly all of the kqueue features in this patch are supported in OS > X 10.5. To expand on this: there are a lot of comments around the web that kqueue was fairly broken at least up to 10.5. E.g. this: http://lists.schmorp.de/pipermail/libev/2008q4/000523.html Since we also use a pipe for the wake_sds[] in our event loop, if kqueue only supports sockets, then it cannot be used reliably in slapd. -- -- 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#6392) olcAuthIDRewrite handler exited with 1
by masarati＠aero.polimi.it 22 Nov '09

22 Nov '09

> Yeah, I noticed that hyc had patched it differently. There is > definitely a steep learning curve when it comes to helping out with > anything. > I see hyc's patch committed in the latest RE24. I have tested it with > HEAD and the error message seems to be gone. > I can't seem to get olcAuthIDRewrite to work -- but that's probably not > an ITS problem. =) Probably, yes. authzid-rewrite is used much like authz-regexp, only with a slightly different syntax. Actually, when rewriting is available, authz-regexp is handled by authzid-rewrite, using a subset of its syntax (and thus of its semantics). So its use applies when authz-regexp is appropriate. See slapd.conf(5) for usage of authz-regexp. p.

1 0

Re: (ITS#6391) missing check for broken filters
by h.b.furuseth＠usit.uio.no 22 Nov '09

22 Nov '09

masarati(a)aero.polimi.it writes: > Are you going to fix this? Probably not. -- Hallvard

1 0

Re: (ITS#6391) missing check for broken filters
by masarati＠aero.polimi.it 22 Nov '09

22 Nov '09

> syncrepl.c and overlays/pcache.c call str2filter() and str2filter_x() > without checking for success. > > (so does retcode, but that overlay is only for testing anyway.) Are you going to fix this? I can take care of it later, in case. p.

1 0

Re: (ITS#6394) syncrepl accepts rid>999 then assumes rid<=999
by hyc＠symas.com 22 Nov '09

22 Nov '09

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD, RE24 > OS: > URL: > Submission from: (NULL) (129.240.6.233) > Submitted by: hallvard > > > syncrepl accepts rid values in range [0, SLAP_SYNC_SID_MAX(4095)], but > proceeds to assume the rid is in range [0, SLAP_SYNC_RID_MAX (999)]. > This can produce buffer overruns for such rids. > > slapd.conf(5) says max rid = 4095, since ITS#5108. > > Possible fixes: either to revert to a limit of 999, or expand to 4 > digits to support the documented behavior, or to make them hex to keep > the documented limit but still max 3 digits. I've opted to revert to 999. The previous behavior was completely broken anyway; aside from the syncrepl config parser all of the rest of the infrastructure was still treating rids as 3 decimal digits: the config unparser, slapd-config(5), slap_compose_sync_cookie, slap_parse_sync_cookie, etc. etc... All of these would have had to change to hex to make the 4095 limit work, and they weren't. Also, for backward compatibility with 2.3, they can't. -- -- 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#6394) syncrepl accepts rid>999 then assumes rid<=999
by h.b.furuseth＠usit.uio.no 21 Nov '09

21 Nov '09

Full_Name: Hallvard B Furuseth Version: HEAD, RE24 OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard syncrepl accepts rid values in range [0, SLAP_SYNC_SID_MAX(4095)], but proceeds to assume the rid is in range [0, SLAP_SYNC_RID_MAX (999)]. This can produce buffer overruns for such rids. slapd.conf(5) says max rid = 4095, since ITS#5108. Possible fixes: either to revert to a limit of 999, or expand to 4 digits to support the documented behavior, or to make them hex to keep the documented limit but still max 3 digits.

1 0

Re: (ITS#6393) test045-syncreplication-proxied for bdb: ldapsearch failed at slave (32)!
by hyc＠symas.com 21 Nov '09

21 Nov '09

michael(a)stroeder.com wrote: > michael(a)stroeder.com wrote: >> quanah(a)zimbra.com wrote: >>> --On Saturday, November 21, 2009 1:20 PM +0000 michael(a)stroeder.com wrote: >>> >>>> Full_Name: Michael Str?der >>>> Version: HEAD >>>> OS: openSUSE Linux 11.2 (x86_64) >>>> URL: >>>> Submission from: (NULL) (84.163.70.93) >>> As I noted yesterday, constant changes were ongoing in HEAD. >>> >>> Please re-sync your sources and try now, I think Howard's done with what he >>> was doing. >> >> My regular test process is as follows: > > Also note that this ITS is for HEAD not RE24. Thanks, got it. A prior patch to syncrepl.c broke this, testing a fix now. -- -- 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#6393) test045-syncreplication-proxied for bdb: ldapsearch failed at slave (32)!
by michael＠stroeder.com 21 Nov '09

21 Nov '09

michael(a)stroeder.com wrote: > quanah(a)zimbra.com wrote: >> --On Saturday, November 21, 2009 1:20 PM +0000 michael(a)stroeder.com wrote: >> >>> Full_Name: Michael Str?der >>> Version: HEAD >>> OS: openSUSE Linux 11.2 (x86_64) >>> URL: >>> Submission from: (NULL) (84.163.70.93) >> As I noted yesterday, constant changes were ongoing in HEAD. >> >> Please re-sync your sources and try now, I think Howard's done with what he >> was doing. > > My regular test process is as follows: Also note that this ITS is for HEAD not RE24. Ciao, Michael.

1 0

Re: (ITS#6393) test045-syncreplication-proxied for bdb: ldapsearch failed at slave (32)!
by michael＠stroeder.com 21 Nov '09

21 Nov '09

quanah(a)zimbra.com wrote: > --On Saturday, November 21, 2009 1:20 PM +0000 michael(a)stroeder.com wrote: > >> Full_Name: Michael Str?der >> Version: HEAD >> OS: openSUSE Linux 11.2 (x86_64) >> URL: >> Submission from: (NULL) (84.163.70.93) > > As I noted yesterday, constant changes were ongoing in HEAD. > > Please re-sync your sources and try now, I think Howard's done with what he > was doing. My regular test process is as follows: 1. Whenever I test I do "cvs up" right before running the build. (And so I did after your message.) 2. Run build script and make test. 3. If anything fails during "make test" I do a "cvs up" once again and watch for changes. If there were changes I return to step 2. 4. If there were no changes I write an ITS. No more changes were present when doing "cvs up" *now*. Ciao, Michael.

1 0

Re: (ITS#6392) olcAuthIDRewrite handler exited with 1
by wgillespie＠es2eng.com 21 Nov '09

21 Nov '09

Yeah, I noticed that hyc had patched it differently. There is definitely a steep learning curve when it comes to helping out with anything. I see hyc's patch committed in the latest RE24. I have tested it with HEAD and the error message seems to be gone. I can't seem to get olcAuthIDRewrite to work -- but that's probably not an ITS problem. =) Thanks for all the help!

1 0

Re: (ITS#6392) olcAuthIDRewrite handler exited with 1
by quanah＠zimbra.com 21 Nov '09

21 Nov '09

--On Saturday, November 21, 2009 10:15 AM -0800 Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > --On Saturday, November 21, 2009 3:22 AM +0000 wgillespie(a)es2eng.com > wrote: > >> Full_Name: Willie Gillespie >> Version: 2.4.X (from CVS) >> OS: Ubuntu 9.10 x64 >> URL: >> Submission from: (NULL) (208.47.173.116) > > Please update your CVS RE24 checkout and test. Also, please be sure your patches aren't present. ;) They were not the correct solution to the issue. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6393) test045-syncreplication-proxied for bdb: ldapsearch failed at slave (32)!
by quanah＠zimbra.com 21 Nov '09

21 Nov '09

--On Saturday, November 21, 2009 1:20 PM +0000 michael(a)stroeder.com wrote: > Full_Name: Michael Str?der > Version: HEAD > OS: openSUSE Linux 11.2 (x86_64) > URL: > Submission from: (NULL) (84.163.70.93) As I noted yesterday, constant changes were ongoing in HEAD. Please re-sync your sources and try now, I think Howard's done with what he was doing. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6392) olcAuthIDRewrite handler exited with 1
by quanah＠zimbra.com 21 Nov '09

21 Nov '09

--On Saturday, November 21, 2009 3:22 AM +0000 wgillespie(a)es2eng.com wrote: > Full_Name: Willie Gillespie > Version: 2.4.X (from CVS) > OS: Ubuntu 9.10 x64 > URL: > Submission from: (NULL) (208.47.173.116) Please update your CVS RE24 checkout and test. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6393) test045-syncreplication-proxied for bdb: ldapsearch failed at slave (32)!
by michael＠stroeder.com 21 Nov '09

21 Nov '09

Full_Name: Michael Ströder Version: HEAD OS: openSUSE Linux 11.2 (x86_64) URL: Submission from: (NULL) (84.163.70.93) Running ./scripts/test045-syncreplication-proxied for bdb... running defines.sh Starting master slapd on TCP/IP port 9011... Using ldapsearch to check that master slapd is running... Using ldapadd to create the context prefix entry in the master... Starting slave slapd on TCP/IP port 9012... Using ldapsearch to check that slave slapd is running... Starting proxy slapd on TCP/IP port 9013... Using ldapsearch to check that proxy slapd is running... 1 > Using ldapadd to populate the master directory... Waiting 7 seconds for syncrepl to receive changes... Waiting 7 seconds for syncrepl to receive changes... Waiting 7 seconds for syncrepl to receive changes... 1 < Comparing retrieved entries from master and slave... 2 > Stopping the provider, sleeping 15 seconds and restarting it... Using ldapsearch to check that master slapd is running... Using ldapmodify to modify master directory... Waiting 7 seconds for syncrepl to receive changes... ldapsearch failed at slave (32)!

1 0

Re: (ITS#6390) test020 seg faults
by michael＠stroeder.com 21 Nov '09

21 Nov '09

quanah(a)zimbra.com wrote: > --On Friday, November 20, 2009 11:29 PM +0000 michael(a)stroeder.com wrote: > >> I think this is the right issue since Howard wrote to me: >>> Your source seems to be corrupt or out of date. There is no call to >>> memrchr anywhere near line 2889 in syncrepl.c > > > This has been fixed in RE24, please try now. :) Seems to be ok now (100 test runs) Ciao, Michael.

1 0

Re: (ITS#6392)
by hyc＠symas.com 21 Nov '09

21 Nov '09

wgillespie(a)es2eng.com wrote: > I tracked down the bug by going through the source code. > Any way I can help with any of this? It's already been fixed in CVS, a few hours ago. -- -- 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#6392)
by wgillespie＠es2eng.com 21 Nov '09

21 Nov '09

This is a multi-part message in MIME format. --------------040503050400050604020005 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Okay, so apparently it was a little easier to code than I anticipated. The supplied patch removes the error message I was seeing. Whether or not authid-rewrite actually works is a different question which I have yet to figure out. The second patch (for config.c) isn't directly related to this bug, but would be nice. I've never done a patch before, so I have no idea if I created these correctly. I used the command: diff -c oldfile newfile > file.diff Is this the proper way to do that? --------------040503050400050604020005 Content-Type: text/x-patch; name="config.c.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="config.c.diff" *** config.c 2009-01-21 17:00:58.000000000 -0700 --- config.c.new 2009-11-21 00:56:08.000000000 -0700 *************** *** 288,294 **** } else { Debug( LDAP_DEBUG_ANY, "[%s:%d] unknown command '%s'\n", ! fname, lineno, "" ); return -1; } --- 288,294 ---- } else { Debug( LDAP_DEBUG_ANY, "[%s:%d] unknown command '%s'\n", ! fname, lineno, argv[0] ); return -1; } --------------040503050400050604020005 Content-Type: text/x-patch; name="saslauthz.c.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="saslauthz.c.diff" *** saslauthz.c 2009-01-21 17:01:03.000000000 -0700 --- saslauthz.c.new 2009-11-21 00:52:15.000000000 -0700 *************** *** 1284,1289 **** --- 1284,1290 ---- ) { int rc; + int i; char *savearg0; /* init at first call */ *************** *** 1291,1300 **** sasl_rwinfo = rewrite_info_init( REWRITE_MODE_USE_DEFAULT ); } - /* strip "authid-" prefix for parsing */ savearg0 = argv[0]; argv[0] += STRLENOF( "authid-" ); rc = rewrite_parse( sasl_rwinfo, fname, lineno, argc, argv ); argv[0] = savearg0; return rc; --- 1292,1310 ---- sasl_rwinfo = rewrite_info_init( REWRITE_MODE_USE_DEFAULT ); } savearg0 = argv[0]; + /* temporarily shift argv to get rid of argv[0] */ + for ( i = 1; i <= argc; i++ ) { + argv[i-1] = argv[i]; + } + argc--; + /* strip "authid-" prefix for parsing */ argv[0] += STRLENOF( "authid-" ); rc = rewrite_parse( sasl_rwinfo, fname, lineno, argc, argv ); + argc++; + for ( i = argc; i >= 1; i-- ) { + argv[i] = argv[i-1]; + } argv[0] = savearg0; return rc; --------------040503050400050604020005--

1 0

(ITS#6392)
by wgillespie＠es2eng.com 21 Nov '09

21 Nov '09

I tracked down the bug by going through the source code. Basically, slap_sasl_rewrite_config() in servers/slapd/saslauthz.c passes the information to rewrite_parse() in libraries/librewrite/config.c. However, what slap_sasl_rewrite_config() sends is NOT what rewrite_parse() expects to get. It looks like rewrite_parse is a generic function which is called all over the place. Probably not best to mess with that. However, slap_sasl_rewrite_config() is only called from servers/slapd/bconfig.c, so any changes could take place in either of those two places relatively easily. Anyway, what slap_sasl_rewrite_config has in my little test: fname = "slapd" lineno = 0 argc = 3 argv[0] = "olcAuthIDRewrite" argv[1] = "authid-rewriteEngine" argv[2] = "on" In rewrite_parse(), it expects it to be set up more like this: fname = "slapd" lineno = 0 argc = 2 argv[0] = "rewriteEngine" argv[1] = "on" So all that needs to happen in slap_sasl_rewrite_config() is: argc--; and Get rid of argv[0] and shift everything down in the array (1 ==> 0, 2 ==> 1, etc.) (?and then put it all back when finished?) Anyway, I'm not sure how to do that, so the most I can really help out here is by filing this report so you don't have to spend your time tracking down the issue. Second note: it would have helped with debugging had a particular debug command been properly finished. See libraries/librewrite/config.c, line 289-291. The debug command has the %s placeholder for the third argument, but is passed "" instead of something more useful like: argv[0]. Probably just a little oversight. Any way I can help with any of this?

1 0

(ITS#6392) olcAuthIDRewrite handler exited with 1
by wgillespie＠es2eng.com 21 Nov '09

21 Nov '09

Full_Name: Willie Gillespie Version: 2.4.X (from CVS) OS: Ubuntu 9.10 x64 URL: Submission from: (NULL) (208.47.173.116) Modify the attribute olcAuthIDRewrite in cn=config and you get: conn=0 op=7 RESULT tag=103 err=80 text=<olcAuthIDRewrite> handler exited with 1 It seems to do this with 2.4.18 and 2.4.19 as well as the version I downloaded from the CVS tonight (2009-11-20). If others don't seem to have the same problem, I'd be happy to list more information about my setup. This is my first ITS bug, so if you need more info about something, let me know and I can provide.

1 0

Re: (ITS#6390) test020 seg faults
by quanah＠zimbra.com 21 Nov '09

21 Nov '09

--On Friday, November 20, 2009 11:29 PM +0000 michael(a)stroeder.com wrote: > I think this is the right issue since Howard wrote to me: >> Your source seems to be corrupt or out of date. There is no call to >> memrchr anywhere near line 2889 in syncrepl.c This has been fixed in RE24, please try now. :) --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6390) test020 seg faults
by michael＠stroeder.com 21 Nov '09

21 Nov '09

quanah(a)zimbra.com wrote: > --On Friday, November 20, 2009 3:53 PM +0000 quanah(a)zimbra.com wrote: > >> --On Friday, November 20, 2009 12:35 PM +0000 rhafer(a)suse.de wrote: >> >>> Hm, I get the following warning during the make run: >>> >>> =2E./../../servers/slapd/syncrepl.c:2861 is: >>> comma =3D ber_bvrchr( &ptr, ',' ); >>> with ber_bvrchr being a macro around memrchr(). So it seems that >>> memrchr() = is=20 >>> undefined in syncrepl.c. >> >> Please don't add secondary issues to an ITS. File a new one. > > Unless you're saying that is the issue, which isn't clear to me in what you > wrote. :P I think this is the right issue since Howard wrote to me: > Your source seems to be corrupt or out of date. There is no call to memrchr > anywhere near line 2889 in syncrepl.c Ciao, Michael.

1 0

(ITS#6391) missing check for broken filters
by h.b.furuseth＠usit.uio.no 20 Nov '09

20 Nov '09

Full_Name: Hallvard B Furuseth Version: HEAD OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard syncrepl.c and overlays/pcache.c call str2filter() and str2filter_x() without checking for success. (so does retcode, but that overlay is only for testing anyway.)

1 0

Re: (ITS#6390) test020 seg faults
by quanah＠zimbra.com 20 Nov '09

20 Nov '09

--On Friday, November 20, 2009 3:53 PM +0000 quanah(a)zimbra.com wrote: > --On Friday, November 20, 2009 12:35 PM +0000 rhafer(a)suse.de wrote: > >> Hm, I get the following warning during the make run: >> >> =2E./../../servers/slapd/syncrepl.c:2861 is: >> comma =3D ber_bvrchr( &ptr, ',' ); >> with ber_bvrchr being a macro around memrchr(). So it seems that >> memrchr() = is=20 >> undefined in syncrepl.c. > > > Please don't add secondary issues to an ITS. File a new one. Unless you're saying that is the issue, which isn't clear to me in what you wrote. :P --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6390) test020 seg faults
by quanah＠zimbra.com 20 Nov '09

20 Nov '09

--On Friday, November 20, 2009 12:35 PM +0000 rhafer(a)suse.de wrote: > Hm, I get the following warning during the make run: > > =2E./../../servers/slapd/syncrepl.c:2861 is: > comma =3D ber_bvrchr( &ptr, ',' ); > with ber_bvrchr being a macro around memrchr(). So it seems that > memrchr() = is=20 > undefined in syncrepl.c. Please don't add secondary issues to an ITS. File a new one. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6390) test020 seg faults
by rhafer＠suse.de 20 Nov '09

20 Nov '09

Am Freitag 20 November 2009 13:34:50 schrieb Ralf Haferkamp: [..] > ../../../servers/slapd/syncrepl.c:2861 is: > comma = ber_bvrchr( &ptr, ',' ); > with ber_bvrchr being a macro around memrchr(). So it seems that memrchr() > is undefined in syncrepl.c. This got introduced by the ITS#6351 fix. I wonder if we should just revert that. The alternative is to add a #define _GNU_SOURCE 1 to ac/string.h if HAVE_MEMRCHR is defined. -- Ralf

1 0

Re: (ITS#6390) test020 seg faults
by michael＠stroeder.com 20 Nov '09

20 Nov '09

hyc(a)symas.com wrote: > michael(a)stroeder.com wrote: >> Full_Name: Michael Ströder >> Version: RE24 >> OS: openSUSE Linux 11.2 (x86_64) >> URL: >> Submission from: (NULL) (84.163.84.65) >> >> >> Relevant build options: >> CFLAGS="-g -O2 -DSLAP_LIGHTWEIGHT_DISPATCHER -DDEVEL" > > The SLAP_LIGHTWEIGHT_DISPATCHER symbol no longer exists in RE24; it was made > the default long ago. > > Why are you testing a release candidate with -DDEVEL? You have no business > defining this, not for release testing. That's for private test builds and > *un*released features; i.e. things we are specifically excluding from > consideration in the release process. I've now set export CFLAGS="-g -O2" now and it still seg faults (after 26 runs). > Your source seems to be corrupt or out of date. There is no call to memrchr > anywhere near line 2889 in syncrepl.c ??? Right before the build I'm always doing cvs up -Rd . This shows me two merges in contrib/ code where I'd tweaked the Makefile to reflect the path of the working dir. Please advice what I should do better. Ciao, Michael.

1 0

Re: (ITS#6390) test020 seg faults
by rhafer＠suse.de 20 Nov '09

20 Nov '09

Hm, I get the following warning during the make run: cc -g -O2 -I../../include -I../../../servers/slapd - I../../../servers/slapd/slapi -I. -I../../../include -c -o syncrepl.o= =20 =2E./../../servers/slapd/syncrepl.c =2E./../../servers/slapd/syncrepl.c: In function =E2=80=98syncrepl_add_glue= =E2=80=99: = =20 =2E./../../servers/slapd/syncrepl.c:2861: warning: cast to pointer from int= eger=20 of different size = =20 =2E./../../servers/slapd/syncrepl.c:2936: warning: cast to pointer from int= eger=20 of different size = =20 =2E./../../servers/slapd/syncrepl.c:2945: warning: cast to pointer from int= eger=20 of different size =2E./../../servers/slapd/syncrepl.c:2861 is: comma =3D ber_bvrchr( &ptr, ',' ); with ber_bvrchr being a macro around memrchr(). So it seems that memrchr() = is=20 undefined in syncrepl.c. Digging through the glibc headers it seems that memrchr() is hidden behind= =20 _GNU_SOURCE. Adding a #define _GNU_SOURCE 1 seems to fix the problem. At le= ast=20 the warnings go away and test020 did fail during the last 40 testruns for m= e. =2D-=20 Ralf

1 0

Re: (ITS#6390) test020 seg faults
by rhafer＠suse.de 20 Nov '09

20 Nov '09

Am Freitag 20 November 2009 00:55:06 schrieb hyc(a)symas.com: This might help: #0 0x00007f117a3f0f54 in __memrchr (s=<value optimized out>, c_in=44, n=18446604362718380092) at memrchr.c:84 char_ptr = 0x7010c82b <Address 0x7010c82b out of bounds> longword_ptr = <value optimized out> longword = <value optimized out> charmask = <value optimized out> c = 44 ',' #1 0x00000000004c484a in syncrepl_add_glue (op=0x7f1177466dd0, e=0xa12508) at ../../../servers/slapd/syncrepl.c:2861 be = 0x9cb760 cb = {sc_next = 0x0, sc_response = 0x4c6e90 <null_callback>, sc_cleanup = 0, sc_private = 0x0} a = 0x0 rc = 0 suffrdns = 2 i = 1 dn = {bv_len = 67, bv_val = 0x7f117010c7f0 "cn=Jennifer Smith,ou=Alumni Association,ou=People,dc=example,dc=com"} ndn = {bv_len = 67, bv_val = 0x7f117010c840 "cn=jennifer smith,ou=alumni association,ou=people,dc=example,dc=com"} glue = 0x3000000018 rs_add = {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} ptr = {bv_len = 18446604362718380092, bv_val = 0x7f117010c7f0 "cn=Jennifer Smith,ou=Alumni Association,ou=People,dc=example,dc=com"} nptr = {bv_len = 139712992275168, bv_val = 0x0} comma = 0x7010c82c <Address 0x7010c82c out of bounds> __PRETTY_FUNCTION__ = "syncrepl_add_glue" #2 0x00000000005a5754 in merge_entry (op=0x7f1177466dd0, e=0xa12508, dup=0, query_uuid=0x7f117010c3e0) at ../../../../servers/slapd/overlays/pcache.c:873 rc = 32 modlist = 0x0 text = 0x0 attr = 0xa2a8b0 textbuf = "\020mFw\021\177\000\000\033JK\000\000\000\000\000\376\003\000\000\000\000\000\000\260\215Fw\021\177\000\000 nFw\001\000\000\000\000\000\020\000\000\000\000\000\340\r\000p\021\177\000\000\340\r\000p\021\177\000\000\020\231Fw\021\177\000\000\a\000\000\000\021\177\000\000\377\377\377\377\377\377\377\377\377\377\377\377\021\177\000\000\360lFw\021\177\000\000r\000`\377\377\377\377\377\020mFw\021\177", '\000' <repeats 18 times>, "\020\231Fw\021\177\000\000 mFw\021\177\000\000!\004`\377\377\377\377\377i{\006K\000\000\000\000PtFw\021\177", '\000' <repeats 18 times>, "PmFw\021\177\000\000\300L\211\000\000\000\000\000PmFw\021\177\000\000:\320E\000\000\000\000\000\350mFw\021\177\000\000\340mFw\021\177\000\000\240mFw\021\177\000\000\247ID\000\000\000\000" textlen = 256 sreply = {sr_type = REP_RESULT, sr_tag = 105, sr_msgid = 0, sr_err = 32, 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 = 0x457438 <slap_null_cb>, sc_cleanup = 0, sc_private = 0x0} #3 0x00000000005a977c in cache_entries (op=0x7f11700008b0, rs=0x7f1177468c80, query_uuid=0x7f117010c3e0) at ../../../../servers/slapd/overlays/pcache.c:2291 si = 0x7f1170001268 on = 0x9cb580 cm = 0x9cb760 return_val = 0 e = 0xa12508 crp_uuid = {bv_len = 17, bv_val = 0x7f1170001050 "dc=example,dc=com"} uuidbuf = "685decf2-6a12-102e-8d88-29e65eca5b5f\000\000\000" op_tmp = 0x7f1177466dd0 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 = {__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}, c_sb = 0x0, c_starttime = 0, c_activitytime = 0, c_connid = 18446744073709551615, c_peer_domain = {bv_len = 0, bv_val = 0x5f22a0 ""}, c_peer_name = {bv_len = 0, bv_val = 0x5f22a0 ""}, c_listener = 0x5f9e60, 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 = {__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}, c_write1_cv = {__data = {__lock = 0, __futex = 0, __total_seq = 0, __wakeup_seq = 0, __woken_seq = 0, __mutex = 0x0, __nwaiters = 0, __broadcast_seq = 0}, __size = '\000' <repeats 47 times>, __align = 0}, c_write2_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}, c_write2_cv = {__data = {__lock = 0, __futex = 0, __total_seq = 0, __wakeup_seq = 0, __woken_seq = 0, __mutex = 0x0, __nwaiters = 0, __broadcast_seq = 0}, __size = '\000' <repeats 47 times>, __align = 0}, c_currentber = 0x0, c_writers = 0, c_writing = 0 '\000', c_sasl_bind_in_progress = 0 '\000', c_writewaiter = 0 '\000', c_is_tls = 0 '\000', c_needs_tls_accept = 0 '\000', c_sasl_layers = 0 '\000', c_sasl_done = 0 '\000', 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 = 0x458a5b <slap_send_ldap_result>, c_send_search_entry = 0x45971e <slap_send_search_entry>, c_send_search_reference = 0x45b9e0 <slap_send_search_reference>, c_send_ldap_extended = 0x4592ab <slap_send_ldap_extended>, c_send_ldap_intermediate = 0x459512 <slap_send_ldap_intermediate>} opbuf = {ob_op = {o_hdr = 0x7f1177466f40, o_tag = 104, o_time = 1258716009, o_tincr = 12, o_bd = 0x9cb760, o_req_dn = {bv_len = 67, bv_val = 0x7f117010c7f0 "cn=Jennifer Smith,ou=Alumni Association,ou=People,dc=example,dc=com"}, o_req_ndn = {bv_len = 67, bv_val = 0x7f117010c840 "cn=jennifer smith,ou=alumni association,ou=people,dc=example,dc=com"}, o_request = {oq_add = {rs_modlist = 0x0, rs_e = 0xa12508}, oq_bind = { rb_method = 0, rb_cred = {bv_len = 10560776, 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 = 8 '\b'}, rs_increment = 0}, oq_modrdn = {rs_mods = {rs_modlist = 0x0, rs_no_opattrs = 8 '\b'}, 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 = 10560776, 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 = 0xa12508 ""}, rs_flags = 0, rs_reqdata = 0x0}, oq_pwdexop = { rs_extended = {rs_reqoid = {bv_len = 0, bv_val = 0xa12508 ""}, 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 = 1 '\001', 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 = 0x7f1177467088, o_authz = {sai_method = 0, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 17, bv_val = 0x9cae70 "dc=example,dc=com"}, sai_ndn = {bv_len = 17, bv_val = 0x9e9af0 "dc=example,dc=com"}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, o_ber = 0x0, o_res_ber = 0x0, o_callback = 0x7f1177466b40, o_ctrls = 0x0, o_csn = {bv_len = 0, bv_val = 0x0}, o_private = 0x0, o_extra = { slh_first = 0x0}, o_next = {stqe_next = 0x0}}, ob_hdr = {oh_opid = 0, oh_connid = 18446744073709551615, oh_conn = 0x7f1177467190, oh_msgid = 0, oh_protocol = 3, oh_tid = 139712992286992, oh_threadctx = 0x7f1177468db0, oh_tmpmemctx = 0x7f1170000de0, oh_tmpmfuncs = 0x88c8c0, oh_counters = 0x90f060, oh_log_prefix = "conn=-1 op=0", '\000' <repeats 243 times>}, ob_controls = {0x0 <repeats 32 times>}} thrctx = 0x7f1177468db0 #4 0x00000000005a9d88 in pcache_op_cleanup (op=0x7f11700008b0, rs=0x7f1177468c80) at ../../../../servers/slapd/overlays/pcache.c:2397 qc = 0x7f117010c3c0 cb = 0x7f1170001248 si = 0x7f1170001268 on = 0x9cb580 cm = 0x9cb760 qm = 0x9f0380 __PRETTY_FUNCTION__ = "pcache_op_cleanup" #5 0x0000000000457ee0 in slap_cleanup_play (op=0x7f11700008b0, rs=0x7f1177468c80) at ../../../servers/slapd/result.c:392 sc_next = 0x0 sc_nextp = 0x7f1170001248 sc = 0x7f1177467980 scp = 0x7f1177467980 #6 0x000000000045868b in send_ldap_response (op=0x7f11700008b0, rs=0x7f1177468c80) at ../../../servers/slapd/result.c:577 berbuf = { buffer = "\000\000\001\000\005\001\000\000\377\377\377\377\377\377\377\377", '\000' <repeats 24 times>"\366, \022\000p\021\177\000\000\304\"\000p\021\177\000\000\000\000\000\000\000\000\000\000\366\022\000p\021\177\000\000\340\r\000p\021\177\000\000pvFw\021\177\000\000\000\000\000\000\000\000\000\000\020\231Fw\021\177\000\000 \000\000p\021\177\000\000\220vFw\021\177\000\000\000\000\000\000\000\000\000\000\020\231Fw\021\177\000\000 \000\000p\021\177\000\000\260vFw\021\177\000\000\000\000\000\000\000\000\000\000\r\311_\000\000\000\000\000\r\311_\000\000\000\000\000\003\000\000\000\000\000\000\000l9>z\021\177\000\000h. \020p\021\177\000\000\071;i|\021\177\000\000\000\000\000\000\000\000\000\000\260\304\020p\021\177\000\000\340vFw\021\177\000\000_\035\213|"..., ialign = 65536, lalign = 1120986529792, falign = 9.18354962e-41, dalign = 5.5384093382102224e-312, palign = 0x10500010000 <Address 0x10500010000 out of bounds>} ber = 0x7f11774675d0 rc = 32768 bytes = 14 __PRETTY_FUNCTION__ = "send_ldap_response" #7 0x0000000000458e70 in slap_send_ldap_result (op=0x7f11700008b0, rs=0x7f1177468c80) at ../../../servers/slapd/result.c:706 tmp = 0x0 otext = 0x0 oref = 0x0 __PRETTY_FUNCTION__ = "slap_send_ldap_result" #8 0x0000000000504d09 in ldap_back_search (op=0x7f11700008b0, rs=0x7f1177468c80) at ../../../../servers/slapd/back-ldap/search.c:575 li = 0x9ca1a0 lc = 0x7f1170102c70 tv = {tv_sec = 0, tv_usec = 100000} stoptime = 1258719609 res = 0x7f117010c4b0 e = 0x7f117010c4b0 rc = 0 msgid = 2 match = {bv_len = 0, bv_val = 0x0} filter = {bv_len = 11, bv_val = 0x7f1170001100 "(sn=smith*)"} i = 5 attrs = 0x7f1170102fb0 freetext = 0 freefilter = 0 do_retry = 0 dont_retry = 1 ctrls = 0x0 references = 0x0 save_matched = 0x0 __PRETTY_FUNCTION__ = "ldap_back_search" #9 0x00000000004d0821 in overlay_op_walk (op=0x7f11700008b0, rs=0x7f1177468c80, which=op_search, oi=0x9cb3a0, on=0x0) at ../../../servers/slapd/backover.c:669 func = 0x8877c8 rc = 32768 #10 0x00000000004d0a38 in over_op_func (op=0x7f11700008b0, rs=0x7f1177468c80, which=op_search) at ../../../servers/slapd/backover.c:721 oi = 0x9cb3a0 on = 0x9cb580 be = 0x9ca010 db = {bd_info = 0x887770, bd_self = 0x9ca010, be_ctrls = "\000", '\001' <repeats 23 times>, "\000\000\000\000\000\000\000\000\001", be_flags = 257, 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 = 0x9cae10, be_nsuffix = 0x9cae40, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = {bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 17, bv_val = 0x9cae70 "dc=example,dc=com"}, be_rootndn = {bv_len = 17, bv_val = 0x9e9af0 "dc=example,dc=com"}, be_rootpw = {bv_len = 6, bv_val = 0x9cad70 "secret"}, be_max_deref_depth = 15, be_def_limit = {lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 500, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x9caf30, be_acl = 0x0, be_dfltaccess = ACL_READ, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0xa6ffe0, 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 = 0x88fc80, be_private = 0x9ca1a0, be_next = { stqe_next = 0x9f2140}} cb = {sc_next = 0x7f1170001248, sc_response = 0x4cf7ca <over_back_response>, sc_cleanup = 0, sc_private = 0x9cb3a0} sc = 0x7f1177468c80 rc = 32768 __PRETTY_FUNCTION__ = "over_op_func" #11 0x00000000004d0b20 in over_op_search (op=0x7f11700008b0, rs=0x7f1177468c80) at ../../../servers/slapd/backover.c:748 No locals. #12 0x0000000000446014 in fe_op_search (op=0x7f11700008b0, rs=0x7f1177468c80) at ../../../servers/slapd/search.c:366 bd = 0x8975a0 #13 0x00000000004458b9 in do_search (op=0x7f11700008b0, rs=0x7f1177468c80) at ../../../servers/slapd/search.c:217 base = {bv_len = 17, bv_val = 0x7f1170102be7 "dc=example,dc=com"} siz = 3 off = 0 i = 3 #14 0x00000000004422f2 in connection_operation (ctx=0x7f1177468db0, arg_v=0x7f11700008b0) at ../../../servers/slapd/connection.c:1109 rc = 80 cancel = 15 op = 0x7f11700008b0 rs = {sr_type = REP_RESULT, sr_tag = 101, sr_msgid = 2, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = {sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x7f1170001198, r_nentries = 1, 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 = 0x7f1178550950 memctx = 0x7f1170000de0 memctx_null = 0x0 memsiz = 1048576 __PRETTY_FUNCTION__ = "connection_operation" #15 0x0000000000442893 in connection_read_thread (ctx=0x7f1177468db0, argv=0xf) at ../../../servers/slapd/connection.c:1245 rc = 0 cri = {op = 0x7f11700008b0, func = 0, arg = 0x0, ctx = 0x7f1177468db0, nullop = 0} s = 15 #16 0x00007f117c8ad279 in ldap_int_thread_pool_wrapper (xpool=0x93e820) at ../../../libraries/libldap_r/tpool.c:685 pool = 0x93e820 task = 0xba6dc0 work_list = 0x93e8b8 ctx = {ltu_id = 139712992286992, ltu_key = {{ltk_key = 0x441e43, ltk_data = 0x7f1170000cd0, ltk_free = 0x441c87 <conn_counter_destroy>}, {ltk_key = 0x4b499a, ltk_data = 0x7f1170000de0, ltk_free = 0x4b477c <slap_sl_mem_destroy>}, {ltk_key = 0x45cda5, ltk_data = 0x0, ltk_free = 0x45ccf8 <slap_op_q_destroy>}, {ltk_key = 0xa70020, ltk_data = 0x7f117010b130, ltk_free = 0x52c79e <bdb_reader_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>}} kctx = 0x0 i = 32 keyslot = 662 hash = 1674836630 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #17 0x00007f117b73865d in start_thread (arg=<value optimized out>) at pthread_create.c:297 __res = <value optimized out> pd = 0x7f1177469910 unwind_buf = {cancel_jmp_buf = {{jmp_buf = {139712992286992, 3546025110985141157, 139713009061584, 139712992286992, 139713085272128, 3, -3524931473729492059, -3524922222741001307}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = <value optimized out> robust = <value optimized out> #18 0x00007f117a43d14d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 No locals. #19 0x0000000000000000 in ?? () No symbol table info available.

1 0

Re: (ITS#6368) Bug in deleting entry in MirrorMode
by hyc＠symas.com 20 Nov '09

20 Nov '09

Peter Palmreuther wrote: > <hyc(a)symas.com> wrote: >> Peter Palmreuther wrote: >>> <hyc(a)symas.com> wrote: > [...[ >>>> Thanks. Please try the syncprov.c in CVS HEAD. (Also you should probably be >>>> testing the RE24 code now, not 2.4.19.) >>> [...] ran several thousand test iterations without a single failure yet. [...] >>> Is this fix "back-portable" to 2.4.19 source, so I can compile a >>> 2.4.19-custom version??? [...] >> >> The patch will be in 2.4.20, which will be released soon. > > Thanks a lot :-) > > Just for the record, so I can > - close this case internally, and > - justify the upcoming upgrade toward our change and release management: > > What was the problem? The second server sending back received synced > operations or the first server processing those "send backs"? Both. The consumer was sending the wrong SID to the provider, so the provider's checks to prevent "send backs" wasn't catching it. Also the provider's checks were being bypassed on Modify operations, so the modified entry would be sent back and recreated after it was deleted. I've added a sequence of repeated add-modify-deletes to test050 to make sure we don't regress on this in the future. > Or was > it just "some pixie dust" on the WLAN cable? ;-) -- -- 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