openldap-bugs April 2012

openldap-bugs@openldap.org

36 participants
172 discussions

Re: (ITS#7088) slapo-accesslog makes OpenLDAP hang
by Pierangelo Masarati 12 Apr '12

12 Apr '12

> The root cause of this bug seems to be related to olcAccessLogOps and > olcAccessLogBase features. If I use one of them to specify I want to log > only "modify" operations: > olcAccessLogOps: modify > or > olcAccessLogBase: modify <suffix> > > Then when I do an "add", slapo-accesslog takes the op_rmutex in > accesslog_op_mod but never release it in accesslog_response. The analysis looks correct. slapo-accesslog(5) was locking the mutex for all write operations, but only releasing it for those that needed to be logged. Should be fixed now in master. Please test. Thanks, p.

1 0

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

12 Apr '12

> ftp://ftp.openldap.org/incoming/jvcelak-120412-moznss-hostname-check.patch The attached file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Red Hat. Red Hat has not assigned rights and/or interest in this work to any party. I, Jan Vcelak am authorized by Red Hat, my employer, to release this work under the following terms. Red Hat hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

(ITS#7241) [PATCH] unbind: free the socket prior to destroying TLS context
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-unbind-free-socket-prior-to-… Submission from: (NULL) (209.132.186.34) Hello. I'm proposing uploaded patch which moves ber_sockbuf_free() prior to ldap_int_tls_destroy() in ldap_ld_free(). I sent the reasoning on the openldap-devel list: http://www.openldap.org/lists/openldap-devel/201204/msg00003.html And there is an answer from Howard: http://www.openldap.org/lists/openldap-devel/201204/msg00004.html Please, consider its inclusion. Jan The attached file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Red Hat. Red Hat has not assigned rights and/or interest in this work to any party. I, Jan Vcelak am authorized by Red Hat, my employer, to release this work under the following terms. Red Hat hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

(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 11 Apr '12

11 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 11 Apr '12

11 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

← Newer
1
...
6
7
8
9
10
11
12
...
18
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs April 2012