- openldap-bugs - openldap.org

(ITS#7240) [PATCH] MozNSS: skip hostname check if peer certificate was not requested
by jvcelak＠redhat.com 12 Apr '12

12 Apr '12

Full_Name: Jan Vcelak Version: git master OS: Linux URL: ftp://ftp.openldap.org/incoming/jvcelak-120412-moznss-hostname-check.patch Submission from: (NULL) (209.132.186.34) Hello. With Mozilla NSS crypto backend, the 'tls_checkpeer no' option in 'sudo' tool does not work. I have uploaded a patch which fixes the bug. But some explanation is necessary: sudo initially creates a ldap handle using ldap_initialize() function. Then it uses ldap_set_option() to set all the settings. The TLS configuration is applied without passing a LDAP handle, which means the the global options are changed. In ldap_int_start_tls(): - The ldap_int_tls_connect() is called and the global TLS context is used (LDAP_INT_GLOBAL_OPT()->ldo_tls_ctx). Which is correct. - The ldap_pvt_tls_check_hostname() is called always. "sudo" will set the ldo_tls_require_cert in global options to LDAP_OPT_X_TLS_NEVER, but the handle options (ld->ld_options) are used to check whether the verification is supposed to happen. And ldo_tls_require_cert in handle options is LDAP_OPT_X_TLS_DEMAND (the default), because it was copied from the global options at the time when ldap_initialize() was called. - With OpenSSL, hostname check (tlso_session_chkhost) will succeed because tlso_get_cert() will return NULL. This is true because no certificate was requested when connecting. We do not request the certificate as well in Mozilla NSS, but it seems that the peer can send it anyway and the library will accept and store it. In this case, hostname check (tlsm_session_chkhost) might fail because SSL_PeerCertificate() will return it. I've added an additional check, which skips the hostname verification within tlsm_session_chkhost if we do not request the certificate validation. With this patch, the behavior is consistent with OpenSSL. (Maybe ldap_pvt_tls_check_hostname() should not just be called, because the global context was used and therefore we should use global options. Not sure what is expected, but I think that changing this might break some applications. My fix is safer.) Jan

1 0

Re: (ITS#7225) back-monitor/ldap crash in test020-proxycache
by ondrej.kuznik＠acision.com 12 Apr '12

12 Apr '12

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/04/2012 02:09 PM, h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth Version: master, > fc1396fa2e94ee2e752fd7c3ea5bb22f6592398a OS: Linux x86_64 URL: > Submission from: (NULL) (129.240.203.186) Submitted by: hallvard > > > back-ldap:ldap_back_monitor_conn_init() calls > monitor_back_register_entry_attrs(,,,nbase=NULL,,) which crashes > at: > > 1093 if ( !BER_BVISNULL( nbase ) ) { > > That checks if nbase->bv_val is NULL, it does not check nbase > itself. Backtrace: > > #0 monitor_back_register_entry_attrs (ndn_in=0x1023d50, > a=0x1092be8, cb=0x10f59b0, nbase=0x0, scope=0, filter=0x0) at > init.c:1093 #1 ldap_back_monitor_conn_init (be=0x104d0c0, > ms=0x1023d28) at monitor.c:658 #2 monitor_back_db_open > (be=0x104d0c0, cr=0x7fff704846e0) at init.c:2365 #3 > backend_startup_one (be=0x104d0c0, cr=0x7fff704846e0) at > backend.c:224 #4 backend_startup (be=0x104d0c0) at backend.c:325 #5 > slap_startup (be=0x0) at init.c:219 I prepared a patch mentioned in the -devel mailing list for the remaining issue not yet fixed in master. - -- Ondrej Kuznik -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+Gsb8ACgkQ9GWxeeH+cXvTvgCfeIIljtQv7XahXE9P2aocg+xu oWoAn0zvQVQ6x3PnL3IhL2SWMo1iSKWo =NZ52 -----END PGP SIGNATURE----- This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you for understanding.

1 0

ITS#7239
by michael＠stroeder.com 12 Apr '12

12 Apr '12

This is a cryptographically signed message in MIME format. --------------ms020908090503080200050809 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable It seems that 'logops all' only fails if an entry is renamed which has an= RDN attribute which is check by slapo-unique. It seems slapo-unique's interna= l search is also logged to accesslog DB. Is that correct behaviour? So this combination does *not* work: ----------------------------------- overlay unique unique_attributes uid overlay accesslog logdb "cn=3Daccesslog" logops all ----------------------------------- This combination works correctly: ----------------------------------- overlay unique unique_attributes uid overlay accesslog logdb "cn=3Daccesslog" logops writes session ----------------------------------- --------------ms020908090503080200050809 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 hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQxMjA3NTUxOFowIwYJKoZIhvcNAQkEMRYE FNS0/62yD9dzyzS3EyhbuMy09iM7MF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoG CCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggq hkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGDMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAc BgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5n IEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwgZMG CyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6 Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEh MB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwDQYJKoZIhvcNAQEBBQAE ggEAKMtTuAEUZMWoCtepWolUde61WnPI+6pmWV/PUVJHHx2jvQHE4CTRI10LzG9MDp371Hf9 PhsFUamF1uEZ7zq7uFHqT8ry3Ku4aKZuIWOnaY8qZxPZTGkkeP6krmJwye/FFsldwNo1iQnl goNRG1PmCkAN2J9cVyUSd+2Ls388sSaThAhUZBvRknF8UbOCMazw8gWNypCSR2euR+0DJhhf kUD6YsQvPpe4eWi6ZIb4nhy1UDqxvWeOnnD2j0Ryg5eixL41DLGjfhwsV8GwMqjkBoFEsEec /yjo46BvN6YX5Ow9SGoy2eYbZo6K2aLZ23OvYsiqgRn/k13R71QPht/4eAAAAAAAAA== --------------ms020908090503080200050809--

1 0

Re: (ITS#6656) logging "reqEntryUUID" in accesslog
by michael＠stroeder.com 12 Apr '12

12 Apr '12

This is a cryptographically signed message in MIME format. --------------ms030601000506050202050204 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable masarati(a)aero.polimi.it wrote: >> Please revisit this ITS. I'd like to implement something like "svn rev= ert=3D >> " >> based on accesslog entries. Having the entry's UUID in an indexable at= tri=3D >> bute >> would make this more robust. >> >> This could also be handy for delta-replication if "conflicting" modrdn= >> requests were sent by a client which result in same reqDN. >=20 > Added to master, please test. Thanks. Seems to work. Added support for it in upcoming web2ldap 1.1.12...(searching the accessl= og entries and reverse searching the target entries). Ciao, Michael. --------------ms030601000506050202050204 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 hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQxMjA3NTUxMlowIwYJKoZIhvcNAQkEMRYE FKAXr449YjNzkPdvkc1ruZoD11dbMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoG CCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggq hkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGDMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAc BgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5n IEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwgZMG CyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6 Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEh MB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwDQYJKoZIhvcNAQEBBQAE ggEAxBqZadPfILnU/3+CI04Q803WcBUbQGGWz1rp9t4aWjOpnDmXwSfoG5kJ+qKJLvo5SGqy CtvlizF3xkVjB4qZJo0x5wRKAV0a8it7YqQbQpwpMC8YX74qJZY0f+3W83WJYiXgLEelkL2p 9AwRnwQS3+MRz5FrO5O7Xr/9csrribOkhJAbEQ+LR4CUNAcNttqkpWeUQ9J4bgW6gUgf7sQ4 SAC3devBI3u1vFxZl7yP8E3H3QQcm9eElvzGIRkX+2aRv2MKev+UzMAO+icTZTl21lnjgAnz KqAYWjKh3FXVoc8RUvMrl5yEuwuc09UV+rQjZmYenHQcWvhauEVOdy46OAAAAAAAAA== --------------ms030601000506050202050204--

1 0

Re: (ITS#7222) Slapd hangs on high load
by hrvoje.habjanic＠zg.t-com.hr 12 Apr '12

12 Apr '12

This is a multi-part message in MIME format. --------------040402080004020608060006 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 09.04.2012 20:09, Hrvoje Habjanić wrote: > > Hi. > > Two more "hang"s, both in sched_yield(). This is with replacement malloc > (tcmalloc, minimal). > > http://free-zg.t-com.hr/HrvojeHabjanic/openldap/hang4.log > http://free-zg.t-com.hr/HrvojeHabjanic/openldap/hang5.log > > H. Hi. Attached patch if solving my proglem with "hang" in sched_yield. In general, i do think that there (cache management) is a lot of unnecessary locking and waiting ... And simplifying things there would solve a lot of problems ... Probably. :-) Of course, i'm not shure how will this change influence the rest of the code, but it does work for me (tm). H. p.s. Also available at http://free-zg.t-com.hr/HrvojeHabjanic/openldap/ol.diff --------------040402080004020608060006 Content-Type: text/x-patch; name="ol.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ol.diff" diff -Nru openldap-d7d1789-org/servers/slapd/back-bdb/cache.c openldap-d7d1789/servers/slapd/back-bdb/cache.c --- openldap-d7d1789-org/servers/slapd/back-bdb/cache.c 2012-04-10 00:47:23.000000000 +0200 +++ openldap-d7d1789/servers/slapd/back-bdb/cache.c 2012-04-11 10:23:43.267461183 +0200 @@ -1361,7 +1361,7 @@ DB_LOCK *lock ) { EntryInfo *ei = BEI(e); - int rc, busy = 0; + int rc, busy = 0, counter = 0; assert( e->e_private != NULL ); @@ -1378,7 +1378,7 @@ bdb_cache_entryinfo_unlock( ei ); - while ( busy ) { + while ( busy && counter < 1000) { ldap_pvt_thread_yield(); busy = 0; bdb_cache_entryinfo_lock( ei ); @@ -1387,6 +1387,13 @@ ei->bei_finders > 0 ) busy = 1; bdb_cache_entryinfo_unlock( ei ); + counter ++; + } + if( busy ) { + bdb_cache_entryinfo_lock( ei ); + ei->bei_state ^= CACHE_ENTRY_DELETED; + bdb_cache_entryinfo_unlock( ei ); + return DB_LOCK_DEADLOCK; } /* Get write lock on the data */ --------------040402080004020608060006--

1 0

Re: ITS#6598
by masarati＠aero.polimi.it 12 Apr '12

12 Apr '12

> --On Saturday, February 18, 2012 12:41 AM +0000 quanah(a)zimbra.com wrote: > >> --On Saturday, February 18, 2012 1:32 AM +0100 masarati(a)aero.polimi.it >> wrote: > >> ah, ok thanks. :) > > > Any particularly reason why the control can't be made critical? No. Now it can. p.

1 0

Re: (ITS#6656) logging "reqEntryUUID" in accesslog
by masarati＠aero.polimi.it 10 Apr '12

10 Apr '12

> Please revisit this ITS. I'd like to implement something like "svn revert= > " > based on accesslog entries. Having the entry's UUID in an indexable attri= > bute > would make this more robust. > > This could also be handy for delta-replication if "conflicting" modrdn > requests were sent by a client which result in same reqDN. Added to master, please test. p.

1 0

Re: (ITS#7224) Core dump while trying to run slapd
by ashish＠sendmail.com 10 Apr '12

10 Apr '12

On 4/9/2012 3:42 PM, masarati(a)aero.polimi.it wrote: > I have checked this case (I suspect the same could happen in other schema > items) and I'm about to commit a fix. > Will this be part of 2.4.31? Thank you for the fix!

1 0

Re: (ITS#7224) Core dump while trying to run slapd
by masarati＠aero.polimi.it 10 Apr '12

10 Apr '12

> On 4/9/2012 7:01 AM, masarati(a)aero.polimi.it wrote: >>> On 4/6/2012 10:22 AM, Howard Chu wrote: >>>> Find out why oc->oc_names is NULL. It should not be. Seems like you >>>> have an invalid schema definition. >>>> >>> I have fixed the objectClasses that were violating by adding >>> "extensibleObject". >> ObjectClass with OID '1.3.6.1.4.1.6152.10.3.2.16'. Can you provide its >> definition? Apparently, oc_names is NULL, i.e. no names are defined for >> that class. >> > Here is the object class definition. > > Few things to note: > 1. I had added this class temporarily (before I added extensibleObject). > 2. I had forgotten to remove this definition from the schema, after > adding extensibleObject. > > objectclass ( 1.3.6.1.4.1.6152.10.3.2.16 > NAME 'sendmailMTAMAPAlias' > SUP ( sendmailMTAAliasObject $ sendmailMTAMAPObject ) STRUCTURAL > DESC 'Sendmail MTA map alias definition' ) > > > 3. I am re-running the slapadd, without this schema. > > (Will update the bug with more info then) I have created something similar (a structural class inheriting from two existing ones) and I couldn't reproduce your issue. However, I could exactly reproduce it by entirely removing the "NAME 'sendmailMTAMAPAlias'" portion, so I suspect you were using something like that. Slapd is accepting such definition (which I believe is at least bad practice, but it should be legal as we only complain about missing OID). I have checked this case (I suspect the same could happen in other schema items) and I'm about to commit a fix. p.

1 0

Re: (ITS#7224) Core dump while trying to run slapd
by ashish＠sendmail.com 09 Apr '12

09 Apr '12

On 4/9/2012 7:01 AM, masarati(a)aero.polimi.it wrote: >> On 4/6/2012 10:22 AM, Howard Chu wrote: >>> Find out why oc->oc_names is NULL. It should not be. Seems like you >>> have an invalid schema definition. >>> >> I have fixed the objectClasses that were violating by adding >> "extensibleObject". > ObjectClass with OID '1.3.6.1.4.1.6152.10.3.2.16'. Can you provide its > definition? Apparently, oc_names is NULL, i.e. no names are defined for > that class. > Here is the object class definition. Few things to note: 1. I had added this class temporarily (before I added extensibleObject). 2. I had forgotten to remove this definition from the schema, after adding extensibleObject. objectclass ( 1.3.6.1.4.1.6152.10.3.2.16 NAME 'sendmailMTAMAPAlias' SUP ( sendmailMTAAliasObject $ sendmailMTAMAPObject ) STRUCTURAL DESC 'Sendmail MTA map alias definition' ) 3. I am re-running the slapadd, without this schema. (Will update the bug with more info then)

1 0

Re: (ITS#7222) Slapd hangs on high load
by hrvoje.habjanic＠zg.t-com.hr 09 Apr '12

09 Apr '12

On 08.04.2012 13:25, Hrvoje Habjanić wrote: > On 04.04.2012 17:45, Hrvoje Habjanić wrote: >> On 03.04.2012 17:41, Howard Chu wrote: >>> You may be able to avoid this bug by using an alternate malloc >>> library, such as Google tcmalloc. >>> >> Hi. >> >> I did try - using tcmalloc. And this time, i got SIGSEGV. Odd thing is >> that this happened in "pthread_mutex_lock" which is in libpthread.so ...? >> >> Another bug in centos libs? I would appreciate if you could take a look. >> >> Thx. >> >> H. >> >> p.s. url -> http://free-zg.t-com.hr/HrvojeHabjanic/hang3.log > Hi. Two more "hang"s, both in sched_yield(). This is with replacement malloc (tcmalloc, minimal). http://free-zg.t-com.hr/HrvojeHabjanic/openldap/hang4.log http://free-zg.t-com.hr/HrvojeHabjanic/openldap/hang5.log H.

1 0

Re: (ITS#7226) olcAuditlogFile At dos not accept multiple values
by hyc＠symas.com 09 Apr '12

09 Apr '12

michael(a)stroeder.com wrote: > This is a cryptographically signed message in MIME format. > > --------------ms000408080902010107050201 > Content-Type: text/plain; charset=ISO-8859-1 > Content-Transfer-Encoding: quoted-printable > > masarati(a)aero.polimi.it wrote: >> In general, I also prefer to have NO matching rules associated to attrs= > >> designed for purposes that do not require matching > > Why? > > As said it's useful for collision detection in case of a modify. So at le= > ast > every multi-valued attribute should have an EQUALITY matching rule. Every multi-valued attribute already does. They would be unusable otherwise. This discussion is only about single-valued config attributes. -- -- 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#7226) olcAuditlogFile At dos not accept multiple values
by masarati＠aero.polimi.it 09 Apr '12

09 Apr '12

> masarati(a)aero.polimi.it wrote: >> In general, I also prefer to have NO matching rules associated to attrs >> designed for purposes that do not require matching > > Why? In general, configuring a system means to write something as a whole, not bit by bit, since it works as intended only when everything is in place. Changing a small bit can have unexpected semantic impact. There are exceptions (either theoretically, or practically). For example, ACLs: occasionally one needs to tweak ACLs (in this case, small modifications can have tremendous impact on the functionality of totally unrelated parts as well), but ACLs need to evolve and adapt to needs. Another example are indexes. Nonetheless, I believe the best way to modify ACLs is through "replace". Fortunately, the most important aspect of ACLs is their order; in this case, the administrator can leverage the X-ORDERED feature. For exceptions, and for all attrs that may legitimately need to be routinely modified, I concur having a well-defined matching rule is helpful. > As said it's useful for collision detection in case of a modify. So at > least > every multi-valued attribute should have an EQUALITY matching rule. "replace" is your friend when managing configuration. > If in doubt which matching rule to use one could choose the stricter one > as > default, e.g. prefer caseExact over caseIgnore. Well, I'm afraid there will always be someone complaining because we chose caseExact instead of caseIgnore. Of course, my 2c. p.

1 0

Re: (ITS#7226) olcAuditlogFile At dos not accept multiple values
by michael＠stroeder.com 09 Apr '12

09 Apr '12

This is a cryptographically signed message in MIME format. --------------ms000408080902010107050201 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable masarati(a)aero.polimi.it wrote: > In general, I also prefer to have NO matching rules associated to attrs= > designed for purposes that do not require matching Why? As said it's useful for collision detection in case of a modify. So at le= ast every multi-valued attribute should have an EQUALITY matching rule. If in doubt which matching rule to use one could choose the stricter one = as default, e.g. prefer caseExact over caseIgnore. Ciao, Michael. --------------ms000408080902010107050201 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 hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQwOTE0MDMzN1owIwYJKoZIhvcNAQkEMRYE FA/Qy+ARPwJkPevCeC+L6wyIRj0kMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoG CCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggq hkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGDMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAc BgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5n IEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwgZMG CyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6 Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEh MB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwDQYJKoZIhvcNAQEBBQAE ggEAGTlcNhwACV1MtWV3357kkJD4g8XzJiMqBalX91sbDNJB1nMxa0T7bL/9EjphF2x848kZ cigt+EvFku6zt2zYTfhtmO4BS2kapufb5FeWfZ0YhBUFHJapvs91bLo07zkeW22Q2JxEbMhc YFAiulZZz8IunikRpC8HT5tFfj/lbdskKllS7Y7p/4lBjyOf/a98+wKLPLt4AhDG6oIDufSr slldCFo6EQ5Gtj6CoF821/No4zIQRWVjjtx1Xzdy6ie395ebvejF1WuX+vIkbTbSPwR4HAF7 zgrUr5tXwI9W1N/nrYQ1eRLuZ3r4Aot/5CxqJ5UtZntIfXx+RWXZ2TE4hQAAAAAAAA== --------------ms000408080902010107050201--

1 0

Re: (ITS#7224) Core dump while trying to run slapd
by masarati＠aero.polimi.it 09 Apr '12

09 Apr '12

> On 4/6/2012 10:22 AM, Howard Chu wrote: >> >> Find out why oc->oc_names is NULL. It should not be. Seems like you >> have an invalid schema definition. >> > I have fixed the objectClasses that were violating by adding > "extensibleObject". ObjectClass with OID '1.3.6.1.4.1.6152.10.3.2.16'. Can you provide its definition? Apparently, oc_names is NULL, i.e. no names are defined for that class. > Also, the slapadd-ing should not "core", and give the right error message. Allowing us to reproduce and fix the issue would help us prevent issues like this. p.

1 0

Re: (ITS#7226) olcAuditlogFile At dos not accept multiple values
by masarati＠aero.polimi.it 09 Apr '12

09 Apr '12

> quanah(a)zimbra.com wrote: >> --On Thursday, April 05, 2012 7:38 PM +0000 h.b.furuseth(a)usit.uio.no >> wrote: >> >>> On Thu, 5 Apr 2012 13:12:31 GMT, michael(a)stroeder.com wrote: >>>> hyc(a)symas.com wrote: >>>>> michael(a)stroeder.com wrote: >>>>>> 2. add an equality matching rule. >>>>> >>>>> My approach with config attrs has been to skip the equality rule for >>>>> single-valued attrs. Since they are single-valued, there's obviously >>>>> no need >>>>> to allow for comparing multiple values. >>> >>> Users always find more ways to use a feature than its creator >>> imagined. >>> >>> I wish people would give attributes all matching rules they can. >>> Equality, ordering, substring. Except when: >>> - flexibility would be a misfeature, e.g. SUBSTR for userPassword, >>> - or it's unclear which rules to choose, e.g. caseIgnore vs >>> caseExact. >> >> I agree. I think defining matching rules where possible is extremely >> useful. > > Patch welcome. This is a pretty trivial patch to write, but I have more > urgent > things to attend to. In general, I also prefer to have NO matching rules associated to attrs designed for purposes that do not require matching (this is often the case of configuration-specific attributes mostly if not only intended for internal use). Whenever one needs to search them, extensible filtering is your friend. p.

1 0

Re: (ITS#7238) Multiple txns in same thread break mdb
by h.b.furuseth＠usit.uio.no 09 Apr '12

09 Apr '12

I wrote: > Related doc bug: > > I expect it should be "only one thread at a time". I doubt > it's about pinning some operation to a particular thread:-) Argh, something ate the part which says what I'm talking about: mdb_open() and mdb_close(), and partly mdb_drop() Hallvard

1 0

Re: (ITS#7238) Multiple txns in same thread break mdb
by hyc＠symas.com 09 Apr '12

09 Apr '12

h.b.furuseth(a)usit.uio.no wrote: > Related doc bug: > > I expect it should be "only one thread at a time". I doubt > it's about pinning some operation to a particular thread:-) Wrong. For write txns I suppose that could be relaxed. For readers, the reader slot is set when the txn is created, and that slot is owned by a particular thread. > However, maybe it should rather be something like "No other > transaction doing mdb_open() may exist at the same time, nor > a write transaction (since that also updates the databases), > nor may such a transaction exist during mdb_close()" ? > > I note mdb_drop() also updates the databases and can > likely not coexist with the others, but that's covered by > mentioning write txns. > > Regarding mdb_drop(), while I'm at it: > @brief Delete a database and/or free all its pages. > @param[in] del non-zero to delete the DB from > the environment, otherwise just free its pages. > Free which pages? In the DB, or some malloced ones? This is single-level-store, there is no distinction. In the DB or in memory, all the same. -- -- 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#7237) Crash abandoning freed/unused operation
by h.b.furuseth＠usit.uio.no 09 Apr '12

09 Apr '12

On Sun, 8 Apr 2012 00:49:28 GMT, h.b.furuseth(a)usit.uio.no wrote: > './run -b ldif test045-syncreplication-proxied' crashed > in connection_abandon() with LDAP_MEMORY_DEBUG: > It dereferenced o_hdr which is NULL in the uninitialized or > freed op 'o'. (op 'o' is full of 0xFF bytes, which I > assume is the poiosin from liblber/memory.c.) Reproduced with bdb. It's a freed op sitting in the c->c_ops list when entering connection_abandon(). (Checked my modifying the "poison" in liblber and inspecting the list before the be_abandon loop.) Not reproduced under valgrind so far. -- Hallvard

1 0

Re: (ITS#7238) Multiple txns in same thread break mdb
by h.b.furuseth＠usit.uio.no 09 Apr '12

09 Apr '12

Related doc bug: I expect it should be "only one thread at a time". I doubt it's about pinning some operation to a particular thread:-) However, maybe it should rather be something like "No other transaction doing mdb_open() may exist at the same time, nor a write transaction (since that also updates the databases), nor may such a transaction exist during mdb_close()" ? I note mdb_drop() also updates the databases and can likely not coexist with the others, but that's covered by mentioning write txns. Regarding mdb_drop(), while I'm at it: @brief Delete a database and/or free all its pages. @param[in] del non-zero to delete the DB from the environment, otherwise just free its pages. Free which pages? In the DB, or some malloced ones? I expect it should be "delete a database or empty its contents", and "del non-zero ... otherwise just empty the database." -- Hallvard

1 0

Re: (ITS#7238) Multiple txns in same thread break mdb
by hyc＠symas.com 09 Apr '12

09 Apr '12

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: > OS: > URL: > Submission from: (NULL) (195.1.106.125) > Submitted by: hallvard > > > mdb.h says a transaction must only be used by a single thread, > but libmdb also assumes a thread only has one transaction: Yes, this is a design requirement. Doc should be updated if it doesn't already state this explicitly. -- -- 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#7238) Multiple txns in same thread break mdb
by h.b.furuseth＠usit.uio.no 08 Apr '12

08 Apr '12

Full_Name: Hallvard B Furuseth Version: OS: URL: Submission from: (NULL) (195.1.106.125) Submitted by: hallvard mdb.h says a transaction must only be used by a single thread, but libmdb also assumes a thread only has one transaction: If there have been some commits since the oldest txn, and a new txn then starts in the same thread as an oldest txn, the oldest txnid is overwritten in the reader table. Writers can then modify pages the oldest txn still uses. Example: This should print A, but prints AEFG. It commits an "A", starts a reader and reads the A, then several commits delete the lowest letter and add two newer letter: -A +BC, -B +DE, -C +FG... while starting new readers, then reads more with 1st reader. #include "mdb.h" #include <assert.h> #include <pthread.h> #include <stdio.h> #include <unistd.h> #define E(expr) assert(!(expr)) enum { Count = 6 }; static char dbname[] = "testdb.mdb"; static MDB_env *env; static MDB_dbi dbi; static pthread_barrier_t barrier; static void *reader(void *arg) { int i, rc; MDB_txn *txns[Count]; MDB_cursor *cursor; MDB_val key, data; pthread_barrier_wait(&barrier); E(mdb_txn_begin(env, NULL, MDB_RDONLY, &txns[0])); E(mdb_cursor_open(txns[0], dbi, &cursor)); E(mdb_cursor_get(cursor, &key, &data, MDB_NEXT)); fputs((char *) key.mv_data, stdout); pthread_barrier_wait(&barrier); for (i = 1; i < Count; i++) { pthread_barrier_wait(&barrier); E(mdb_txn_begin(env, NULL, MDB_RDONLY, &txns[i])); pthread_barrier_wait(&barrier); } while ((rc = mdb_cursor_get(cursor, &key, &data, MDB_NEXT)) == 0) fputs((char *) key.mv_data, stdout); puts("."); assert(rc == MDB_NOTFOUND); return arg; } int main(void) { char add[2] = "A", del[2] = "A"; MDB_val key = {2, add}, dkey = {2, del}, data = {3, "Hi"}; MDB_txn *txn; pthread_t tid; int i; unlink(dbname); E(mdb_env_create(&env)); E(mdb_env_open(env, dbname, MDB_NOSUBDIR, 0660)); E(mdb_txn_begin(env, NULL, 0, &txn)); E(mdb_open(txn, NULL, 0, &dbi)); E(mdb_put(txn, dbi, &key, &data, 0)); ++*add; E(mdb_txn_commit(txn)); E(pthread_barrier_init(&barrier, NULL, 2)); E(pthread_create(&tid, NULL, reader, NULL)); pthread_barrier_wait(&barrier); for (i = 1; i < Count; i++) { pthread_barrier_wait(&barrier); E(mdb_txn_begin(env, NULL, 0, &txn)); E(mdb_del(txn, dbi, &dkey, NULL )); ++*del; E(mdb_put(txn, dbi, &key, &data, 0)); ++*add; E(mdb_put(txn, dbi, &key, &data, 0)); ++*add; E(mdb_txn_commit(txn)); pthread_barrier_wait(&barrier); } pthread_barrier_wait(&barrier); E(pthread_join(tid, NULL)); return 0; } I have not looked at what happens if some of the readers are in the same thread as the writer.

1 0

Re: (ITS#7222) Slapd hangs on high load
by hrvoje.habjanic＠zg.t-com.hr 08 Apr '12

08 Apr '12

On 04.04.2012 17:45, Hrvoje Habjanić wrote: > On 03.04.2012 17:41, Howard Chu wrote: >> You may be able to avoid this bug by using an alternate malloc >> library, such as Google tcmalloc. >> > Hi. > > I did try - using tcmalloc. And this time, i got SIGSEGV. Odd thing is > that this happened in "pthread_mutex_lock" which is in libpthread.so ...? > > Another bug in centos libs? I would appreciate if you could take a look. > > Thx. > > H. > > p.s. url -> http://free-zg.t-com.hr/HrvojeHabjanic/hang3.log Hi. And, one more SIGSEGV ... Should i open a new ITS? H. p.s. http://free-zg.t-com.hr/HrvojeHabjanic/openldap/ssegv.log

1 0

Re: (ITS#7202) slapo-memeberof crashing OL 2.4.30
by marco.pizzoli＠gmail.com 08 Apr '12

08 Apr '12

--20cf300fa9cf6deac304bd27f749 Content-Type: multipart/alternative; boundary=20cf300fa9cf6deabd04bd27f747 --20cf300fa9cf6deabd04bd27f747 Content-Type: text/plain; charset=ISO-8859-1 Hi Howard, On Sat, Apr 7, 2012 at 7:07 PM, Howard Chu <hyc(a)symas.com> wrote: > marco.pizzoli(a)gmail.com wrote: > >> Full_Name: Marco Pizzoli >> Version: 2.4.30 >> OS: Linux >> URL: ftp://ftp.openldap.org/**incoming/<ftp://ftp.openldap.org/incoming/> >> Submission from: (NULL) (213.174.164.11) >> >> >> Hi, I'm facing crashes with openldap 2.4.30 (actually the RE24 of the day >> before >> the release, but nothing changed in the meantime). >> >> I have a consumer starting from scratch with an empty db. During his >> starting he >> populates his db by connecting to 4 servers which are part of a 4-way >> multi-master cluster. They are running a previous version of OpenLDAP. >> We are doing an upgrade of our deployment just to solve an issue we face >> from >> time to time consisting in data corruption. >> This bug, which is not the target of this ITS, is able to trigger a crash >> of the >> slave slapd 2.4.30. >> >> During the first synchronization the consumer is receiving the entire db >> and I >> can see on this slave, in the logs, coming two odd entries, like this one: >> > > Please send the complete consumer config. Also the provider config and > sample DB. > In attachment you can find the sanitized consumer configurations of both the consumer and the provider. I cannot share my db, but I cannot be of help anyway because ldifs produced both by ldapsearch and slapcat produced a clean database / clean db entries. The problem arises only after a corruption on the data as *published* from the provider. As I wrote, this was a problem we already were having. Other times we simply found one server which doesn't publish wrong data and then clearing the other ones: drop the db and starting from scratch replicating from this one. > > Please let me know if you keed other details. >> Thanks >> Marco >> > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/**project/<http://www.openldap.org/project/> > --20cf300fa9cf6deabd04bd27f747 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Howard,<br><br><div class=3D"gmail_quote">On Sat, Apr 7, 2012 at 7:07 PM= , Howard Chu <span dir=3D"ltr"><<a href=3D"mailto:hyc@symas.com" target= =3D"_blank">hyc(a)symas.com</a>></span> wrote:<br><blockquote class=3D"gma= il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef= t:1ex"> <a href=3D"mailto:marco.pizzoli@gmail.com" target=3D"_blank">marco.pizzoli@= gmail.com</a> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Full_Name: Marco Pizzoli<br> Version: 2.4.30<br> OS: Linux<br> URL: <a href=3D"ftp://ftp.openldap.org/incoming/" target=3D"_blank">ftp://f= tp.openldap.org/<u></u>incoming/</a><br> Submission from: (NULL) (213.174.164.11)<br> <br> <br> Hi, I'm facing crashes with openldap 2.4.30 (actually the RE24 of the d= ay before<br> the release, but nothing changed in the meantime).<br> <br> I have a consumer starting from scratch with an empty db. During his starti= ng he<br> populates his db by connecting to 4 servers which are part of a 4-way<br> multi-master cluster. They are running a previous version of OpenLDAP.<br> We are doing an upgrade of our deployment just to solve an issue we face fr= om<br> time to time consisting in data corruption.<br> This bug, which is not the target of this ITS, is able to trigger a crash o= f the<br> slave slapd 2.4.30.<br> <br> During the first synchronization the consumer is receiving the entire db an= d I<br> can see on this slave, in the logs, coming two odd entries, like this one:<= br> </blockquote> <br> Please send the complete consumer config. Also the provider config and samp= le DB.<br></blockquote><div><br></div><div>In attachment you can find the= =A0sanitized=A0consumer configurations of both the consumer and the provide= r.</div> <div><br></div><div>I cannot share my db, but I cannot be of help anyway be= cause ldifs produced both by ldapsearch and slapcat produced a clean databa= se / clean db entries. The problem arises only after a corruption on the da= ta as *published* from the provider.</div> <div>As I wrote, this was a problem we already were having. Other times we = simply found one server which doesn't publish wrong data and then clear= ing the other ones: drop the db and starting from scratch replicating from = this one.</div> <div><br></div><div><br></div><div>=A0</div><blockquote class=3D"gmail_quot= e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Please let me know if you keed other details.<br> Thanks<br> Marco<span><font color=3D"#888888"><br> </font></span></blockquote><span><font color=3D"#888888"> <br> -- <br> =A0-- Howard Chu<br> =A0CTO, Symas Corp. =A0 =A0 =A0 =A0 =A0 <a href=3D"http://www.symas.com" t= arget=3D"_blank">http://www.symas.com</a><br> =A0Director, Highland Sun =A0 =A0 <a href=3D"http://highlandsun.com/hyc/" = target=3D"_blank">http://highlandsun.com/hyc/</a><br> =A0Chief Architect, OpenLDAP =A0<a href=3D"http://www.openldap.org/project= /" target=3D"_blank">http://www.openldap.org/<u></u>project/</a><br> </font></span></blockquote></div><br> --20cf300fa9cf6deabd04bd27f747-- --20cf300fa9cf6deac304bd27f749 Content-Type: application/octet-stream; name="consumer.conf" Content-Disposition: attachment; filename="consumer.conf" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h0rx8deb0 c2NoZW1hZG4JY249U3Vic2NoZW1hDQppbmNsdWRlCQkvb3B0L29wZW5sZGFwL2V0Yy9vcGVubGRh cC9zY2hlbWEvY29yZS5zY2hlbWENCmluY2x1ZGUJCS9vcHQvb3BlbmxkYXAvZXRjL29wZW5sZGFw L3NjaGVtYS9jb3NpbmUuc2NoZW1hDQppbmNsdWRlCQkvb3B0L29wZW5sZGFwL2V0Yy9vcGVubGRh cC9zY2hlbWEvcHBvbGljeS5zY2hlbWENCmluY2x1ZGUJCS9vcHQvb3BlbmxkYXAvZXRjL29wZW5s ZGFwL3NjaGVtYS9yZmMyMzA3YmlzLnNjaGVtYQ0KaW5jbHVkZQkJL29wdC9vcGVubGRhcC9ldGMv b3BlbmxkYXAvc2NoZW1hL2luZXRvcmdwZXJzb24uc2NoZW1hDQppbmNsdWRlCQkvZXRjL29wZW5s ZGFwL3NjaGVtYS9jdXN0b20uc2NoZW1hDQoNCm1vZHVsZXBhdGgJL29wdC9vcGVubGRhcC9saWJl eGVjL29wZW5sZGFwDQptb2R1bGVsb2FkCW1lbWJlcm9mLmxhDQptb2R1bGVsb2FkCWFjY2Vzc2xv Zy5sYQ0KbW9kdWxlbG9hZAlhdWRpdGxvZy5sYQ0KbW9kdWxlbG9hZAlwcG9saWN5LmxhDQptb2R1 bGVsb2FkCXNzc3Zsdi5sYQ0KbW9kdWxlbG9hZAlzeW5jcHJvdi5sYQ0KbW9kdWxlbG9hZAlsYXN0 YmluZC5sYQ0KbW9kdWxlbG9hZAljb25zdHJhaW50LmxhDQptb2R1bGVsb2FkCXZhbHNvcnQubGEN Cg0KcGlkZmlsZQkJIi9vcHQvb3BlbmxkYXAvdmFyL3J1bi9zbGFwZC5waWQiDQphcmdzZmlsZQki L29wdC9vcGVubGRhcC92YXIvcnVuL3NsYXBkLmFyZ3MiDQoNCnRocmVhZHMgMTYNCg0KaWRsZXRp bWVvdXQgMTgwMA0KcmV2ZXJzZS1sb29rdXAgb2ZmDQoNCmdlbnRsZWh1cCBvbg0KDQp0b29sLXRo cmVhZHMgMQ0KDQpzaXplbGltaXQgdW5saW1pdGVkDQoNClRMU0NpcGhlclN1aXRlIEhJR0g6TUVE SVVNDQoNClRMU0NBQ2VydGlmaWNhdGVGaWxlIDxteXBhdGg+DQpUTFNDZXJ0aWZpY2F0ZUZpbGUg PG15cGF0aD4NClRMU0NlcnRpZmljYXRlS2V5RmlsZSA8bXlwYXRoPg0KVExTVmVyaWZ5Q2xpZW50 IG5ldmVyDQoNCg0KaW5jbHVkZSA8cGF0aF90b19hY2xzX2ZpbGU+DQoNCmRhdGFiYXNlICAgICAg IG1vbml0b3INCnJvb3RkbiAgICAgICAgIGNuPW1vbml0b3INCnJvb3RwdyAgICAgICAgIG15X3Nl Y3JldA0KDQptb25pdG9yaW5nIG9uDQoNCmRhdGFiYXNlICAgICAgICBoZGINCnN1ZmZpeCAgICAg ICAgICAiZGM9bXlfc3VmZml4Ig0Kcm9vdGRuICAgICAgICAgICJjbj1NYW5hZ2VyLGRjPW15X3N1 ZmZpeCINCnJvb3RwdwkJe1NTSEF9bXlfc3NoYV9wYXNzd29yZA0KZGlyZWN0b3J5ICAgICAgIDxt eV9kaXI+DQppbmRleCAgICAgICAgICAgY24gICAgICAgICAgICAgIGVxDQppbmRleCAgICAgICAg ICAgb3UgICAgICAgICAgICAgIGVxDQppbmRleCAgICAgICAgICAgb2JqZWN0Q2xhc3MgICAgIGVx DQppbmRleCAgICAgICAgICAgdWlkICAgICAgICAgICAgIGVxDQppbmRleCAgICAgICAgICAgZ2lk TnVtYmVyICAgICAgIGVxDQppbmRleCAgICAgICAgICAgdWlkTnVtYmVyICAgICAgIGVxDQppbmRl eCAgICAgICAgICAgbWVtYmVyICAgICAgICAgIHByZXMsZXENCmluZGV4ICAgICAgICAgICBtZW1i ZXJVaWQgICAgICAgZXENCmluZGV4CQltZW1iZXJPZgllcQ0KaW5kZXggICAgICAgICAgIGVudHJ5 Q1NOICAgICAgICBlcQ0KaW5kZXggICAgICAgICAgIGVudHJ5VVVJRCAgICAgICBlcQ0KaW5kZXgJ CXVzZXJQYXNzd29yZAlwcmVzDQppbmRleAkJdW5pcXVlTWVtYmVyCWVxDQppbmRleAkJZGVzY3Jp cHRpb24JcHJlcw0KaW5kZXgJCWNzZUFtYmllbnRlCWVxDQppbmRleAkJY3NlV2VibWluQW1iaWVu dGUJZXENCmluZGV4CQljc2VVZmZpY2lvCWVxDQppbmRleAkJY3NlUHJvZ2V0dG8JZXENCmluZGV4 CQljc2VUaXBvR3J1cHBvCWVxDQppbmRleAkJY3NlREIyR3J1cHBpUHJpdmlsZWdpCWVxDQoNCmxp bWl0cyAgICAgICAgICBkbj0iY249TWFuYWdlcixkYz1teV9zdWZmaXgiIHNpemU9dW5saW1pdGVk DQpsaW1pdHMJCWRuPSI8bXlfc3luY3JlcGxfdXNlcnM+IiAgICAgc2l6ZT11bmxpbWl0ZWQNCg0K cmVxdWlyZQkJYXV0aGMgTERBUHYzDQphZGRfY29udGVudF9hY2wJb24NCmNhY2hlc2l6ZSAgICAg ICA0MDAwDQpkbmNhY2hlc2l6ZSAgICAgMA0KaWRsY2FjaGVzaXplICAgIDUwMDAwDQpjYWNoZWZy ZWUgICAgICAgMTANCmNoZWNrcG9pbnQgICAgICAxMDI0IDMwDQpzaG1fa2V5CQkxMDAwDQoNCmRi Y29uZmlnCXNldF9sZ19kaXIJCTxteV9kYmRpcj4NCmRiY29uZmlnCXNldF9sZ19tYXgJCTEwNDg1 NzYwDQpkYmNvbmZpZwlzZXRfbGdfcmVnaW9ubWF4CTI2MjE0NA0KZGJjb25maWcJc2V0X2xnX2Jz aXplCQkyMDk3MTUyDQpkYmNvbmZpZwlzZXRfY2FjaGVzaXplCQkwIDI2ODQzNTQ1NiAxDQpkYmNv bmZpZwlzZXRfbGtfbWF4X29iamVjdHMJMzAwMA0KZGJjb25maWcJc2V0X2xrX21heF9sb2Nrcwkz MDAwDQpkYmNvbmZpZwlzZXRfbGtfbWF4X2xvY2tlcnMJMzAwMA0KZGJjb25maWcJc2V0X2ZsYWdz CQlEQl9MT0dfQVVUT1JFTU9WRQ0KDQpvdmVybGF5IHZhbHNvcnQNCnZhbHNvcnQtYXR0ciBtZW1i ZXJVaWQgb3U9Z3JvdXBzLDxteV9zdWZmaXg+IGFscGhhLWFzY2VuZA0KdmFsc29ydC1hdHRyIG1l bWJlciAgICBvdT1ncm91cHMsPG15X3N1ZmZpeD4gYWxwaGEtYXNjZW5kDQp2YWxzb3J0LWF0dHIg bWVtYmVyVWlkIG91PXNlcnZpY2UsPG15X3N1ZmZpeD4gYWxwaGEtYXNjZW5kDQoNCm92ZXJsYXkg bGFzdGJpbmQNCg0Kb3ZlcmxheSBwcG9saWN5DQpwcG9saWN5X2RlZmF1bHQgY249ZGVmYXVsdCxv dT1Qb2xpY2llcyw8bXlfc3VmZml4Pg0KcHBvbGljeV91c2VfbG9ja291dA0KcHBvbGljeV9oYXNo X2NsZWFydGV4dA0KcHBvbGljeV9mb3J3YXJkX3VwZGF0ZXMNCg0Kb3ZlcmxheSBzeW5jcHJvdg0K c3luY3Byb3YtY2hlY2twb2ludCA1MCAxMA0Kc3luY3Byb3Ytc2Vzc2lvbmxvZyAxNTANCg0Kb3Zl cmxheSBhdWRpdGxvZw0KYXVkaXRsb2cgPHBhdGhfdG9fbXlfYXVkaXRsb2dfZmlsZT4NCg0Kb3Zl cmxheSBtZW1iZXJvZg0KbWVtYmVyb2YtZ3JvdXAtb2MgZ3JvdXBPZk5hbWVzDQptZW1iZXJvZi1t ZW1iZXItYWQgbWVtYmVyDQptZW1iZXJvZi1tZW1iZXJvZi1hZCBtZW1iZXJPZg0KbWVtYmVyb2Yt ZG4gY249TWFuYWdlciw8bXlfc3VmZml4Pg0KbWVtYmVyb2YtZGFuZ2xpbmcgaWdub3JlDQptZW1i ZXJvZi1kYW5nbGluZy1lcnJvciA4MA0KbWVtYmVyb2YtcmVmaW50IEZBTFNFDQoNCm92ZXJsYXkg c3Nzdmx2DQpzc3N2bHYtbWF4IDQNCnNzc3Zsdi1tYXhrZXlzIDUNCg0Kc2VydmVySUQgICAgICAg MDE1DQoNCnN5bmNyZXBsIHJpZD0wMDENCiAgcHJvdmlkZXI9bGRhcDovL215bGRhcDAxDQogIHR5 cGU9cmVmcmVzaEFuZFBlcnNpc3QNCiAgcmV0cnk9IjMwICsiDQogIHNlYXJjaGJhc2U9ImRjPW15 X3N1ZmZpeCINCiAgYXR0cnM9IiosKyINCiAgYmluZGRuPSJjbj1zeW5jcmVwbC1sZGFwMTUsb3U9 bXl0cmVlIg0KICBiaW5kbWV0aG9kPXNpbXBsZQ0KICBjcmVkZW50aWFscz1teV9zZWNyZXQNCiAg dGxzX3JlcWNlcnQ9bmV2ZXINCiAgaW50ZXJ2YWw9MDA6MDA6MDA6MTANCiAgdGltZW91dD0xDQoN CnN5bmNyZXBsIHJpZD0wMDINCiAgcHJvdmlkZXI9bGRhcDovL215bGRhcDAyDQogIHR5cGU9cmVm cmVzaEFuZFBlcnNpc3QNCiAgcmV0cnk9IjMwICsiDQogIHNlYXJjaGJhc2U9ImRjPW15X3N1ZmZp eCINCiAgYXR0cnM9IiosKyINCiAgYmluZGRuPSJjbj1zeW5jcmVwbC1sZGFwMTUsb3U9bXl0cmVl Ig0KICBiaW5kbWV0aG9kPXNpbXBsZQ0KICBjcmVkZW50aWFscz1teV9zZWNyZXQNCiAgdGxzX3Jl cWNlcnQ9bmV2ZXINCiAgaW50ZXJ2YWw9MDA6MDA6MDA6MTANCiAgdGltZW91dD0xDQoNCnN5bmNy ZXBsIHJpZD0wMDMNCiAgcHJvdmlkZXI9bGRhcDovL215bGRhcDAzDQogIHR5cGU9cmVmcmVzaEFu ZFBlcnNpc3QNCiAgcmV0cnk9IjMwICsiDQogIHNlYXJjaGJhc2U9ImRjPW15X3N1ZmZpeCINCiAg YXR0cnM9IiosKyINCiAgYmluZGRuPSJjbj1zeW5jcmVwbC1sZGFwMTUsb3U9bXl0cmVlIg0KICBi aW5kbWV0aG9kPXNpbXBsZQ0KICBjcmVkZW50aWFscz1teV9zZWNyZXQNCiAgdGxzX3JlcWNlcnQ9 bmV2ZXINCiAgaW50ZXJ2YWw9MDA6MDA6MDA6MTANCiAgdGltZW91dD0xDQoNCnN5bmNyZXBsIHJp ZD0wMDMNCiAgcHJvdmlkZXI9bGRhcDovL215bGRhcDAzDQogIHR5cGU9cmVmcmVzaEFuZFBlcnNp c3QNCiAgcmV0cnk9IjMwICsiDQogIHNlYXJjaGJhc2U9ImRjPW15X3N1ZmZpeCINCiAgYXR0cnM9 IiosKyINCiAgYmluZGRuPSJjbj1zeW5jcmVwbC1sZGFwMTUsb3U9bXl0cmVlIg0KICBiaW5kbWV0 aG9kPXNpbXBsZQ0KICBjcmVkZW50aWFscz1teV9zZWNyZXQNCiAgdGxzX3JlcWNlcnQ9bmV2ZXIN CiAgaW50ZXJ2YWw9MDA6MDA6MDA6MTANCiAgdGltZW91dD0xDQoNCm1pcnJvcm1vZGUgICAgIFRS VUUNCg0KbG9nbGV2ZWwgODMyDQo= --20cf300fa9cf6deac304bd27f749 Content-Type: application/octet-stream; name="provider.conf" Content-Disposition: attachment; filename="provider.conf" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h0rx8gti1 aW5jbHVkZSAgICAgICAgIC91c3Ivc2hhcmUvb3BlbmxkYXAyLjQvc2NoZW1hL2NvcmUuc2NoZW1h DQppbmNsdWRlICAgICAgICAgL3Vzci9zaGFyZS9vcGVubGRhcDIuNC9zY2hlbWEvY29zaW5lLnNj aGVtYQ0KaW5jbHVkZSAgICAgICAgIC91c3Ivc2hhcmUvb3BlbmxkYXAyLjQvc2NoZW1hL3Bwb2xp Y3kuc2NoZW1hDQppbmNsdWRlICAgICAgICAgL3Vzci9zaGFyZS9vcGVubGRhcDIuNC9zY2hlbWEv bmlzLnNjaGVtYQ0KaW5jbHVkZSAgICAgICAgIC91c3Ivc2hhcmUvb3BlbmxkYXAyLjQvc2NoZW1h L3JmYzIzMDdiaXMuc2NoZW1hDQppbmNsdWRlICAgICAgICAgL3Vzci9zaGFyZS9vcGVubGRhcDIu NC9zY2hlbWEvaW5ldG9yZ3BlcnNvbi5zY2hlbWENCg0KaW5jbHVkZQkJL2V0Yy9vcGVubGRhcDIu NC9zY2hlbWEvY3VzdG9tLnNjaGVtYQ0KDQptb2R1bGVwYXRoICAgL3Vzci9sb2NhbC9vcGVubGRh cC9saWI2NC8NCm1vZHVsZWxvYWQgbGFzdGJpbmQubGENCg0KcGlkZmlsZSAgICAgICAgIC92YXIv cnVuL2xkYXAyLjQvc2xhcGQucGlkDQphcmdzZmlsZSAgICAgICAgL3Zhci9ydW4vbGRhcDIuNC9z bGFwZC5hcmdzDQp0aHJlYWRzIDE2DQppZGxldGltZW91dCAxODAwDQpyZXZlcnNlLWxvb2t1cCBv ZmYNCmdlbnRsZWh1cCBvbg0KdG9vbC10aHJlYWRzIDMNCnNpemVsaW1pdCB1bmxpbWl0ZWQNCg0K VExTQ2lwaGVyU3VpdGUgSElHSDpNRURJVU0NClRMU0NBQ2VydGlmaWNhdGVGaWxlIDxteV9wYXRo Pg0KVExTQ2VydGlmaWNhdGVGaWxlIDxteV9wYXRoPg0KVExTQ2VydGlmaWNhdGVLZXlGaWxlIDxt eV9wYXRoPg0KVExTVmVyaWZ5Q2xpZW50IG5ldmVyDQoNCmluY2x1ZGUgPHBhdGhfdG9fYWNsc19m aWxlPg0KDQpkYXRhYmFzZSAgICAgICBtb25pdG9yDQpyb290ZG4gICAgICAgICBjbj1tb25pdG9y DQpyb290cHcgICAgICAgICBteV9zZWNyZXQNCg0KbW9uaXRvcmluZyBvbg0KDQpkYXRhYmFzZSAg ICAgICAgaGRiDQpzdWZmaXggICAgICAgICAgImRjPW15X3N1ZmZpeCINCnJvb3RkbiAgICAgICAg ICAiY249TWFuYWdlcixkYz1teV9zdWZmaXgiDQpyb290cHcJCXtTU0hBfW15X3NzaGFfcGFzc3dv cmQNCmRpcmVjdG9yeSAgICAgICA8bXlfZGlyPg0KaW5kZXggICAgICAgICAgIGNuICAgICAgICAg ICAgICBlcQ0KaW5kZXggICAgICAgICAgIG91ICAgICAgICAgICAgICBlcQ0KaW5kZXggICAgICAg ICAgIG9iamVjdENsYXNzICAgICBlcQ0KaW5kZXggICAgICAgICAgIHVpZCAgICAgICAgICAgICBl cQ0KaW5kZXggICAgICAgICAgIGdpZE51bWJlciAgICAgICBlcQ0KaW5kZXggICAgICAgICAgIHVp ZE51bWJlciAgICAgICBlcQ0KaW5kZXggICAgICAgICAgIG1lbWJlciAgICAgICAgICBwcmVzLGVx DQppbmRleCAgICAgICAgICAgbWVtYmVyVWlkICAgICAgIGVxDQppbmRleAkJbWVtYmVyT2YJZXEN CmluZGV4ICAgICAgICAgICBlbnRyeUNTTiAgICAgICAgZXENCmluZGV4ICAgICAgICAgICBlbnRy eVVVSUQgICAgICAgZXENCmluZGV4CQl1c2VyUGFzc3dvcmQJcHJlcw0KaW5kZXgJCXVuaXF1ZU1l bWJlcgllcQ0KaW5kZXgJCWRlc2NyaXB0aW9uCXByZXMNCmluZGV4CQlteUFtYmllbnRlCWVxDQpp bmRleAkJbXlXZWJtaW5BbWJpZW50ZQllcQ0KaW5kZXgJCW15VWZmaWNpbwllcQ0KaW5kZXgJCW15 UHJvZ2V0dG8JZXENCmluZGV4CQlteVRpcG9HcnVwcG8JZXENCmluZGV4CQlteURCMkdydXBwaVBy aXZpbGVnaQllcQ0KDQpsaW1pdHMgICAgICAgICAgZG49ImNuPU1hbmFnZXIsZGM9bXlfc3VmZml4 IiBzaXplPXVubGltaXRlZA0KDQpjYWNoZXNpemUgICAgICAgMzUwMA0KZG5jYWNoZXNpemUgICAg IDANCmlkbGNhY2hlc2l6ZSAgICA1MDAwMA0KY2FjaGVmcmVlICAgICAgIDEwDQpjaGVja3BvaW50 ICAgICAgMTAyNCAzMA0KDQpvdmVybGF5IGxhc3RiaW5kDQoNCm92ZXJsYXkgcHBvbGljeQ0KcHBv bGljeV9kZWZhdWx0IGNuPWRlZmF1bHQsb3U9UG9saWNpZXMsPG15X3N1ZmZpeD4NCnBwb2xpY3lf dXNlX2xvY2tvdXQNCnBwb2xpY3lfaGFzaF9jbGVhcnRleHQNCnBwb2xpY3lfZm9yd2FyZF91cGRh dGVzDQoNCm92ZXJsYXkgc3luY3Byb3YNCnN5bmNwcm92LWNoZWNrcG9pbnQgNTAgMTANCnN5bmNw cm92LXNlc3Npb25sb2cgMTUwDQoNCm92ZXJsYXkgYXVkaXRsb2cNCmF1ZGl0bG9nIDxwYXRoX3Rv X215X2F1ZGl0bG9nX2ZpbGU+DQoNCm92ZXJsYXkgc3Nzdmx2DQpzc3N2bHYtbWF4IDQNCnNzc3Zs di1tYXhrZXlzIDUNCg0Kb3ZlcmxheSBtZW1iZXJvZg0KbWVtYmVyb2YtZ3JvdXAtb2MgZ3JvdXBP Zk5hbWVzDQptZW1iZXJvZi1tZW1iZXItYWQgbWVtYmVyDQptZW1iZXJvZi1tZW1iZXJvZi1hZCBt ZW1iZXJPZg0KbWVtYmVyb2YtZG4gY249TWFuYWdlciw8bXlfc3VmZml4Pg0KbWVtYmVyb2YtZGFu Z2xpbmcgaWdub3JlDQptZW1iZXJvZi1kYW5nbGluZy1lcnJvciA4MA0KbWVtYmVyb2YtcmVmaW50 IEZBTFNFDQoNCnNlcnZlcklEICAgICAgICAwMDENCg0Kc3luY3JlcGwgcmlkPTAwMg0KICBwcm92 aWRlcj1sZGFwOi8vbXlsZGFwMDINCiAgdHlwZT1yZWZyZXNoQW5kUGVyc2lzdA0KICByZXRyeT0i MzAgKyINCiAgc2VhcmNoYmFzZT0iZGM9bXlfc3VmZml4Ig0KICBhdHRycz0iKiwrIg0KICBiaW5k ZG49ImNuPXN5bmNyZXBsLWxkYXAwMSxvdT1teXRyZWUiDQogIGJpbmRtZXRob2Q9c2ltcGxlDQog IGNyZWRlbnRpYWxzPW15X3NlY3JldA0KICB0bHNfcmVxY2VydD1uZXZlcg0KICBpbnRlcnZhbD0w MDowMDowMDoxMA0KICB0aW1lb3V0PTENCg0Kc3luY3JlcGwgcmlkPTAwMw0KICBwcm92aWRlcj1s ZGFwOi8vbXlsZGFwMDMNCiAgdHlwZT1yZWZyZXNoQW5kUGVyc2lzdA0KICByZXRyeT0iMzAgKyIN CiAgc2VhcmNoYmFzZT0iZGM9bXlfc3VmZml4Ig0KICBhdHRycz0iKiwrIg0KICBiaW5kZG49ImNu PXN5bmNyZXBsLWxkYXAwMSxvdT1teXRyZWUiDQogIGJpbmRtZXRob2Q9c2ltcGxlDQogIGNyZWRl bnRpYWxzPW15X3NlY3JldA0KICB0bHNfcmVxY2VydD1uZXZlcg0KICBpbnRlcnZhbD0wMDowMDow MDoxMA0KICB0aW1lb3V0PTENCg0Kc3luY3JlcGwgcmlkPTAwNA0KICBwcm92aWRlcj1sZGFwOi8v bXlsZGFwMDQNCiAgdHlwZT1yZWZyZXNoQW5kUGVyc2lzdA0KICByZXRyeT0iMzAgKyINCiAgc2Vh cmNoYmFzZT0iZGM9bXlfc3VmZml4Ig0KICBhdHRycz0iKiwrIg0KICBiaW5kZG49ImNuPXN5bmNy ZXBsLWxkYXAwMSxvdT1teXRyZWUiDQogIGJpbmRtZXRob2Q9c2ltcGxlDQogIGNyZWRlbnRpYWxz PW15X3NlY3JldA0KICB0bHNfcmVxY2VydD1uZXZlcg0KICBpbnRlcnZhbD0wMDowMDowMDoxMA0K ICB0aW1lb3V0PTENCg0KbWlycm9ybW9kZSAgICAgVFJVRQ0KDQpsb2dsZXZlbCA4MzI= --20cf300fa9cf6deac304bd27f749--

1 0

(ITS#7237) Crash abandoning freed/unused operation
by h.b.furuseth＠usit.uio.no 08 Apr '12

08 Apr '12

Full_Name: Hallvard B Furuseth Version: RE24 + master patches OS: Linux x86_64 URL: http://folk.uio.no/hbf/test045.testrun.tgz Submission from: (NULL) (195.1.106.125) Submitted by: hallvard './run -b ldif test045-syncreplication-proxied' crashed in connection_abandon() with LDAP_MEMORY_DEBUG: It dereferenced o_hdr which is NULL in the uninitialized or freed op 'o'. (op 'o' is full of 0xFF bytes, which I assume is the poiosin from liblber/memory.c.) The code is RE24 + recent master patches: RE24 (0e03b1369f4da5db9d0bdd2445b3a7ccc0c5638f) + ITS#7228 check for unexpected result from ldapsearch + ITS#7231 fix idl_append when b has only 1 element + ITS#7231 simplify prev commit + ITS#7233 Fix slapd listener initialization. + ITS#7234 Fix syncprov entry leak: Set op->o_tag + ITS#7235 prevent sop from being freed during init Configured with --enable-overlays --enable-backends --disable-sql --disable-ndb --enable-cleartext --enable-dynacl --enable-aci --enable-crypt --enable-lmpasswd --enable-spasswd --enable-modules --enable-rlookups --enable-slapi --enable-wrappers CFLAGS="-O0 -g" CPPFLAGS="-DLDAP_MEMORY_DEBUG -DLDAP_THREAD_DEBUG=2 -DUSE_RS_ASSERT". Test output and some GDB trace info enclosed.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs