- openldap-bugs - openldap.org

Re: (ITS#7636) slapd crash when multi-master replication (syncrepl) enabled
by kb9vqf＠pearsoncomputing.net 09 Jul '13

09 Jul '13

I have done further testing, and it appears that simply enabling a dummy plugin is enough to cause slapd to crash. This plugin code alone is sufficient to cause a crash when syncrepl is enabled: #include "slapi-plugin.h" int plugin_init (Slapi_PBlock *pb); int internal_plugin_init (Slapi_PBlock *pb); __attribute__ ((visibility ("default"))) int plugin_init (Slapi_PBlock *pb) { return 0; } Therefore, it would seem that there is actually a bug in the openldap code, not in a third-party plugin as originally thought. What do you need to investigate this bug further? Thanks!

1 0

Re: (ITS#7638) Handle connection loss in SQL backend
by pierre＠reactos.org 08 Jul '13

08 Jul '13

This is a cryptographically signed message in MIME format. --------------ms090404050901070205030703 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Unfortunately, I don't see any other solution. I browsed everything I=20 could in ODBC doc, in order to be able to query link status, but there's = no way. And the other solution to redo the whole statement in case of failure=20 would be even more complex and would require too many code rewrites due=20 to a complete logic change. So, it seems to me to be the intermediate=20 solution. The overhead being limited on "decent" connection. Regards, On 07/07/2013 14:33, Michael Str=F6der wrote: > pierre(a)reactos.org wrote: >> With this patch, before preparing any req on the given connection=20 >> handle, the >> backend will first try to check whether the connection is active by=20 >> issue a >> dummy query. In case it's not, it will close the previous connection=20 >> and open a >> new one. And then, will prepare the req on the connection link. >> >> I made this choice of developement because, preparing statement,=20 >> executing it >> and then, only looking whether it fails to re-submit would have been=20 >> more >> complex, since it would have required to start over the whole process = >> for the >> query (statement preparation and such) while preparation & execution=20 >> aren't not >> in the same function. > > Hmm, so there's an extra dummy query for each real query. If the SQL=20 > DB is connected over network this means a synchronous extra round trip = > for each query. > > Ciao, Michael. > > --=20 Pierre Schweitzer<pierre at reactos.org> System Administrator ReactOS Foundation --------------ms090404050901070205030703 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMuTCC BjQwggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDI1NVoXDTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOM KqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi 8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8M DP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y 2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR65cdG zTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqp Jw3I07QWke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Mic c/NXcs7kPBRdn6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9Jphw UPTXwHovjavRnhUQHLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMc p+reg9901zkyT3fDW/ivJVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT +HBDYtbuvexNftwNQKD5193A7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1X hwby6mLhkbaXslkVtwEWT3Van49rKjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvO hNz/QplNa+VkIsrcp7+8ZhP1l1b2U6MaxIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC 0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqh AChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H75dVCV33K6FuxZrf09yTz+Vx/PkdRUYk XmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIGfTCCBWWgAwIBAgICKTswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMjExMjEyMDMyNTZa Fw0xNDExMjMwNzI4NTRaMIGZMRkwFwYDVQQNExBBTUdwaXREYlFMMTNWNzBhMQswCQYDVQQG EwJGUjEYMBYGA1UECBMPSGF1dGUtTm9ybWFuZGllMRYwFAYDVQQHEw1Nb250aXZpbGxpZXJz MRowGAYDVQQDExFQaWVycmUgU2Nod2VpdHplcjEhMB8GCSqGSIb3DQEJARYScGllcnJlQHJl YWN0b3Mub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAs6df8jj7p6qV61Nt KQTvsBSsxDKWF1artqGRgk4xj5wxuPcBn7Couffu1uoO/HE8gU6JIcac+Yy9gHnZmVak91qR 6BMXdMZmS4Pw42J1v9jUIps0uLCUL+ERIgC6Czrnr+RVGyL49ybXsUjq0SMGpM65K7W3hc6l 52R94XIDDZX5tSC8ykvnnsgDv8A4YubKhJYTO3G285Dw2gcIxf/Zg1AE7fBCAx+Eahqly7DP MEP1tH66Xs9jUXwWH/LuuHh1qCEOMeVf2QiiFVa1DqY5bWaRJFmOHsSJ/UVA+o/fF3MWpDZy xLnf2Ia4cUW4D0xP6po0BJLxg3J7Zz83K3dH1QIDAQABo4IC2DCCAtQwCQYDVR0TBAIwADAL BgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSj smXI/ofbH9TM2n4vCg+ffljF9jAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzAd BgNVHREEFjAUgRJwaWVycmVAcmVhY3Rvcy5vcmcwggFMBgNVHSAEggFDMIIBPzCCATsGCysG AQQBgbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9s aWN5LnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRo b3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcgdG8g dGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29tIENB IHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wNgYDVR0fBC8wLTAr oCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUH AQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFz czIvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0 cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQCFeXbRYRXSXj+qOhO84ZVGZXb6YQ9NEp2A 3nFDOJke+FH2id3lkuWYze89znDRekvta51EhuLtgpwK2AmWQqnN6NoCuAjJNRBZ+/NourxM S8nn+pyFFTXBbErFAHIO6iOZw0voScHJXfodxPfwc5aP5HTWasbszXzG1Q4uwtj6ZcTU5r0a 21Gt5bBb58II39yk8/mWuxI+gTUgbAt67cMvdJGH0aEZc9XTSKSYRp3kXtBeQ23LMJnxAjIo q/Q8vaCMb6EHJ6Kkz0Fdmxjxpqg+Dop1YtgaaDspSY0f2qkrxhwqGpSXfk+Du8YDXqD2nMCi qoQTrGpdI6q2d5i0PM2sMYICiTCCAoUCAQEwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQQICKTswCQYFKw4DAhoFAKCByzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0xMzA3MDgxNzI5NDJaMCMGCSqGSIb3DQEJBDEWBBSp4weucVM5 IASlCKMvHRpm39/eKzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQME AQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIH MA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABIIBAHaoWj/CjXJf1TfekN650kEwojD+ 0HYA3EV5/s6SYHeaOi8ZM1bd6ykJGEd6ehajWoW12jBXq+ibH5QcO6hv49nxMNGpZ5m1dF1w 7yTs3X1ZaZx0A5UfmYMS8Hk2nxgiO/IG0K07CEJiMfggEBP5JdeMdlhmdMJv5TmV+lnIiIeI jH06JJXDVq33qFRdFt0CbaOISDlddXp9/OEtHHp818TiD9Vh12v/jqzD8BxHQr0+zDFoPZPY 2f30Donz/mj/cWWBBmuVCrULgW8fL59BM02MaX6O9BdAb1paBVvAVXy/TkuwzlRPu4yo8rew H2iLVVcdyL+DGqCGqoZiLYAym4kAAAAAAAA= --------------ms090404050901070205030703--

1 0

(ITS#7639) test062-config-delete intermittently succeeds
by rsbx＠acm.org 07 Jul '13

07 Jul '13

Full_Name: Raymond S Brand Version: 60720f5d9cdc19092d0aad6b0a94e196e5525d1c OS: Debian Wheezy amd64 URL: Submission from: (NULL) (50.88.155.14) When run with the bdb, hdb, and mdb backends, test062-config-delete intermittently succeeds but more often than not it fails. It is the only test that has failed in my testing. Test system, a VirtualBox instance: Linux LDAP 3.2.0-4-amd64 #1 SMP Debian 3.2.46-1 x86_64 GNU/Linux 2 VCPUs; 1.5GB VirtualBox host system: Linux LDAP 3.2.0-4-amd64 #1 SMP Debian 3.2.46-1 x86_64 GNU/Linux 2 CPUs (Core 2 Duo); 8GB Both O/S's are current with respect to Debian updates. Build options: ../../configure --prefix=/tmp/ol --enable-perl --enable-overlays --enable-bdb When run with full logging, the last line of the server log file appeared to be corrupted. This is a sample run: XXXX$ ./run -b mdb test062-config-delete Cleaning up test run directory leftover from previous run. Running ../../../tests/scripts/test062-config-delete for mdb... running defines.sh Starting slapd on TCP/IP port 9011... /home/internet/Projects/OpenLDAP/openldap/BUILD/t2/tests Using ldapsearch to check that slapd is running... Waiting 5 seconds for slapd to start... Inserting syncprov overlay ... Starting a refreshAndPersist search in background Removing syncprov overlay again ... Waiting 2 seconds for RefreshAndPersist search to end ... Checking return code of backgrounded RefreshAndPersist search ... Exit code correct. Running a refreshOnly search, should fail... ldapsearch should have failed with Critical extension is unavailable (12)! ../../../tests/scripts/test062-config-delete: 164: kill: No such process XXXX$ The following is the output from valgrind for the above run. Valgrind was used specifically to aid in creating this bug report; it is not part of my normal testing of this software. ==2454== Memcheck, a memory error detector ==2454== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. ==2454== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info ==2454== Command: /home/internet/Projects/OpenLDAP/openldap/BUILD/t2/tests/../servers/slapd/slapd -s0 -F ./slapd.d -h ldap://localhost:9011/ -d 0x4105 ==2454== Parent PID: 2442 ==2454== ==2454== Thread 4: ==2454== Invalid read of size 8 ==2454== at 0x45006E: send_ldap_response (result.c:704) ==2454== by 0x4508E5: slap_send_ldap_result (result.c:844) ==2454== by 0x5572BB: syncprov_db_close (syncprov.c:3178) ==2454== by 0x4A6B5A: overlay_remove_cb (backover.c:1189) ==2454== by 0x44F93A: slap_cleanup_play (result.c:525) ==2454== by 0x44FD99: send_ldap_response (result.c:717) ==2454== by 0x4508E5: slap_send_ldap_result (result.c:844) ==2454== by 0x42F7C4: config_back_delete (bconfig.c:6481) ==2454== by 0x4A75F2: overlay_op_walk (backover.c:691) ==2454== by 0x4A7734: over_op_func (backover.c:743) ==2454== by 0x45931F: fe_op_delete (delete.c:174) ==2454== by 0x45904C: do_delete (delete.c:95) ==2454== Address 0xa23cc80 is 0 bytes inside a block of size 758 free'd ==2454== at 0x4C27D4E: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==2454== by 0x555F5B: syncprov_free_syncop (syncprov.c:814) ==2454== by 0x555FE5: syncprov_drop_psearch (syncprov.c:1109) ==2454== by 0x556141: syncprov_op_abandon (syncprov.c:1158) ==2454== by 0x45E0A6: fe_op_abandon (abandon.c:136) ==2454== by 0x43EBFB: connection_abandon (connection.c:747) ==2454== by 0x4403B8: connection_closing (connection.c:820) ==2454== by 0x440EBA: connection_read_thread (connection.c:1476) ==2454== by 0x573917: ldap_int_thread_pool_wrapper (tpool.c:688) ==2454== by 0x59BFB4F: start_thread (pthread_create.c:304) ==2454== by 0x8039A7C: clone (clone.S:112) ==2454== ==2454== Invalid read of size 8 ==2454== at 0x450072: send_ldap_response (result.c:704) ==2454== by 0x4508E5: slap_send_ldap_result (result.c:844) ==2454== by 0x5572BB: syncprov_db_close (syncprov.c:3178) ==2454== by 0x4A6B5A: overlay_remove_cb (backover.c:1189) ==2454== by 0x44F93A: slap_cleanup_play (result.c:525) ==2454== by 0x44FD99: send_ldap_response (result.c:717) ==2454== by 0x4508E5: slap_send_ldap_result (result.c:844) ==2454== by 0x42F7C4: config_back_delete (bconfig.c:6481) ==2454== by 0x4A75F2: overlay_op_walk (backover.c:691) ==2454== by 0x4A7734: over_op_func (backover.c:743) ==2454== by 0x45931F: fe_op_delete (delete.c:174) ==2454== by 0x45904C: do_delete (delete.c:95) ==2454== Address 0xa23ce30 is 432 bytes inside a block of size 758 free'd ==2454== at 0x4C27D4E: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==2454== by 0x555F5B: syncprov_free_syncop (syncprov.c:814) ==2454== by 0x555FE5: syncprov_drop_psearch (syncprov.c:1109) ==2454== by 0x556141: syncprov_op_abandon (syncprov.c:1158) ==2454== by 0x45E0A6: fe_op_abandon (abandon.c:136) ==2454== by 0x43EBFB: connection_abandon (connection.c:747) ==2454== by 0x4403B8: connection_closing (connection.c:820) ==2454== by 0x440EBA: connection_read_thread (connection.c:1476) ==2454== by 0x573917: ldap_int_thread_pool_wrapper (tpool.c:688) ==2454== by 0x59BFB4F: start_thread (pthread_create.c:304) ==2454== by 0x8039A7C: clone (clone.S:112) ==2454== ==2454== Invalid read of size 8 ==2454== at 0x45007F: send_ldap_response (result.c:705) ==2454== by 0x4508E5: slap_send_ldap_result (result.c:844) ==2454== by 0x5572BB: syncprov_db_close (syncprov.c:3178) ==2454== by 0x4A6B5A: overlay_remove_cb (backover.c:1189) ==2454== by 0x44F93A: slap_cleanup_play (result.c:525) ==2454== by 0x44FD99: send_ldap_response (result.c:717) ==2454== by 0x4508E5: slap_send_ldap_result (result.c:844) ==2454== by 0x42F7C4: config_back_delete (bconfig.c:6481) ==2454== by 0x4A75F2: overlay_op_walk (backover.c:691) ==2454== by 0x4A7734: over_op_func (backover.c:743) ==2454== by 0x45931F: fe_op_delete (delete.c:174) ==2454== by 0x45904C: do_delete (delete.c:95) ==2454== Address 0xa23cc80 is 0 bytes inside a block of size 758 free'd ==2454== at 0x4C27D4E: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==2454== by 0x555F5B: syncprov_free_syncop (syncprov.c:814) ==2454== by 0x555FE5: syncprov_drop_psearch (syncprov.c:1109) ==2454== by 0x556141: syncprov_op_abandon (syncprov.c:1158) ==2454== by 0x45E0A6: fe_op_abandon (abandon.c:136) ==2454== by 0x43EBFB: connection_abandon (connection.c:747) ==2454== by 0x4403B8: connection_closing (connection.c:820) ==2454== by 0x440EBA: connection_read_thread (connection.c:1476) ==2454== by 0x573917: ldap_int_thread_pool_wrapper (tpool.c:688) ==2454== by 0x59BFB4F: start_thread (pthread_create.c:304) ==2454== by 0x8039A7C: clone (clone.S:112) ==2454== ==2454== Invalid read of size 8 ==2454== at 0x450083: send_ldap_response (result.c:705) ==2454== by 0x4508E5: slap_send_ldap_result (result.c:844) ==2454== by 0x5572BB: syncprov_db_close (syncprov.c:3178) ==2454== by 0x4A6B5A: overlay_remove_cb (backover.c:1189) ==2454== by 0x44F93A: slap_cleanup_play (result.c:525) ==2454== by 0x44FD99: send_ldap_response (result.c:717) ==2454== by 0x4508E5: slap_send_ldap_result (result.c:844) ==2454== by 0x42F7C4: config_back_delete (bconfig.c:6481) ==2454== by 0x4A75F2: overlay_op_walk (backover.c:691) ==2454== by 0x4A7734: over_op_func (backover.c:743) ==2454== by 0x45931F: fe_op_delete (delete.c:174) ==2454== by 0x45904C: do_delete (delete.c:95) ==2454== Address 0xa23ce30 is 432 bytes inside a block of size 758 free'd ==2454== at 0x4C27D4E: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==2454== by 0x555F5B: syncprov_free_syncop (syncprov.c:814) ==2454== by 0x555FE5: syncprov_drop_psearch (syncprov.c:1109) ==2454== by 0x556141: syncprov_op_abandon (syncprov.c:1158) ==2454== by 0x45E0A6: fe_op_abandon (abandon.c:136) ==2454== by 0x43EBFB: connection_abandon (connection.c:747) ==2454== by 0x4403B8: connection_closing (connection.c:820) ==2454== by 0x440EBA: connection_read_thread (connection.c:1476) ==2454== by 0x573917: ldap_int_thread_pool_wrapper (tpool.c:688) ==2454== by 0x59BFB4F: start_thread (pthread_create.c:304) ==2454== by 0x8039A7C: clone (clone.S:112) ==2454== ==2454== Invalid read of size 8 ==2454== at 0x44FD85: send_ldap_response (result.c:716) ==2454== by 0x4508E5: slap_send_ldap_result (result.c:844) ==2454== by 0x5572BB: syncprov_db_close (syncprov.c:3178) ==2454== by 0x4A6B5A: overlay_remove_cb (backover.c:1189) ==2454== by 0x44F93A: slap_cleanup_play (result.c:525) ==2454== by 0x44FD99: send_ldap_response (result.c:717) ==2454== by 0x4508E5: slap_send_ldap_result (result.c:844) ==2454== by 0x42F7C4: config_back_delete (bconfig.c:6481) ==2454== by 0x4A75F2: overlay_op_walk (backover.c:691) ==2454== by 0x4A7734: over_op_func (backover.c:743) ==2454== by 0x45931F: fe_op_delete (delete.c:174) ==2454== by 0x45904C: do_delete (delete.c:95) ==2454== Address 0xa23cdb8 is 312 bytes inside a block of size 758 free'd ==2454== at 0x4C27D4E: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==2454== by 0x555F5B: syncprov_free_syncop (syncprov.c:814) ==2454== by 0x555FE5: syncprov_drop_psearch (syncprov.c:1109) ==2454== by 0x556141: syncprov_op_abandon (syncprov.c:1158) ==2454== by 0x45E0A6: fe_op_abandon (abandon.c:136) ==2454== by 0x43EBFB: connection_abandon (connection.c:747) ==2454== by 0x4403B8: connection_closing (connection.c:820) ==2454== by 0x440EBA: connection_read_thread (connection.c:1476) ==2454== by 0x573917: ldap_int_thread_pool_wrapper (tpool.c:688) ==2454== by 0x59BFB4F: start_thread (pthread_create.c:304) ==2454== by 0x8039A7C: clone (clone.S:112) ==2454== ==2454== Invalid read of size 8 ==2454== at 0x450B28: slap_send_ldap_result (result.c:845) ==2454== by 0x5572BB: syncprov_db_close (syncprov.c:3178) ==2454== by 0x4A6B5A: overlay_remove_cb (backover.c:1189) ==2454== by 0x44F93A: slap_cleanup_play (result.c:525) ==2454== by 0x44FD99: send_ldap_response (result.c:717) ==2454== by 0x4508E5: slap_send_ldap_result (result.c:844) ==2454== by 0x42F7C4: config_back_delete (bconfig.c:6481) ==2454== by 0x4A75F2: overlay_op_walk (backover.c:691) ==2454== by 0x4A7734: over_op_func (backover.c:743) ==2454== by 0x45931F: fe_op_delete (delete.c:174) ==2454== by 0x45904C: do_delete (delete.c:95) ==2454== by 0x4407E2: connection_operation (connection.c:1155) ==2454== Address 0xa23cc88 is 8 bytes inside a block of size 758 free'd ==2454== at 0x4C27D4E: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==2454== by 0x555F5B: syncprov_free_syncop (syncprov.c:814) ==2454== by 0x555FE5: syncprov_drop_psearch (syncprov.c:1109) ==2454== by 0x556141: syncprov_op_abandon (syncprov.c:1158) ==2454== by 0x45E0A6: fe_op_abandon (abandon.c:136) ==2454== by 0x43EBFB: connection_abandon (connection.c:747) ==2454== by 0x4403B8: connection_closing (connection.c:820) ==2454== by 0x440EBA: connection_read_thread (connection.c:1476) ==2454== by 0x573917: ldap_int_thread_pool_wrapper (tpool.c:688) ==2454== by 0x59BFB4F: start_thread (pthread_create.c:304) ==2454== by 0x8039A7C: clone (clone.S:112) ==2454== ==2454== Invalid read of size 8 ==2454== at 0x450CD1: slap_send_ldap_result (result.c:846) ==2454== by 0x5572BB: syncprov_db_close (syncprov.c:3178) ==2454== by 0x4A6B5A: overlay_remove_cb (backover.c:1189) ==2454== by 0x44F93A: slap_cleanup_play (result.c:525) ==2454== by 0x44FD99: send_ldap_response (result.c:717) ==2454== by 0x4508E5: slap_send_ldap_result (result.c:844) ==2454== by 0x42F7C4: config_back_delete (bconfig.c:6481) ==2454== by 0x4A75F2: overlay_op_walk (backover.c:691) ==2454== by 0x4A7734: over_op_func (backover.c:743) ==2454== by 0x45931F: fe_op_delete (delete.c:174) ==2454== by 0x45904C: do_delete (delete.c:95) ==2454== by 0x4407E2: connection_operation (connection.c:1155) ==2454== Address 0xa23cc80 is 0 bytes inside a block of size 758 free'd ==2454== at 0x4C27D4E: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==2454== by 0x555F5B: syncprov_free_syncop (syncprov.c:814) ==2454== by 0x555FE5: syncprov_drop_psearch (syncprov.c:1109) ==2454== by 0x556141: syncprov_op_abandon (syncprov.c:1158) ==2454== by 0x45E0A6: fe_op_abandon (abandon.c:136) ==2454== by 0x43EBFB: connection_abandon (connection.c:747) ==2454== by 0x4403B8: connection_closing (connection.c:820) ==2454== by 0x440EBA: connection_read_thread (connection.c:1476) ==2454== by 0x573917: ldap_int_thread_pool_wrapper (tpool.c:688) ==2454== by 0x59BFB4F: start_thread (pthread_create.c:304) ==2454== by 0x8039A7C: clone (clone.S:112) ==2454== ==2454== Invalid read of size 1 ==2454== at 0x7FA4CBA: vfprintf (vfprintf.c:1623) ==2454== by 0x7FCB6A1: vsnprintf (vsnprintf.c:120) ==2454== by 0x59D492: lutil_debug (debug.c:67) ==2454== by 0x450D03: slap_send_ldap_result (result.c:846) ==2454== by 0x5572BB: syncprov_db_close (syncprov.c:3178) ==2454== by 0x4A6B5A: overlay_remove_cb (backover.c:1189) ==2454== by 0x44F93A: slap_cleanup_play (result.c:525) ==2454== by 0x44FD99: send_ldap_response (result.c:717) ==2454== by 0x4508E5: slap_send_ldap_result (result.c:844) ==2454== by 0x42F7C4: config_back_delete (bconfig.c:6481) ==2454== by 0x4A75F2: overlay_op_walk (backover.c:691) ==2454== by 0x4A7734: over_op_func (backover.c:743) ==2454== Address 0xa23ce38 is 440 bytes inside a block of size 758 free'd ==2454== at 0x4C27D4E: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==2454== by 0x555F5B: syncprov_free_syncop (syncprov.c:814) ==2454== by 0x555FE5: syncprov_drop_psearch (syncprov.c:1109) ==2454== by 0x556141: syncprov_op_abandon (syncprov.c:1158) ==2454== by 0x45E0A6: fe_op_abandon (abandon.c:136) ==2454== by 0x43EBFB: connection_abandon (connection.c:747) ==2454== by 0x4403B8: connection_closing (connection.c:820) ==2454== by 0x440EBA: connection_read_thread (connection.c:1476) ==2454== by 0x573917: ldap_int_thread_pool_wrapper (tpool.c:688) ==2454== by 0x59BFB4F: start_thread (pthread_create.c:304) ==2454== by 0x8039A7C: clone (clone.S:112) ==2454== ==2454== Invalid read of size 1 ==2454== at 0x7FD4480: _IO_default_xsputn (genops.c:480) ==2454== by 0x7FA4B82: vfprintf (vfprintf.c:1623) ==2454== by 0x7FCB6A1: vsnprintf (vsnprintf.c:120) ==2454== by 0x59D492: lutil_debug (debug.c:67) ==2454== by 0x450D03: slap_send_ldap_result (result.c:846) ==2454== by 0x5572BB: syncprov_db_close (syncprov.c:3178) ==2454== by 0x4A6B5A: overlay_remove_cb (backover.c:1189) ==2454== by 0x44F93A: slap_cleanup_play (result.c:525) ==2454== by 0x44FD99: send_ldap_response (result.c:717) ==2454== by 0x4508E5: slap_send_ldap_result (result.c:844) ==2454== by 0x42F7C4: config_back_delete (bconfig.c:6481) ==2454== by 0x4A75F2: overlay_op_walk (backover.c:691) ==2454== Address 0xa23ce38 is 440 bytes inside a block of size 758 free'd ==2454== at 0x4C27D4E: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==2454== by 0x555F5B: syncprov_free_syncop (syncprov.c:814) ==2454== by 0x555FE5: syncprov_drop_psearch (syncprov.c:1109) ==2454== by 0x556141: syncprov_op_abandon (syncprov.c:1158) ==2454== by 0x45E0A6: fe_op_abandon (abandon.c:136) ==2454== by 0x43EBFB: connection_abandon (connection.c:747) ==2454== by 0x4403B8: connection_closing (connection.c:820) ==2454== by 0x440EBA: connection_read_thread (connection.c:1476) ==2454== by 0x573917: ldap_int_thread_pool_wrapper (tpool.c:688) ==2454== by 0x59BFB4F: start_thread (pthread_create.c:304) ==2454== by 0x8039A7C: clone (clone.S:112) ==2454== ==2454== Invalid read of size 1 ==2454== at 0x7FD4492: _IO_default_xsputn (genops.c:479) ==2454== by 0x7FA4B82: vfprintf (vfprintf.c:1623) ==2454== by 0x7FCB6A1: vsnprintf (vsnprintf.c:120) ==2454== by 0x59D492: lutil_debug (debug.c:67) ==2454== by 0x450D03: slap_send_ldap_result (result.c:846) ==2454== by 0x5572BB: syncprov_db_close (syncprov.c:3178) ==2454== by 0x4A6B5A: overlay_remove_cb (backover.c:1189) ==2454== by 0x44F93A: slap_cleanup_play (result.c:525) ==2454== by 0x44FD99: send_ldap_response (result.c:717) ==2454== by 0x4508E5: slap_send_ldap_result (result.c:844) ==2454== by 0x42F7C4: config_back_delete (bconfig.c:6481) ==2454== by 0x4A75F2: overlay_op_walk (backover.c:691) ==2454== Address 0xa23ce3a is 442 bytes inside a block of size 758 free'd ==2454== at 0x4C27D4E: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==2454== by 0x555F5B: syncprov_free_syncop (syncprov.c:814) ==2454== by 0x555FE5: syncprov_drop_psearch (syncprov.c:1109) ==2454== by 0x556141: syncprov_op_abandon (syncprov.c:1158) ==2454== by 0x45E0A6: fe_op_abandon (abandon.c:136) ==2454== by 0x43EBFB: connection_abandon (connection.c:747) ==2454== by 0x4403B8: connection_closing (connection.c:820) ==2454== by 0x440EBA: connection_read_thread (connection.c:1476) ==2454== by 0x573917: ldap_int_thread_pool_wrapper (tpool.c:688) ==2454== by 0x59BFB4F: start_thread (pthread_create.c:304) ==2454== by 0x8039A7C: clone (clone.S:112) ==2454== ==2454== Invalid read of size 8 ==2454== at 0x5572BC: syncprov_db_close (syncprov.c:3179) ==2454== by 0x4A6B5A: overlay_remove_cb (backover.c:1189) ==2454== by 0x44F93A: slap_cleanup_play (result.c:525) ==2454== by 0x44FD99: send_ldap_response (result.c:717) ==2454== by 0x4508E5: slap_send_ldap_result (result.c:844) ==2454== by 0x42F7C4: config_back_delete (bconfig.c:6481) ==2454== by 0x4A75F2: overlay_op_walk (backover.c:691) ==2454== by 0x4A7734: over_op_func (backover.c:743) ==2454== by 0x45931F: fe_op_delete (delete.c:174) ==2454== by 0x45904C: do_delete (delete.c:95) ==2454== by 0x4407E2: connection_operation (connection.c:1155) ==2454== by 0x440C1D: connection_read_thread (connection.c:1291) ==2454== Address 0xa23cbc0 is 0 bytes inside a block of size 128 free'd ==2454== at 0x4C27D4E: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==2454== by 0x555FE5: syncprov_drop_psearch (syncprov.c:1109) ==2454== by 0x556141: syncprov_op_abandon (syncprov.c:1158) ==2454== by 0x45E0A6: fe_op_abandon (abandon.c:136) ==2454== by 0x43EBFB: connection_abandon (connection.c:747) ==2454== by 0x4403B8: connection_closing (connection.c:820) ==2454== by 0x440EBA: connection_read_thread (connection.c:1476) ==2454== by 0x573917: ldap_int_thread_pool_wrapper (tpool.c:688) ==2454== by 0x59BFB4F: start_thread (pthread_create.c:304) ==2454== by 0x8039A7C: clone (clone.S:112) ==2454== ==2454== Invalid read of size 1 ==2454== at 0x555F78: syncprov_drop_psearch (syncprov.c:1099) ==2454== by 0x5572C8: syncprov_db_close (syncprov.c:3180) ==2454== by 0x4A6B5A: overlay_remove_cb (backover.c:1189) ==2454== by 0x44F93A: slap_cleanup_play (result.c:525) ==2454== by 0x44FD99: send_ldap_response (result.c:717) ==2454== by 0x4508E5: slap_send_ldap_result (result.c:844) ==2454== by 0x42F7C4: config_back_delete (bconfig.c:6481) ==2454== by 0x4A75F2: overlay_op_walk (backover.c:691) ==2454== by 0x4A7734: over_op_func (backover.c:743) ==2454== by 0x45931F: fe_op_delete (delete.c:174) ==2454== by 0x45904C: do_delete (delete.c:95) ==2454== by 0x4407E2: connection_operation (connection.c:1155) ==2454== Address 0xa23cc00 is 64 bytes inside a block of size 128 free'd ==2454== at 0x4C27D4E: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==2454== by 0x555FE5: syncprov_drop_psearch (syncprov.c:1109) ==2454== by 0x556141: syncprov_op_abandon (syncprov.c:1158) ==2454== by 0x45E0A6: fe_op_abandon (abandon.c:136) ==2454== by 0x43EBFB: connection_abandon (connection.c:747) ==2454== by 0x4403B8: connection_closing (connection.c:820) ==2454== by 0x440EBA: connection_read_thread (connection.c:1476) ==2454== by 0x573917: ldap_int_thread_pool_wrapper (tpool.c:688) ==2454== by 0x59BFB4F: start_thread (pthread_create.c:304) ==2454== by 0x8039A7C: clone (clone.S:112) ==2454== ==2454== Invalid read of size 8 ==2454== at 0x555F86: syncprov_drop_psearch (syncprov.c:1102) ==2454== by 0x5572C8: syncprov_db_close (syncprov.c:3180) ==2454== by 0x4A6B5A: overlay_remove_cb (backover.c:1189) ==2454== by 0x44F93A: slap_cleanup_play (result.c:525) ==2454== by 0x44FD99: send_ldap_response (result.c:717) ==2454== by 0x4508E5: slap_send_ldap_result (result.c:844) ==2454== by 0x42F7C4: config_back_delete (bconfig.c:6481) ==2454== by 0x4A75F2: overlay_op_walk (backover.c:691) ==2454== by 0x4A7734: over_op_func (backover.c:743) ==2454== by 0x45931F: fe_op_delete (delete.c:174) ==2454== by 0x45904C: do_delete (delete.c:95) ==2454== by 0x4407E2: connection_operation (connection.c:1155) ==2454== Address 0xa23cbe0 is 32 bytes inside a block of size 128 free'd ==2454== at 0x4C27D4E: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==2454== by 0x555FE5: syncprov_drop_psearch (syncprov.c:1109) ==2454== by 0x556141: syncprov_op_abandon (syncprov.c:1158) ==2454== by 0x45E0A6: fe_op_abandon (abandon.c:136) ==2454== by 0x43EBFB: connection_abandon (connection.c:747) ==2454== by 0x4403B8: connection_closing (connection.c:820) ==2454== by 0x440EBA: connection_read_thread (connection.c:1476) ==2454== by 0x573917: ldap_int_thread_pool_wrapper (tpool.c:688) ==2454== by 0x59BFB4F: start_thread (pthread_create.c:304) ==2454== by 0x8039A7C: clone (clone.S:112) ==2454== ==2454== Invalid read of size 8 ==2454== at 0x555F8A: syncprov_drop_psearch (syncprov.c:1102) ==2454== by 0x5572C8: syncprov_db_close (syncprov.c:3180) ==2454== by 0x4A6B5A: overlay_remove_cb (backover.c:1189) ==2454== by 0x44F93A: slap_cleanup_play (result.c:525) ==2454== by 0x44FD99: send_ldap_response (result.c:717) ==2454== by 0x4508E5: slap_send_ldap_result (result.c:844) ==2454== by 0x42F7C4: config_back_delete (bconfig.c:6481) ==2454== by 0x4A75F2: overlay_op_walk (backover.c:691) ==2454== by 0x4A7734: over_op_func (backover.c:743) ==2454== by 0x45931F: fe_op_delete (delete.c:174) ==2454== by 0x45904C: do_delete (delete.c:95) ==2454== by 0x4407E2: connection_operation (connection.c:1155) ==2454== Address 0xa23cc80 is 0 bytes inside a block of size 758 free'd ==2454== at 0x4C27D4E: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==2454== by 0x555F5B: syncprov_free_syncop (syncprov.c:814) ==2454== by 0x555FE5: syncprov_drop_psearch (syncprov.c:1109) ==2454== by 0x556141: syncprov_op_abandon (syncprov.c:1158) ==2454== by 0x45E0A6: fe_op_abandon (abandon.c:136) ==2454== by 0x43EBFB: connection_abandon (connection.c:747) ==2454== by 0x4403B8: connection_closing (connection.c:820) ==2454== by 0x440EBA: connection_read_thread (connection.c:1476) ==2454== by 0x573917: ldap_int_thread_pool_wrapper (tpool.c:688) ==2454== by 0x59BFB4F: start_thread (pthread_create.c:304) ==2454== by 0x8039A7C: clone (clone.S:112) ==2454== ==2454== Invalid read of size 8 ==2454== at 0x555F8D: syncprov_drop_psearch (syncprov.c:1102) ==2454== by 0x5572C8: syncprov_db_close (syncprov.c:3180) ==2454== by 0x4A6B5A: overlay_remove_cb (backover.c:1189) ==2454== by 0x44F93A: slap_cleanup_play (result.c:525) ==2454== by 0x44FD99: send_ldap_response (result.c:717) ==2454== by 0x4508E5: slap_send_ldap_result (result.c:844) ==2454== by 0x42F7C4: config_back_delete (bconfig.c:6481) ==2454== by 0x4A75F2: overlay_op_walk (backover.c:691) ==2454== by 0x4A7734: over_op_func (backover.c:743) ==2454== by 0x45931F: fe_op_delete (delete.c:174) ==2454== by 0x45904C: do_delete (delete.c:95) ==2454== by 0x4407E2: connection_operation (connection.c:1155) ==2454== Address 0xa23ce00 is 384 bytes inside a block of size 758 free'd ==2454== at 0x4C27D4E: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==2454== by 0x555F5B: syncprov_free_syncop (syncprov.c:814) ==2454== by 0x555FE5: syncprov_drop_psearch (syncprov.c:1109) ==2454== by 0x556141: syncprov_op_abandon (syncprov.c:1158) ==2454== by 0x45E0A6: fe_op_abandon (abandon.c:136) ==2454== by 0x43EBFB: connection_abandon (connection.c:747) ==2454== by 0x4403B8: connection_closing (connection.c:820) ==2454== by 0x440EBA: connection_read_thread (connection.c:1476) ==2454== by 0x573917: ldap_int_thread_pool_wrapper (tpool.c:688) ==2454== by 0x59BFB4F: start_thread (pthread_create.c:304) ==2454== by 0x8039A7C: clone (clone.S:112) ==2454== ==2454== Invalid read of size 8 ==2454== at 0x555FBB: syncprov_drop_psearch (syncprov.c:1104) ==2454== by 0x5572C8: syncprov_db_close (syncprov.c:3180) ==2454== by 0x4A6B5A: overlay_remove_cb (backover.c:1189) ==2454== by 0x44F93A: slap_cleanup_play (result.c:525) ==2454== by 0x44FD99: send_ldap_response (result.c:717) ==2454== by 0x4508E5: slap_send_ldap_result (result.c:844) ==2454== by 0x42F7C4: config_back_delete (bconfig.c:6481) ==2454== by 0x4A75F2: overlay_op_walk (backover.c:691) ==2454== by 0x4A7734: over_op_func (backover.c:743) ==2454== by 0x45931F: fe_op_delete (delete.c:174) ==2454== by 0x45904C: do_delete (delete.c:95) ==2454== by 0x4407E2: connection_operation (connection.c:1155) ==2454== Address 0x168 is not stack'd, malloc'd or (recently) free'd ==2454== ==2454== ==2454== Process terminating with default action of signal 11 (SIGSEGV) ==2454== Access not within mapped region at address 0x168 ==2454== at 0x555FBB: syncprov_drop_psearch (syncprov.c:1104) ==2454== by 0x5572C8: syncprov_db_close (syncprov.c:3180) ==2454== by 0x4A6B5A: overlay_remove_cb (backover.c:1189) ==2454== by 0x44F93A: slap_cleanup_play (result.c:525) ==2454== by 0x44FD99: send_ldap_response (result.c:717) ==2454== by 0x4508E5: slap_send_ldap_result (result.c:844) ==2454== by 0x42F7C4: config_back_delete (bconfig.c:6481) ==2454== by 0x4A75F2: overlay_op_walk (backover.c:691) ==2454== by 0x4A7734: over_op_func (backover.c:743) ==2454== by 0x45931F: fe_op_delete (delete.c:174) ==2454== by 0x45904C: do_delete (delete.c:95) ==2454== by 0x4407E2: connection_operation (connection.c:1155) ==2454== If you believe this happened as a result of a stack ==2454== overflow in your program's main thread (unlikely but ==2454== possible), you can try to increase the size of the ==2454== main thread stack using the --main-stacksize= flag. ==2454== The main thread stack size used in this run was 8388608. ==2454== ==2454== HEAP SUMMARY: ==2454== in use at exit: 6,002,487 bytes in 13,317 blocks ==2454== total heap usage: 22,504 allocs, 9,187 frees, 8,818,779 bytes allocated ==2454== ==2454== LEAK SUMMARY: ==2454== definitely lost: 0 bytes in 0 blocks ==2454== indirectly lost: 0 bytes in 0 blocks ==2454== possibly lost: 1,152 bytes in 4 blocks ==2454== still reachable: 6,001,335 bytes in 13,313 blocks ==2454== suppressed: 0 bytes in 0 blocks ==2454== Rerun with --leak-check=full to see details of leaked memory ==2454== ==2454== For counts of detected and suppressed errors, rerun with: -v ==2454== ERROR SUMMARY: 42 errors from 16 contexts (suppressed: 31 from 9) ~ ~

1 0

Re: (ITS#7638) Handle connection loss in SQL backend
by michael＠stroeder.com 07 Jul '13

07 Jul '13

This is a cryptographically signed message in MIME format. --------------ms060507090607040908080102 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable pierre(a)reactos.org wrote: > With this patch, before preparing any req on the given connection handl= e, the > backend will first try to check whether the connection is active by iss= ue a > dummy query. In case it's not, it will close the previous connection an= d open a > new one. And then, will prepare the req on the connection link. > > I made this choice of developement because, preparing statement, execut= ing it > and then, only looking whether it fails to re-submit would have been mo= re > complex, since it would have required to start over the whole process f= or the > query (statement preparation and such) while preparation & execution ar= en't not > in the same function. Hmm, so there's an extra dummy query for each real query. If the SQL DB i= s=20 connected over network this means a synchronous extra round trip for each= query. Ciao, Michael. --------------ms060507090607040908080102 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFfzCC BXswggNjoAMCAQICAwxOfTANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMjEw MDIyMDE3MDlaFw0xNDEwMDIyMDE3MDlaMD8xGDAWBgNVBAMUD01pY2hhZWwgU3Ry9mRlcjEj MCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDo2SKth5GhtaDrCyfGtyUG+/hAAa/J52L0NFN4SSRvTtdGf9HfWwwd NCtgae0TVGWk2lKDbXA9d5vmyIiRhuwxd90H6FLErhRBeB9G67qtw87E8WUoXt2DwPQEUTWV hqHpPadlmgFw3+i3TGQQTe3O3W9MMMd4GJNhObem2VGRuCD37OXnzBksTcq0FPJgcWAhe3d/ 0ItOkNWBqgq8Mf3p7WFBhaQ0a27BC/mKtH8fI3kPcS305imPRja69Msq3EwUZBc9ToVp6FRQ NYKjfOBybDUzVkmRZl3H8xutQP2w8Zxb8m5f7Q1BfLLrIFScfYvIDgOERxTCd4lab8+/09XH AgMBAAGjggFEMIIBQDAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJFkdUbyBnZXQgeW91 ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6Ly93d3cuQ0Fj ZXJ0Lm9yZzAOBgNVHQ8BAf8EBAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMC BgorBgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIG CCsGAQUFBzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMDEGA1UdHwQqMCgwJqAkoCKGIGh0 dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9yZXZva2UuY3JsMB8GA1UdEQQYMBaBFG1pY2hhZWxAc3Ry b2VkZXIuY29tMA0GCSqGSIb3DQEBBQUAA4ICAQC9ouXq3p/bDWMM4tBKgD3tl4HY5H0eECl8 q9/nqk0UL6YeWkrCiQdrDtNPW7DcGqNYtzdgtzmyTr1GhiAX+igrOjdk/ge5NRcQOpONK/4b zrmpQEcIUyxSSDKLWh211/kcFfxxLEiJ5teF4GL8Fc1qbrLP4+DCvJXWfYaaR5NLjZMqm2VP yKTv3qpXWnGohiRkGTwS/11QM2XCfIGdRsQT9a8mO4m2fn2tGPp2TEIoCLrDDrbGVeDWaOWB OIeTrp4wa3Q4OI6yCptJhEqKvjhV96IBRYgM76nTBqsqnDzwxExAyhhWiUS5DunRHOr/+NyF pUpD4883RBLO0g9kUEGOhtZNF1u+8zEL0YgMGvifAom9JEklLOXZuqj0MThypKs/3d/OyOQb 4gURnu6oZwcKZ7LskytWnlRKUxF6o0A8grtmyKkqe14TS7cQbg0NTaIYXPkHR+dfFmb3uEqn BBjvpJXFcEtWI2lQXC/ET+au991pK797ExBOmpQwjIn3SjiW80vw/UoL6DMvqY/6JhVhyNTP MJ2W5AX5kc27DIbVtVGZs8J4AYhuNALJUq9N9Ka7rPRj3RcYDrfehDLOkM5iMnarpmtuOpLK d1SvZhqj/0N/JWGIDpPSTkTFOPP6ZN9I9Rqyf+9NGqb2sjo4DkIiZcHxt735/GJLwus5KLBl 2DGCA6EwggOdAgEBMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93 d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8G CSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wCQYFKw4DAhoFAKCCAfUwGAYJ KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNzA3MTIzMzAwWjAj BgkqhkiG9w0BCQQxFgQUcA4tlsdiopKrS2o6P/u/9l6BtaowbAYJKoZIhvcNAQkPMV8wXTAL BglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAN BggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGD MIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9y ZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYS c3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wgZMGCyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNV BAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZ Q0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNl cnQub3JnAgMMTn0wDQYJKoZIhvcNAQEBBQAEggEAVQZMpxErjJaK7BfN3lo+Q0Jf4cJRZ3Y/ hutq+P9aUTxJB1pOwjxle8MZ0H0/TbJ5XJu5Mtc/fzc3DcKMH+EDgyM8Jt/z5bqY1SRmVBNA U8ZZMxyhaBDpt4wIl1JftEkrn87iLXD5H5uxsE70ohKSOKIt0m+500tuvWxGtlrQPV4Ufilf a/jQU3G9Td04y4T4eq6ql39AkZPYR88SyJC1jjKhPPzRb/iWvvUzsJNpe/LSgd+ujdpIceY7 rM0PS8bPMZUCtS5TS9f+QT//tb7YI5r/a5jlP3nTeTRiQjMBLMb2EU2+q0fA6PcsQ0Hhr3TU OeNbOIlyfS6NrRu5pjupkgAAAAAAAA== --------------ms060507090607040908080102--

1 0

(ITS#7638) Handle connection loss in SQL backend
by pierre＠reactos.org 07 Jul '13

07 Jul '13

Full_Name: Pierre Schweitzer Version: HEAD OS: Ubuntu URL: http://fc.isima.fr/~schweitz/schweitz/0001-In-the-SQL-backend-add-code-to-h… Submission from: (NULL) (90.27.237.49) Hi, here is a patch to handle a possible connection loss to DBMS for the SQL backend. Right now, in case of connection loss, slapd just denied any entry lookup with an error 80 (backend error). With this patch, before preparing any req on the given connection handle, the backend will first try to check whether the connection is active by issue a dummy query. In case it's not, it will close the previous connection and open a new one. And then, will prepare the req on the connection link. I made this choice of developement because, preparing statement, executing it and then, only looking whether it fails to re-submit would have been more complex, since it would have required to start over the whole process for the query (statement preparation and such) while preparation & execution aren't not in the same function. This patch has been tested and validated in production on the ReactOS Foundation infrastructure. The attached patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Pierre Schweitzer (pierre(a)reactos.org). I have not assigned rights and/or interest in this work to any party. I, Pierre Schweitzer, 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. Regards, Pierre

1 0

Re: (ITS#7637) Need documentation: LDAP on virtual IP address
by hyc＠symas.com 04 Jul '13

04 Jul '13

Ulrich.Windl(a)rz.uni-regensburg.de wrote: > Full_Name: Ulrich Windl > Version: 2.4.26 > OS: Linux (SLES11 SP2) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (132.199.152.129) > > > I was able to set up a master LDAP server and a replication consumer using the > physical host names and TLS. However when I tried to bind slapd on a virtual IP > address ("interface alias"), I never got slapd working (even though I fixed the > certificates for TLS, of course). Dynamic configuration ("cn=config") seems to > make things very difficult, because slapd ends in a state where _nobody_ can > make configuration changes. Use the openldap-technical mailing list to ask for configuration help. You talk about IP addresses and yet in your quoted text below you are using hostnames. Be consistent when you post your question to the mailing list otherwise no one will understand what you're asking for. Closing this ITS. > It seems slapd tried to use the wrong URI (using the physical host where nobody > is listening): > slapd[10036]: slap_client_connect: URI=ldap://phost.domain.org/ Error, > ldap_start_tls failed (-1) > slapd[10036]: do_syncrepl: rid=002 rc -1 retrying > > slapd is listening on ldap://vhost.domain.org/ however. > > I read lots of procedures using Google, but could not find the solution for this > problem. Thus I suggest to add documentation how to configure such a scenario: > > 1) Set up an LDAP Master server that provides service on a specific IP address > using TLS > 2) Set up a replication consumer that provides service on a specific IP address > using TLS also > 3) The replication consumer should use the address where the master server > listens for replication > > It sounds like an every-day setup, but I failed multiple times, thus the request > for documentation. > > -- -- 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#7637) Need documentation: LDAP on virtual IP address
by Ulrich.Windl＠rz.uni-regensburg.de 04 Jul '13

04 Jul '13

Full_Name: Ulrich Windl Version: 2.4.26 OS: Linux (SLES11 SP2) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (132.199.152.129) I was able to set up a master LDAP server and a replication consumer using the physical host names and TLS. However when I tried to bind slapd on a virtual IP address ("interface alias"), I never got slapd working (even though I fixed the certificates for TLS, of course). Dynamic configuration ("cn=config") seems to make things very difficult, because slapd ends in a state where _nobody_ can make configuration changes. It seems slapd tried to use the wrong URI (using the physical host where nobody is listening): slapd[10036]: slap_client_connect: URI=ldap://phost.domain.org/ Error, ldap_start_tls failed (-1) slapd[10036]: do_syncrepl: rid=002 rc -1 retrying slapd is listening on ldap://vhost.domain.org/ however. I read lots of procedures using Google, but could not find the solution for this problem. Thus I suggest to add documentation how to configure such a scenario: 1) Set up an LDAP Master server that provides service on a specific IP address using TLS 2) Set up a replication consumer that provides service on a specific IP address using TLS also 3) The replication consumer should use the address where the master server listens for replication It sounds like an every-day setup, but I failed multiple times, thus the request for documentation.

1 0

Re: (ITS#7636) slapd crash when multi-master replication (syncrepl) enabled
by hyc＠symas.com 03 Jul '13

03 Jul '13

kb9vqf(a)pearsoncomputing.net wrote: >> kb9vqf(a)pearsoncomputing.net wrote: >>> Full_Name: Timothy Pearson >>> Version: 2.4.31 >>> OS: Debian Wheezy >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (131.156.2.26) >>> >>> >>> The setup: >>> Multi-master syncrepl on two servers >>> Identical hardware and software between servers >>> Self-signed TLS using common (private) CA certificate >>> >>> The problem: >>> slapd on one server crashes repeatably within a minute of slapd > starting on the >>> other server. slapd works reliably if and only if the other server is not >>> running a slapd process. >> >> 1) 2.4.31 is ancient. Current is 2.4.35. Please provide a backtrace > against a >> current OpenLDAP release. >> >> 2) Your backtrace shows a crash in a slapi plugin. If the bug is in your > plugin there's nothing we can do about it. >> >> 3) Don't touch the individual files inside the slapd configuration > database. >> Use "slapcat -n0". > > Thank you for your prompt response. In the backtrace I posted, which > portion suggests that the crash occurred in a plugin? I would have > expected to see at least one frame in something other than > ../../../../servers/slapd. Program received signal SIGABRT, Aborted. [Switching to Thread 0x7fffe356c700 (LWP 10433)] 0x00007ffff5a32475 in *__GI_raise (sig=<optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 64 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory. (gdb) bt #0 0x00007ffff5a32475 in *__GI_raise (sig=<optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #1 0x00007ffff5a356f0 in *__GI_abort () at abort.c:92 #2 0x00007ffff5a6d52b in __libc_message (do_abort=<optimized out>, fmt=<optimized out>) at ../sysdeps/unix/sysv/linux/libc_fatal.c:189 #3 0x00007ffff5a76d76 in malloc_printerr (action=3, str=0x7ffff5b4f170 "munmap_chunk(): invalid pointer", ptr=<optimized out>) at malloc.c:6283 #4 0x00007ffff63d214a in slapi_op_search_callback (op=0x7fffe3569fd0, rs=<optimized out>, prc=<optimized out>) at ../../../../../servers/slapd/slapi/slapi_overlay.c:313 #5 slapi_op_search_callback (op=0x7fffe3569fd0, rs=<optimized out>, prc=<optimized out>) at ../../../../../servers/slapd/slapi/slapi_overlay.c:296 #6 0x00007ffff63d304f in slapi_op_func (rs=0x7fffe3569f60, op=<optimized out>) at ../../../../../servers/slapd/slapi/slapi_overlay.c:631 #7 slapi_op_func (op=0x7fffe3569fd0, rs=0x7fffe3569f60) at ../../../../../servers/slapd/slapi/slapi_overlay.c:556 The slapi_* functions would not be present in the stack trace unless you had configured a slapi plugin on this database. -- -- 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#7636) slapd crash when multi-master replication (syncrepl) enabled
by kb9vqf＠pearsoncomputing.net 03 Jul '13

03 Jul '13

> kb9vqf(a)pearsoncomputing.net wrote: >> Full_Name: Timothy Pearson >> Version: 2.4.31 >> OS: Debian Wheezy >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (131.156.2.26) >> >> >> The setup: >> Multi-master syncrepl on two servers >> Identical hardware and software between servers >> Self-signed TLS using common (private) CA certificate >> >> The problem: >> slapd on one server crashes repeatably within a minute of slapd starting on the >> other server. slapd works reliably if and only if the other server is not >> running a slapd process. > > 1) 2.4.31 is ancient. Current is 2.4.35. Please provide a backtrace against a > current OpenLDAP release. > > 2) Your backtrace shows a crash in a slapi plugin. If the bug is in your plugin there's nothing we can do about it. > > 3) Don't touch the individual files inside the slapd configuration database. > Use "slapcat -n0". Thank you for your prompt response. In the backtrace I posted, which portion suggests that the crash occurred in a plugin? I would have expected to see at least one frame in something other than ../../../../servers/slapd. I am not directly modifying the config database text files, but did not know the correct method to dump the existing files. Thanks for the command!

1 0

Re: (ITS#7633) Slapd hangs on hdb write lock
by hyc＠symas.com 03 Jul '13

03 Jul '13

dusan.fric(a)t-systems.sk wrote: > --_000_B3C9B2D7E2866A479BAEDF530AA0293D2C5FE65416TSSKKEEXCCR1s_ > Content-Type: text/plain; charset="us-ascii" > Content-Transfer-Encoding: quoted-printable > > Hi guys, > > good news, the issue is solved. We changed db setting (DB_CONFIG) as follow= > s: > > set_lk_detect DB_LOCK_RANDOM > > (instead of bad set_lk_detect DB_LOCK_EXPIRE) > > and no hangs until now. That's great, but why was it set to DB_LOCK_EXPIRE in the first place? DB_LOCK_RANDOM is the default, you should not be changing this setting without a good reason and good knowledge of what you're doing. > > We can also find the same issue described here > > http://www.openldap.org/lists/openldap-technical/201102/msg00074.html > > > FYI - customer's test confirmed it. > > Thanks for your suggestions and help. > > Regards, > Dusan -- -- 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#7633) Slapd hangs on hdb write lock
by dusan.fric＠t-systems.sk 03 Jul '13

03 Jul '13

--_000_B3C9B2D7E2866A479BAEDF530AA0293D2C5FE65416TSSKKEEXCCR1s_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi guys, good news, the issue is solved. We changed db setting (DB_CONFIG) as follow= s: set_lk_detect DB_LOCK_RANDOM (instead of bad set_lk_detect DB_LOCK_EXPIRE) and no hangs until now. We can also find the same issue described here http://www.openldap.org/lists/openldap-technical/201102/msg00074.html FYI - customer's test confirmed it. Thanks for your suggestions and help. Regards, Dusan --_000_B3C9B2D7E2866A479BAEDF530AA0293D2C5FE65416TSSKKEEXCCR1s_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"><head><meta http-equiv=3DContent-Type content= =3D"text/html; charset=3Dus-ascii"><meta name=3DGenerator content=3D"Micros= oft Word 14 (filtered medium)"><style></style></head><body lang=3DEN-US link=3Dblue vli= nk=3Dpurple><div class=3DWordSection1>Hi guys,<o:p></o= :p><o:p> </o:p>good = news, the issue is solved. We changed db setting (DB_CONFIG) as follows:<o:= p></o:p><o:p> </o:p>= set_lk_detect DB_LOCK_RANDOM<o:p></o:p><o:p> = </o:p>(instead of bad <s>set_lk_detect DB_LOCK_EXP= IRE</s>)<o:p></o:p><o:p> </o:p>and no hangs until now. <o:p></o:p><o= :p> </o:p>We can also find the same issue des= cribed here<o:p></o:p><o:p> </o:p><a href=3D"http://www.openldap.org/lists/openldap-technical/2= 01102/msg00074.html">http://www.openldap.org/lists/openldap-technical/20110= 2/msg00074.html</a><o:p></o:p><o:p> </o:p></p= ><o:p> </o:p>FYI –= customer’s test confirmed it.<o:p></o:p><o:= p> </o:p>Thanks for your suggestions and help= .<o:p></o:p><o:p> </o:p>Regards,<o:p></o:p>Dusan<o:p></o:p></div><= /body></html>= --_000_B3C9B2D7E2866A479BAEDF530AA0293D2C5FE65416TSSKKEEXCCR1s_--

1 0

Re: (ITS#7636) slapd crash when multi-master replication (syncrepl) enabled
by hyc＠symas.com 02 Jul '13

02 Jul '13

kb9vqf(a)pearsoncomputing.net wrote: > Full_Name: Timothy Pearson > Version: 2.4.31 > OS: Debian Wheezy > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (131.156.2.26) > > > The setup: > Multi-master syncrepl on two servers > Identical hardware and software between servers > Self-signed TLS using common (private) CA certificate > > The problem: > slapd on one server crashes repeatably within a minute of slapd starting on the > other server. slapd works reliably if and only if the other server is not > running a slapd process. 1) 2.4.31 is ancient. Current is 2.4.35. Please provide a backtrace against a current OpenLDAP release. 2) Your backtrace shows a crash in a slapi plugin. If the bug is in your plugin there's nothing we can do about it. 3) Don't touch the individual files inside the slapd configuration database. Use "slapcat -n0". > > Backtrace (does not change appreciably from crash to crash): > > Program received signal SIGABRT, Aborted. > [Switching to Thread 0x7fffe356c700 (LWP 10433)] > 0x00007ffff5a32475 in *__GI_raise (sig=<optimized out>) at > ../nptl/sysdeps/unix/sysv/linux/raise.c:64 > 64 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory. > (gdb) bt > #0 0x00007ffff5a32475 in *__GI_raise (sig=<optimized out>) at > ../nptl/sysdeps/unix/sysv/linux/raise.c:64 > #1 0x00007ffff5a356f0 in *__GI_abort () at abort.c:92 > #2 0x00007ffff5a6d52b in __libc_message (do_abort=<optimized out>, > fmt=<optimized out>) at ../sysdeps/unix/sysv/linux/libc_fatal.c:189 > #3 0x00007ffff5a76d76 in malloc_printerr (action=3, str=0x7ffff5b4f170 > "munmap_chunk(): invalid pointer", ptr=<optimized out>) at malloc.c:6283 > #4 0x00007ffff63d214a in slapi_op_search_callback (op=0x7fffe3569fd0, > rs=<optimized out>, prc=<optimized out>) at > ../../../../../servers/slapd/slapi/slapi_overlay.c:313 > #5 slapi_op_search_callback (op=0x7fffe3569fd0, rs=<optimized out>, > prc=<optimized out>) at ../../../../../servers/slapd/slapi/slapi_overlay.c:296 > #6 0x00007ffff63d304f in slapi_op_func (rs=0x7fffe3569f60, op=<optimized out>) > at ../../../../../servers/slapd/slapi/slapi_overlay.c:631 > #7 slapi_op_func (op=0x7fffe3569fd0, rs=0x7fffe3569f60) at > ../../../../../servers/slapd/slapi/slapi_overlay.c:556 > #8 0x00005555555ff18a in overlay_op_walk (op=op@entry=0x7fffe3569fd0, > rs=0x7fffe3569f60, which=op_search, oi=0x5555559e57f0, on=0x5555559e4510) at > ../../../../servers/slapd/backover.c:661 > #9 0x00005555555ff31b in over_op_func (op=0x7fffe3569fd0, rs=<optimized out>, > which=<optimized out>) at ../../../../servers/slapd/backover.c:723 > #10 0x00007ffff1c4870e in syncprov_findbase (op=op@entry=0x555555dd8560, > fc=fc@entry=0x7fffe356a280) at > ../../../../../servers/slapd/overlays/syncprov.c:453 > #11 0x00007ffff1c4b1ef in syncprov_op_search (op=0x555555dd8560, > rs=0x7fffe356ba50) at ../../../../../servers/slapd/overlays/syncprov.c:2465 > #12 0x00005555555ff18a in overlay_op_walk (op=op@entry=0x555555dd8560, > rs=rs@entry=0x7fffe356ba50, which=which@entry=op_search, oi=0x5555559e57f0, > on=0x5555559e15e0) at ../../../../servers/slapd/backover.c:661 > #13 0x00007ffff63d3086 in slapi_op_func (rs=0x7fffe356ba50, op=<optimized out>) > at ../../../../../servers/slapd/slapi/slapi_overlay.c:647 > #14 slapi_op_func (op=0x555555dd8560, rs=0x7fffe356ba50) at > ../../../../../servers/slapd/slapi/slapi_overlay.c:556 > #15 0x00005555555ff18a in overlay_op_walk (op=op@entry=0x555555dd8560, > rs=0x7fffe356ba50, which=op_search, oi=0x5555559e57f0, on=0x5555559e4510) at > ../../../../servers/slapd/backover.c:661 > #16 0x00005555555ff31b in over_op_func (op=0x555555dd8560, rs=<optimized out>, > which=<optimized out>) at ../../../../servers/slapd/backover.c:723 > #17 0x0000555555594641 in fe_op_search (op=0x555555dd8560, rs=0x7fffe356ba50) at > ../../../../servers/slapd/search.c:402 > #18 0x0000555555593f06 in do_search (op=0x555555dd8560, rs=0x7fffe356ba50) at > ../../../../servers/slapd/search.c:247 > #19 0x0000555555591961 in connection_operation (ctx=ctx@entry=0x7fffe356bba0, > arg_v=arg_v@entry=0x555555dd8560) at > ../../../../servers/slapd/connection.c:1150 > #20 0x0000555555591c84 in connection_read_thread (ctx=0x7fffe356bba0, > argv=<optimized out>) at ../../../../servers/slapd/connection.c:1286 > #21 0x00007ffff7b9dff3 in ?? () from > /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2 > #22 0x00007ffff5d90b50 in start_thread (arg=<optimized out>) at > pthread_create.c:304 > #23 0x00007ffff5adaa7d in clone () at > ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 > #24 0x0000000000000000 in ?? () > > > Relevant configuration files: > > > olcDatabase={0}config.ldif: > > dn: olcDatabase={0}config > objectClass: olcDatabaseConfig > olcDatabase: {0}config > olcAccess: {0}to * by > group/groupOfNames/member.exact="cn=realmadmins,ou=groups,ou=core,ou=realm,dc=<redacted>" > write by dn.base="uid=ldapadmin,ou=users,ou=core,ou=realm,dc=<redacted>" write > by dn.base="cn=admin,dc=<redacted>" write by sockurl.regex="^ldapi:///$" write > by dynacl/aci write by * none > olcAddContentAcl: TRUE > olcLastMod: TRUE > olcMaxDerefDepth: 15 > olcReadOnly: FALSE > olcRootDN: cn=config > olcRootPW:: REDACTED > olcSyncUseSubentry: FALSE > olcMonitoring: FALSE > structuralObjectClass: olcDatabaseConfig > creatorsName: cn=config > createTimestamp: 20130702170316Z > olcSyncrepl: {0}rid=001 provider=ldaps://ldap002.<redacted>/ > binddn="cn=admin,dc=<redacted>" bindmethod=simple credentials="ldapadmin001" > searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5 600 +" timeout=1 > tls_reqcert=never tls_cacert="/etc/trinity/ldap/tde-ca/anchors/tdeca.pem"lcSyncrepl: > {1}rid=002 provider=ldaps://ldap003.<redacted>/ binddn="cn=admin,dc=<redacted>" > bindmethod=simple credentials="ldapadmin001" searchbase="cn=config" > type=refreshAndPersist retry="5 5 300 5 600 +" timeout=1 tls_reqcert=never > tls_cacert="/etc/trinity/ldap/tde-ca/anchors/tdeca.pem" > olcMirrorMode: TRUE > entryCSN: 20130702180604.682031Z#000000#002#000000 > modifiersName: > modifyTimestamp: 20130702180604Z > > > olcDatabase={1}hdb.ldif: > > dn: olcDatabase={1}hdb > objectClass: olcDatabaseConfig > objectClass: olcHdbConfig > olcDatabase: {1}hdb > olcDbDirectory: /var/lib/ldap > olcSuffix: dc=<redacted> > olcAccess: {0}to attrs=userPassword,shadowLastChange,krb5Key,krb5PrincipalName,krb5KeyVersionNumber,krb5MaxLife,krb5MaxRenew,krb5KDCFlags,privateRootCertificateKey > by group/groupOfNames/member.exact="cn=realmadmins,ou=groups,ou=core,ou=realm,dc=<redacted>" > write by dn.base="uid=ldapadmin,ou=users,ou=core,ou=realm,dc=<redacted>" by > sockurl.regex="^ldapi:///$" write by anonymous auth by self write by * none > olcAccess: {1}to dn.base="" by * read > olcAccess: {2}to * by > group/groupOfNames/member.exact="cn=realmadmins,ou=groups,ou=core,ou=realm,dc=<redacted>" > write by dn.base="uid=ldapadmin,ou=users,ou=core,ou=realm,dc=<redacted>" write > by sockurl.regex="^ldapi:///$" write by dynacl/aci write > olcAddContentAcl: FALSE > olcLastMod: TRUE > olcMaxDerefDepth: 15 > olcReadOnly: FALSE > olcRootDN: cn=admin,dc=<redacted> > olcRootPW:: REDACTED > olcMonitoring: TRUE > olcDbCacheSize: 1000 > olcDbCheckpoint: 512 30 > olcDbConfig: {0}set_cachesize 0 67108864 1 > olcDbConfig: {1}set_lg_regionmax 262144 > olcDbConfig: {2}set_lg_bsize 2097152 > olcDbNoSync: FALSE > olcDbDirtyRead: FALSE > olcDbIDLcacheSize: 0 > olcDbIndex: objectClass eq > olcDbIndex: krb5PrincipalName eq,pres > olcDbIndex: cn eq,pres,subinitial > olcDbIndex: mail eq,pres > olcDbIndex: uid pres,eq > olcDbIndex: uidNumber eq > olcDbIndex: gidNumber eq > olcDbLinearIndex: FALSE > olcDbMode: 0600 > olcDbSearchStack: 16 > olcDbShmKey: 0 > olcDbCacheFree: 1 > olcDbDNcacheSize: 0 > olcPlugin: postoperation /opt/trinity/lib/slapi-acl-manager.so plugin_init > admingroup-dn:=cn=realmadmins,ou=groups,ou=core,ou=realm,dc=<redacted> > realm:=CEET.NIU.EDU aclfile:=/etc/heimdal-kdc/kadmind.acl builtinadmin:=admin > structuralObjectClass: olcHdbConfig > creatorsName: cn=config > createTimestamp: 20130702170316Z > olcSyncrepl: {0}rid=001 provider=ldaps://ldap002.<redacted>/ > binddn="cn=admin,dc=<redacted>" bindmethod=simple credentials="ldapadmin001" > searchbase="dc=<redacted>" type=refreshAndPersist retry="5 5 300 5" timeout=1 > tls_reqcert=never tls_cacert="/etc/trinity/ldap/tde-ca/anchors/tdeca.pem" > olcSyncrepl: {1}rid=002 provider=ldaps://ldap003.<redacted>/ > binddn="cn=admin,dc=<redacted>" bindmethod=simple credentials="ldapadmin001" > searchbase="dc=<redacted>" type=refreshAndPersist retry="5 5 300 5" timeout=1 > tls_reqcert=never tls_cacert="/etc/trinity/ldap/tde-ca/anchors/tdeca.pem" > olcMirrorMode: TRUE > entryCSN: 20130702170511.039863Z#000000#002#000000 > modifiersName: > modifyTimestamp: 20130702170511Z > > > olcDatabase={0}config/olcOverlay={0}syncprov.ldif: > > dn: olcOverlay={0}syncprov > objectClass: olcOverlayConfig > objectClass: olcSyncProvConfig > olcOverlay: {0}syncprov > structuralObjectClass: olcSyncProvConfig > entryUUID: 14f25934-7785-1032-93bd-0fe5d581c3b6 > creatorsName: > createTimestamp: 20130702170337Z > entryCSN: 20130702170337.631532Z#000000#002#000000 > modifiersName: > modifyTimestamp: 20130702170337Z > > > olcDatabase={1}hdb/olcOverlay={0}syncprov.ldif: > > dn: olcOverlay={0}syncprov > objectClass: olcOverlayConfig > objectClass: olcSyncProvConfig > olcOverlay: {0}syncprov > structuralObjectClass: olcSyncProvConfig > entryUUID: bfa2e530-778d-1032-9b41-e7480f731418 > creatorsName: > createTimestamp: 20130702180539Z > entryCSN: 20130702180539.975057Z#000000#002#000000 > modifiersName: > modifyTimestamp: 20130702180539Z > > -- -- 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#7636) slapd crash when multi-master replication (syncrepl) enabled
by kb9vqf＠pearsoncomputing.net 02 Jul '13

02 Jul '13

Since my report above seems to have been somewhat mangled by the submission process, here is a link to a plain-text version of the same report: http://www.ceet.niu.edu/pastebin/openldap_bug_report_7636.txt

1 0

(ITS#7636) slapd crash when multi-master replication (syncrepl) enabled
by kb9vqf＠pearsoncomputing.net 02 Jul '13

02 Jul '13

Full_Name: Timothy Pearson Version: 2.4.31 OS: Debian Wheezy URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (131.156.2.26) The setup: Multi-master syncrepl on two servers Identical hardware and software between servers Self-signed TLS using common (private) CA certificate The problem: slapd on one server crashes repeatably within a minute of slapd starting on the other server. slapd works reliably if and only if the other server is not running a slapd process. Backtrace (does not change appreciably from crash to crash): Program received signal SIGABRT, Aborted. [Switching to Thread 0x7fffe356c700 (LWP 10433)] 0x00007ffff5a32475 in *__GI_raise (sig=<optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 64 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory. (gdb) bt #0 0x00007ffff5a32475 in *__GI_raise (sig=<optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #1 0x00007ffff5a356f0 in *__GI_abort () at abort.c:92 #2 0x00007ffff5a6d52b in __libc_message (do_abort=<optimized out>, fmt=<optimized out>) at ../sysdeps/unix/sysv/linux/libc_fatal.c:189 #3 0x00007ffff5a76d76 in malloc_printerr (action=3, str=0x7ffff5b4f170 "munmap_chunk(): invalid pointer", ptr=<optimized out>) at malloc.c:6283 #4 0x00007ffff63d214a in slapi_op_search_callback (op=0x7fffe3569fd0, rs=<optimized out>, prc=<optimized out>) at ../../../../../servers/slapd/slapi/slapi_overlay.c:313 #5 slapi_op_search_callback (op=0x7fffe3569fd0, rs=<optimized out>, prc=<optimized out>) at ../../../../../servers/slapd/slapi/slapi_overlay.c:296 #6 0x00007ffff63d304f in slapi_op_func (rs=0x7fffe3569f60, op=<optimized out>) at ../../../../../servers/slapd/slapi/slapi_overlay.c:631 #7 slapi_op_func (op=0x7fffe3569fd0, rs=0x7fffe3569f60) at ../../../../../servers/slapd/slapi/slapi_overlay.c:556 #8 0x00005555555ff18a in overlay_op_walk (op=op@entry=0x7fffe3569fd0, rs=0x7fffe3569f60, which=op_search, oi=0x5555559e57f0, on=0x5555559e4510) at ../../../../servers/slapd/backover.c:661 #9 0x00005555555ff31b in over_op_func (op=0x7fffe3569fd0, rs=<optimized out>, which=<optimized out>) at ../../../../servers/slapd/backover.c:723 #10 0x00007ffff1c4870e in syncprov_findbase (op=op@entry=0x555555dd8560, fc=fc@entry=0x7fffe356a280) at ../../../../../servers/slapd/overlays/syncprov.c:453 #11 0x00007ffff1c4b1ef in syncprov_op_search (op=0x555555dd8560, rs=0x7fffe356ba50) at ../../../../../servers/slapd/overlays/syncprov.c:2465 #12 0x00005555555ff18a in overlay_op_walk (op=op@entry=0x555555dd8560, rs=rs@entry=0x7fffe356ba50, which=which@entry=op_search, oi=0x5555559e57f0, on=0x5555559e15e0) at ../../../../servers/slapd/backover.c:661 #13 0x00007ffff63d3086 in slapi_op_func (rs=0x7fffe356ba50, op=<optimized out>) at ../../../../../servers/slapd/slapi/slapi_overlay.c:647 #14 slapi_op_func (op=0x555555dd8560, rs=0x7fffe356ba50) at ../../../../../servers/slapd/slapi/slapi_overlay.c:556 #15 0x00005555555ff18a in overlay_op_walk (op=op@entry=0x555555dd8560, rs=0x7fffe356ba50, which=op_search, oi=0x5555559e57f0, on=0x5555559e4510) at ../../../../servers/slapd/backover.c:661 #16 0x00005555555ff31b in over_op_func (op=0x555555dd8560, rs=<optimized out>, which=<optimized out>) at ../../../../servers/slapd/backover.c:723 #17 0x0000555555594641 in fe_op_search (op=0x555555dd8560, rs=0x7fffe356ba50) at ../../../../servers/slapd/search.c:402 #18 0x0000555555593f06 in do_search (op=0x555555dd8560, rs=0x7fffe356ba50) at ../../../../servers/slapd/search.c:247 #19 0x0000555555591961 in connection_operation (ctx=ctx@entry=0x7fffe356bba0, arg_v=arg_v@entry=0x555555dd8560) at ../../../../servers/slapd/connection.c:1150 #20 0x0000555555591c84 in connection_read_thread (ctx=0x7fffe356bba0, argv=<optimized out>) at ../../../../servers/slapd/connection.c:1286 #21 0x00007ffff7b9dff3 in ?? () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2 #22 0x00007ffff5d90b50 in start_thread (arg=<optimized out>) at pthread_create.c:304 #23 0x00007ffff5adaa7d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 #24 0x0000000000000000 in ?? () Relevant configuration files: olcDatabase={0}config.ldif: dn: olcDatabase={0}config objectClass: olcDatabaseConfig olcDatabase: {0}config olcAccess: {0}to * by group/groupOfNames/member.exact="cn=realmadmins,ou=groups,ou=core,ou=realm,dc=<redacted>" write by dn.base="uid=ldapadmin,ou=users,ou=core,ou=realm,dc=<redacted>" write by dn.base="cn=admin,dc=<redacted>" write by sockurl.regex="^ldapi:///$" write by dynacl/aci write by * none olcAddContentAcl: TRUE olcLastMod: TRUE olcMaxDerefDepth: 15 olcReadOnly: FALSE olcRootDN: cn=config olcRootPW:: REDACTED olcSyncUseSubentry: FALSE olcMonitoring: FALSE structuralObjectClass: olcDatabaseConfig creatorsName: cn=config createTimestamp: 20130702170316Z olcSyncrepl: {0}rid=001 provider=ldaps://ldap002.<redacted>/ binddn="cn=admin,dc=<redacted>" bindmethod=simple credentials="ldapadmin001" searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5 600 +" timeout=1 tls_reqcert=never tls_cacert="/etc/trinity/ldap/tde-ca/anchors/tdeca.pem"lcSyncrepl: {1}rid=002 provider=ldaps://ldap003.<redacted>/ binddn="cn=admin,dc=<redacted>" bindmethod=simple credentials="ldapadmin001" searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5 600 +" timeout=1 tls_reqcert=never tls_cacert="/etc/trinity/ldap/tde-ca/anchors/tdeca.pem" olcMirrorMode: TRUE entryCSN: 20130702180604.682031Z#000000#002#000000 modifiersName: modifyTimestamp: 20130702180604Z olcDatabase={1}hdb.ldif: dn: olcDatabase={1}hdb objectClass: olcDatabaseConfig objectClass: olcHdbConfig olcDatabase: {1}hdb olcDbDirectory: /var/lib/ldap olcSuffix: dc=<redacted> olcAccess: {0}to attrs=userPassword,shadowLastChange,krb5Key,krb5PrincipalName,krb5KeyVersionNumber,krb5MaxLife,krb5MaxRenew,krb5KDCFlags,privateRootCertificateKey by group/groupOfNames/member.exact="cn=realmadmins,ou=groups,ou=core,ou=realm,dc=<redacted>" write by dn.base="uid=ldapadmin,ou=users,ou=core,ou=realm,dc=<redacted>" by sockurl.regex="^ldapi:///$" write by anonymous auth by self write by * none olcAccess: {1}to dn.base="" by * read olcAccess: {2}to * by group/groupOfNames/member.exact="cn=realmadmins,ou=groups,ou=core,ou=realm,dc=<redacted>" write by dn.base="uid=ldapadmin,ou=users,ou=core,ou=realm,dc=<redacted>" write by sockurl.regex="^ldapi:///$" write by dynacl/aci write olcAddContentAcl: FALSE olcLastMod: TRUE olcMaxDerefDepth: 15 olcReadOnly: FALSE olcRootDN: cn=admin,dc=<redacted> olcRootPW:: REDACTED olcMonitoring: TRUE olcDbCacheSize: 1000 olcDbCheckpoint: 512 30 olcDbConfig: {0}set_cachesize 0 67108864 1 olcDbConfig: {1}set_lg_regionmax 262144 olcDbConfig: {2}set_lg_bsize 2097152 olcDbNoSync: FALSE olcDbDirtyRead: FALSE olcDbIDLcacheSize: 0 olcDbIndex: objectClass eq olcDbIndex: krb5PrincipalName eq,pres olcDbIndex: cn eq,pres,subinitial olcDbIndex: mail eq,pres olcDbIndex: uid pres,eq olcDbIndex: uidNumber eq olcDbIndex: gidNumber eq olcDbLinearIndex: FALSE olcDbMode: 0600 olcDbSearchStack: 16 olcDbShmKey: 0 olcDbCacheFree: 1 olcDbDNcacheSize: 0 olcPlugin: postoperation /opt/trinity/lib/slapi-acl-manager.so plugin_init admingroup-dn:=cn=realmadmins,ou=groups,ou=core,ou=realm,dc=<redacted> realm:=CEET.NIU.EDU aclfile:=/etc/heimdal-kdc/kadmind.acl builtinadmin:=admin structuralObjectClass: olcHdbConfig creatorsName: cn=config createTimestamp: 20130702170316Z olcSyncrepl: {0}rid=001 provider=ldaps://ldap002.<redacted>/ binddn="cn=admin,dc=<redacted>" bindmethod=simple credentials="ldapadmin001" searchbase="dc=<redacted>" type=refreshAndPersist retry="5 5 300 5" timeout=1 tls_reqcert=never tls_cacert="/etc/trinity/ldap/tde-ca/anchors/tdeca.pem" olcSyncrepl: {1}rid=002 provider=ldaps://ldap003.<redacted>/ binddn="cn=admin,dc=<redacted>" bindmethod=simple credentials="ldapadmin001" searchbase="dc=<redacted>" type=refreshAndPersist retry="5 5 300 5" timeout=1 tls_reqcert=never tls_cacert="/etc/trinity/ldap/tde-ca/anchors/tdeca.pem" olcMirrorMode: TRUE entryCSN: 20130702170511.039863Z#000000#002#000000 modifiersName: modifyTimestamp: 20130702170511Z olcDatabase={0}config/olcOverlay={0}syncprov.ldif: dn: olcOverlay={0}syncprov objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {0}syncprov structuralObjectClass: olcSyncProvConfig entryUUID: 14f25934-7785-1032-93bd-0fe5d581c3b6 creatorsName: createTimestamp: 20130702170337Z entryCSN: 20130702170337.631532Z#000000#002#000000 modifiersName: modifyTimestamp: 20130702170337Z olcDatabase={1}hdb/olcOverlay={0}syncprov.ldif: dn: olcOverlay={0}syncprov objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {0}syncprov structuralObjectClass: olcSyncProvConfig entryUUID: bfa2e530-778d-1032-9b41-e7480f731418 creatorsName: createTimestamp: 20130702180539Z entryCSN: 20130702180539.975057Z#000000#002#000000 modifiersName: modifyTimestamp: 20130702180539Z

1 0

(ITS#7635) lmdb race condition in read vs write txns
by hyc＠OpenLDAP.org 01 Jul '13

01 Jul '13

Full_Name: Howard Chu Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.127.144.82) Submitted by: hyc It's possible for a write txn to update a meta page while a reader is creating its snapshot of the meta page. In most cases this situation is harmless, but if the update raises the mm_last_pg field it may later cause an assert if the reader still has the old value of mm_last_pg, but accesses a DB whose pages are beyond the old value. A fix has been tested and will be committed shortly.

1 0

RE: (ITS#7634) openldap 2.4.24 hangs while attempting to shutdown
by madhan.kumar＠alcatel-lucent.com 01 Jul '13

01 Jul '13

Thanks Micheal. -----Original Message----- From: Michael Ströder [mailto:michael@stroeder.com] Sent: Monday, July 01, 2013 1:49 PM To: KUMAR, Madhan (Madhan); openldap-its(a)openldap.org Subject: Re: (ITS#7634) openldap 2.4.24 hangs while attempting to shutdown madhan.kumar(a)alcatel-lucent.com wrote: > We have an issue of openldap 2.4.24 hanging. This is similar to the issue > mentioned in the link: > http://www.openldap.org/lists/openldap-technical/201208/msg00119.html If you read the follow-up in the ML archive Howard says this was fixed in 2.4.25. So could you please try out recent release 2.4.35? Ciao, Michael.

1 0

Re: (ITS#7634) openldap 2.4.24 hangs while attempting to shutdown
by michael＠stroeder.com 01 Jul '13

01 Jul '13

madhan.kumar(a)alcatel-lucent.com wrote: > We have an issue of openldap 2.4.24 hanging. This is similar to the issue > mentioned in the link: > http://www.openldap.org/lists/openldap-technical/201208/msg00119.html If you read the follow-up in the ML archive Howard says this was fixed in 2.4.25. So could you please try out recent release 2.4.35? Ciao, Michael.

1 0

(ITS#7634) openldap 2.4.24 hangs while attempting to shutdown
by madhan.kumar＠alcatel-lucent.com 30 Jun '13

30 Jun '13

Full_Name: Madhan Kumar Version: 2.4.24 OS: linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (135.245.192.4) We have an issue of openldap 2.4.24 hanging. This is similar to the issue mentioned in the link: http://www.openldap.org/lists/openldap-technical/201208/msg00119.html When I checked the openldap logs I could see that the listeners are shown as busy continuously and an automatic internal shutdown is initiated to recover the ldap process. Unfortunately in our case the automatic internal shutdown is stuck and hence the issue. daemon: epoll: listen=7 active_threads=0 tvp=zero daemon: epoll: listen=8 busy daemon: epoll: listen=7 active_threads=0 tvp=zero daemon: epoll: listen=8 busy daemon: epoll: listen=7 active_threads=0 tvp=zero daemon: epoll: listen=8 busy daemon: epoll: listen=7 active_threads=0 tvp=zero daemon: epoll: listen=8 busy daemon: epoll: listen=7 active_threads=0 tvp=zero daemon: epoll: listen=8 busy daemon: epoll: listen=7 active_threads=0 tvp=zero daemon: epoll: listen=8 busy daemon: epoll: listen=7 active_threads=0 tvp=zero daemon: epoll: listen=8 busy daemon: shutdown requested and initiated. daemon: closing 7 daemon: closing 8 We need to get an confirmation that this issue is being fixed in openldap 2.4.25 so that we can upgrade our openldap version. Please confirm.

1 0

RE: (ITS#7633) Slapd hangs on hdb write lock
by ck＠cksoft.de 28 Jun '13

28 Jun '13

Hi Dusan, On Fri, 28 Jun 2013, dusan.fric(a)t-systems.sk wrote: > Hi Chu, > > thanks for your quick response. We will try to contact Oracle to advice here. > > However, what is your suggestion here ' try different settings for the deadlock detector' exactly? > > BTW - certainly, we are patched DB 4.7.25 (all 4 patches)... In case you can update to 2.4.35 you might want to test the mdb backend with your workload. Especially if you can easily reproduce the problem. Greetings Christian > > Regards, > Dusan > > -----Original Message----- > From: Howard Chu [mailto:hyc@symas.com] > Sent: 26. j??na 2013 13:32 > To: Fric, Dusan; openldap-its(a)openldap.org > Subject: Re: (ITS#7633) Slapd hangs on hdb write lock > > dusan.fric(a)t-systems.sk wrote: >> Full_Name: Dusan Fric >> Version: 2.4.32 >> OS: RHEL 5.7 x64 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (88.212.40.139) >> >> >> We are experiencing frequent hangs in slapd. Once hung we usualy >> cannot continue to connect until we kill -9 the slapd process and >> restart it. The directory is used for 2 applications as user eDir and >> we are using it in production over 1 month - we have noted the busier >> the directory becomes the more often it hangs (now twice per week). >> >> We have installed identical configurations on 3 environments, each has >> only one single server (no replication). There are 30k entries in the >> directory (production). >> >> We are running: >> >> RHEL 5.7 x64 (VMWare with NFS mountpoints) OpenLDAP 2.4.32 Berkeley DB >> 4.8.30 (4.7.25) >> >> We were starting with DB 4.8.30, after downgrade to version 4.7.25 >> (according to >> ITS#7378 - >> https://www.openldap.org/its/index.cgi/Incoming?id=7378;selectid=7378) >> we are facing the same issue. >> >> The problem occurs when two requests simultaneously try to update >> attributes of a record and in most cases of the same DN value. >> We can easily reproduce it with a java test program running 2 threads >> each connecting to the ldap server and updating the record for a >> particular DN value. >> It need not be the same DN value but DN values which reside on the >> same BDB page. > > Thanks for the traces, but the information you've provided shows that this is a BDB problem, not an OpenLDAP bug. You'll have to contact Oracle for help. > The BDB deadlock detector is supposed to handle these situations. > > For example in your 4.8.30 lock status there are only 2 conflicting transactions 80000028 and 80000029 and they are only contending on a single page. This is one of the most elementary deadlock situations. > > You might try different settings for the deadlock detector, but ultimately this appears to be a BDB bug and the choice of detector shouldn't matter. > >> Configuration >> >> olc cn=config (part): >> dn: cn=config >> objectClass: olcGlobal >> cn: config >> olcConcurrency: 0 >> olcConnMaxPending: 100 >> olcConnMaxPendingAuth: 1000 >> olcSockbufMaxIncoming: 262143 >> olcSockbufMaxIncomingAuth: 16777215 >> olcThreads: 32 >> >> olc DB hdb config (part): >> dn: olcDatabase={1}hdb,cn=config >> objectClass: olcHdbConfig >> objectClass: olcDatabaseConfig >> olcDatabase: {1}hdb >> olcDbCacheSize: 80000 >> olcDbCheckpoint: 128 5 >> olcDbConfig: {0}set_cachesize 0 268435456 1 >> olcDbConfig: {1}set_lg_max 10485760 >> olcDbConfig: {2}set_lg_bsize 2097152 >> olcDbConfig: {3}set_lg_dir /pkg/openldap/dblog >> olcDbConfig: {4}set_lg_regionmax 262144 >> olcDbConfig: {5}set_lk_detect DB_LOCK_EXPIRE >> olcDbConfig: {6}set_flags DB_TXN_NOSYNC >> olcDbDirtyRead: FALSE >> olcDbDNcacheSize: 0 >> olcDbIDLcacheSize: 240000 >> olcDbIndex: default eq,sub >> olcDbIndex: objectClass eq >> olcDbIndex: cn eq,sub >> olcDbIndex: uid eq,sub >> olcDbIndex: mail pres,eq >> olcDbIndex: sn eq,sub >> olcDbIndex: member eq >> olcDbLinearIndex: FALSE >> olcDbMode: 0600 >> olcDbNoSync: TRUE >> olcDbSearchStack: 20 >> olcDbShmKey: 0 >> olcLastMod: TRUE >> olcMaxDerefDepth: 15 >> olcMonitoring: TRUE >> olcReadOnly: FALSE >> >> We have managed to collect db_stat lock information, which indicates >> the same issue with DB write locks on both DB versions. >> >> db_stat -C ol (4.8.30) >> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >> Lock REGINFO information: >> Lock Region type >> 5 Region ID >> /apps/DECCLASA-1/data/openldap/__db.005 Region name >> 0x2ab41cdc3000 Region address >> 0x2ab41cdc3138 Region primary address >> 0 Region maximum allocation >> 0 Region allocated >> Region allocations: 3006 allocations, 0 failures, 0 frees, 1 longest >> REGION_JOIN_OK Region flags >> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >> Locks grouped by lockers: >> Locker Mode Count Status ----------------- Object --------------- >> 1 dd= 0 locks held 1 write locks 0 pid/thread 30034/47555767609232 >> 1 READ 1 HELD id2entry.bdb handle 0 >> 2 dd= 0 locks held 0 write locks 0 pid/thread 30034/47555767609232 >> 3 dd= 0 locks held 1 write locks 0 pid/thread 30034/47555767609232 >> 3 READ 1 HELD dn2id.bdb handle 0 >> 4 dd= 0 locks held 0 write locks 0 pid/thread 30034/1147971904 >> 5 dd= 0 locks held 0 write locks 0 pid/thread 30034/47555767609232 >> 6 dd= 0 locks held 0 write locks 0 pid/thread 30034/1139579200 >> 7 dd= 0 locks held 0 write locks 0 pid/thread 30034/1147971904 >> 8 dd= 0 locks held 0 write locks 0 pid/thread 30034/1131186496 >> 9 dd= 0 locks held 1 write locks 0 pid/thread 30034/1122793792 >> 9 READ 1 HELD objectClass.bdb handle 0 >> a dd= 0 locks held 0 write locks 0 pid/thread 30034/1122793792 >> b dd= 0 locks held 0 write locks 0 pid/thread 30034/1122793792 >> c dd= 0 locks held 1 write locks 0 pid/thread 30034/1122793792 >> c READ 1 HELD uid.bdb handle 0 >> d dd= 0 locks held 0 write locks 0 pid/thread 30034/1122793792 >> e dd= 0 locks held 0 write locks 0 pid/thread 30034/1122793792 >> f dd= 0 locks held 0 write locks 0 pid/thread 30034/1122793792 >> 10 dd= 0 locks held 1 write locks 0 pid/thread 30034/1147971904 >> 10 READ 1 HELD member.bdb handle 0 >> 11 dd= 0 locks held 0 write locks 0 pid/thread 30034/1147971904 >> 12 dd= 0 locks held 0 write locks 0 pid/thread 30034/1147971904 >> 13 dd= 0 locks held 1 write locks 0 pid/thread 30034/1147971904 >> 13 READ 1 HELD mail.bdb handle 0 >> 14 dd= 0 locks held 0 write locks 0 pid/thread 30034/1147971904 >> 15 dd= 0 locks held 0 write locks 0 pid/thread 30034/1147971904 >> 16 dd= 0 locks held 0 write locks 0 pid/thread 30034/1147971904 >> 17 dd= 0 locks held 0 write locks 0 pid/thread 30034/1147971904 >> 18 dd= 0 locks held 1 write locks 0 pid/thread 30034/1147971904 >> 18 READ 1 HELD sn.bdb handle 0 >> 19 dd= 0 locks held 0 write locks 0 pid/thread 30034/1147971904 >> 1a dd= 0 locks held 0 write locks 0 pid/thread 30034/1147971904 >> 1b dd= 0 locks held 1 write locks 0 pid/thread 30034/1147971904 >> 1b READ 1 HELD cn.bdb handle 0 >> 1c dd= 0 locks held 0 write locks 0 pid/thread 30034/1147971904 >> 1d dd= 0 locks held 0 write locks 0 pid/thread 30034/1147971904 >> 1e dd= 0 locks held 0 write locks 0 pid/thread 30034/1122793792 >> 1f dd= 0 locks held 0 write locks 0 pid/thread 30034/1131186496 >> 80000003 dd= 0 locks held 0 write locks 0 pid/thread 30034/47555767609232 >> 80000004 dd= 0 locks held 0 write locks 0 pid/thread 30034/1139579200 >> 80000005 dd= 0 locks held 0 write locks 0 pid/thread 30034/1147971904 >> 80000006 dd= 0 locks held 0 write locks 0 pid/thread 30034/1131186496 >> 80000007 dd= 0 locks held 0 write locks 0 pid/thread 30034/1122793792 >> 80000026 dd= 0 locks held 1 write locks 0 pid/thread 30034/1122793792 >> 80000026 READ 1 HELD 0x5e948 len: 9 data: 0x560x0500000000000000 >> 80000027 dd= 0 locks held 1 write locks 0 pid/thread 30034/1131186496 >> 80000027 READ 1 HELD 0x36490 len: 9 data: 0x370000000000000000 >> 80000028 dd= 0 locks held 1 write locks 0 pid/thread 30034/1131186496 >> 80000028 WRITE 1 WAIT mail.bdb page 3 >> 80000028 READ 1 HELD mail.bdb page 3 >> 80000029 dd= 0 locks held 1 write locks 0 pid/thread 30034/1122793792 >> 80000029 WRITE 1 WAIT mail.bdb page 3 >> 80000029 READ 1 HELD mail.bdb page 3 >> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >> Locks grouped by object: >> Locker Mode Count Status ----------------- Object --------------- >> 80000027 READ 1 HELD 0x36490 len: 9 data: 0x370000000000000000 >> >> 1b READ 1 HELD cn.bdb handle 0 >> >> 10 READ 1 HELD member.bdb handle 0 >> >> 9 READ 1 HELD objectClass.bdb handle 0 >> >> c READ 1 HELD uid.bdb handle 0 >> >> 80000026 READ 1 HELD 0x5e948 len: 9 data: 0x560x0500000000000000 >> >> 1 READ 1 HELD id2entry.bdb handle 0 >> >> 18 READ 1 HELD sn.bdb handle 0 >> >> 3 READ 1 HELD dn2id.bdb handle 0 >> >> 80000029 READ 1 HELD mail.bdb page 3 >> 80000028 READ 1 HELD mail.bdb page 3 >> 80000029 WRITE 1 WAIT mail.bdb page 3 >> 80000028 WRITE 1 WAIT mail.bdb page 3 >> >> 13 READ 1 HELD mail.bdb handle 0 >> >> db_stat -C ol (4.7.25) >> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >> Lock REGINFO information: >> Lock Region type >> 5 Region ID >> /apps/DECCLASA-1/data/openldap/__db.005 Region name >> 0x2b4a8a577000 Original region address >> 0x2b4a8a577000 Region address >> 0x2b4a8a577138 Region primary address >> 0 Region maximum allocation >> 0 Region allocated >> Region allocations: 3006 allocations, 0 failures, 0 frees, 1 longest >> REGION_JOIN_OK Region flags >> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >> Locks grouped by lockers: >> Locker Mode Count Status ----------------- Object --------------- >> 1 dd= 0 locks held 1 write locks 0 pid/thread 32447/47463753631632 >> 1 READ 1 HELD id2entry.bdb handle 0 >> 2 dd= 0 locks held 0 write locks 0 pid/thread 32447/47463753631632 >> 3 dd= 0 locks held 1 write locks 0 pid/thread 32447/47463753631632 >> 3 READ 1 HELD dn2id.bdb handle 0 >> 4 dd= 0 locks held 0 write locks 0 pid/thread 32447/1114126656 >> 5 dd= 0 locks held 0 write locks 0 pid/thread 32447/47463753631632 >> 6 dd= 0 locks held 0 write locks 0 pid/thread 32447/1097341248 >> 7 dd= 0 locks held 1 write locks 0 pid/thread 32447/1097341248 >> 7 READ 1 HELD objectClass.bdb handle 0 >> 8 dd= 0 locks held 0 write locks 0 pid/thread 32447/1097341248 >> 9 dd= 0 locks held 0 write locks 0 pid/thread 32447/1097341248 >> a dd= 0 locks held 0 write locks 0 pid/thread 32447/1097341248 >> b dd= 0 locks held 0 write locks 0 pid/thread 32447/1097341248 >> c dd= 0 locks held 1 write locks 0 pid/thread 32447/1097341248 >> c READ 1 HELD cn.bdb handle 0 >> d dd= 0 locks held 0 write locks 0 pid/thread 32447/1097341248 >> e dd= 0 locks held 0 write locks 0 pid/thread 32447/1097341248 >> f dd= 0 locks held 1 write locks 0 pid/thread 32447/1097341248 >> f READ 1 HELD uid.bdb handle 0 >> 10 dd= 0 locks held 0 write locks 0 pid/thread 32447/1097341248 >> 11 dd= 0 locks held 0 write locks 0 pid/thread 32447/1097341248 >> 12 dd= 0 locks held 1 write locks 0 pid/thread 32447/1097341248 >> 12 READ 1 HELD member.bdb handle 0 >> 13 dd= 0 locks held 0 write locks 0 pid/thread 32447/1097341248 >> 14 dd= 0 locks held 0 write locks 0 pid/thread 32447/1097341248 >> 15 dd= 0 locks held 1 write locks 0 pid/thread 32447/1105733952 >> 15 READ 1 HELD mail.bdb handle 0 >> 16 dd= 0 locks held 0 write locks 0 pid/thread 32447/1105733952 >> 17 dd= 0 locks held 0 write locks 0 pid/thread 32447/1105733952 >> 18 dd= 0 locks held 0 write locks 0 pid/thread 32447/1105733952 >> 19 dd= 0 locks held 0 write locks 0 pid/thread 32447/1105733952 >> 1a dd= 0 locks held 1 write locks 0 pid/thread 32447/1105733952 >> 1a READ 1 HELD sn.bdb handle 0 >> 1b dd= 0 locks held 0 write locks 0 pid/thread 32447/1105733952 >> 1c dd= 0 locks held 0 write locks 0 pid/thread 32447/1105733952 >> 1d dd= 0 locks held 0 write locks 0 pid/thread 32447/1105733952 >> 1e dd= 0 locks held 0 write locks 0 pid/thread 32447/1105733952 >> 1f dd= 0 locks held 0 write locks 0 pid/thread 32447/1097341248 >> 80000003 dd= 0 locks held 0 write locks 0 pid/thread 32447/47463753631632 >> 80000004 dd= 0 locks held 0 write locks 0 pid/thread 32447/1097341248 >> 80000008 dd= 0 locks held 0 write locks 0 pid/thread 32447/1105733952 >> 80000038 dd= 0 locks held 0 write locks 0 pid/thread 32447/1114126656 >> 800000a9 dd= 0 locks held 1 write locks 0 pid/thread 32447/1097341248 >> 800000a9 READ 1 HELD 0x2d228 len: 9 data: 0x370000000000000000 >> 800000aa dd= 0 locks held 2 write locks 0 pid/thread 32447/1097341248 >> 800000aa WRITE 1 WAIT mail.bdb page 3 >> 800000aa READ 1 HELD mail.bdb page 1 >> 800000aa READ 1 HELD mail.bdb page 3 >> 800000ab dd= 0 locks held 1 write locks 0 pid/thread 32447/1105733952 >> 800000ab READ 1 HELD 0x43d58 len: 9 data: 0x540x0500000000000000 >> 800000ac dd= 0 locks held 2 write locks 0 pid/thread 32447/1105733952 >> 800000ac WRITE 1 WAIT mail.bdb page 3 >> 800000ac READ 1 HELD mail.bdb page 1 >> 800000ac READ 1 HELD mail.bdb page 3 >> 800000b1 dd= 0 locks held 0 write locks 0 pid/thread 32447/1122519360 >> 800000b2 dd= 0 locks held 0 write locks 0 pid/thread 32447/1130912064 >> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >> Locks grouped by object: >> Locker Mode Count Status ----------------- Object --------------- >> 800000a9 READ 1 HELD 0x2d228 len: 9 data: 0x370000000000000000 >> >> 1 READ 1 HELD id2entry.bdb handle 0 >> >> 3 READ 1 HELD dn2id.bdb handle 0 >> >> 7 READ 1 HELD objectClass.bdb handle 0 >> >> f READ 1 HELD uid.bdb handle 0 >> >> 1a READ 1 HELD sn.bdb handle 0 >> >> 800000aa READ 1 HELD mail.bdb page 3 >> 800000ac READ 1 HELD mail.bdb page 3 >> 800000aa WRITE 1 WAIT mail.bdb page 3 >> 800000ac WRITE 1 WAIT mail.bdb page 3 >> >> c READ 1 HELD cn.bdb handle 0 >> >> 15 READ 1 HELD mail.bdb handle 0 >> >> 800000aa READ 1 HELD mail.bdb page 1 >> 800000ac READ 1 HELD mail.bdb page 1 >> >> 12 READ 1 HELD member.bdb handle 0 >> >> 800000ab READ 1 HELD 0x43d58 len: 9 data: 0x540x0500000000000000 >> >> >> We have also collected the backtrace of threads for both DB versions >> which I have uploaded to: >> https://dl.dropboxusercontent.com/u/92115703/dusan_gdb_threads_4.8.30_ >> 20130625.txt >> >> https://dl.dropboxusercontent.com/u/92115703/dusan_gdb_threads_4.7.25_ >> 20130625.txt >> >> > > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > > > -- Christian Kratzer CK Software GmbH Email: ck(a)cksoft.de Wildberger Weg 24/2 Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart Web: http://www.cksoft.de/ Geschaeftsfuehrer: Christian Kratzer

1 0

RE: (ITS#7633) Slapd hangs on hdb write lock
by dusan.fric＠t-systems.sk 28 Jun '13

28 Jun '13

Hi Chu, thanks for your quick response. We will try to contact Oracle to advice here. However, what is your suggestion here ' try different settings for the deadlock detector' exactly? BTW - certainly, we are patched DB 4.7.25 (all 4 patches)... Regards, Dusan -----Original Message----- From: Howard Chu [mailto:hyc@symas.com] Sent: 26. júna 2013 13:32 To: Fric, Dusan; openldap-its(a)openldap.org Subject: Re: (ITS#7633) Slapd hangs on hdb write lock dusan.fric(a)t-systems.sk wrote: > Full_Name: Dusan Fric > Version: 2.4.32 > OS: RHEL 5.7 x64 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (88.212.40.139) > > > We are experiencing frequent hangs in slapd. Once hung we usualy > cannot continue to connect until we kill -9 the slapd process and > restart it. The directory is used for 2 applications as user eDir and > we are using it in production over 1 month - we have noted the busier > the directory becomes the more often it hangs (now twice per week). > > We have installed identical configurations on 3 environments, each has > only one single server (no replication). There are 30k entries in the > directory (production). > > We are running: > > RHEL 5.7 x64 (VMWare with NFS mountpoints) OpenLDAP 2.4.32 Berkeley DB > 4.8.30 (4.7.25) > > We were starting with DB 4.8.30, after downgrade to version 4.7.25 > (according to > ITS#7378 - > https://www.openldap.org/its/index.cgi/Incoming?id=7378;selectid=7378) > we are facing the same issue. > > The problem occurs when two requests simultaneously try to update > attributes of a record and in most cases of the same DN value. > We can easily reproduce it with a java test program running 2 threads > each connecting to the ldap server and updating the record for a > particular DN value. > It need not be the same DN value but DN values which reside on the > same BDB page. Thanks for the traces, but the information you've provided shows that this is a BDB problem, not an OpenLDAP bug. You'll have to contact Oracle for help. The BDB deadlock detector is supposed to handle these situations. For example in your 4.8.30 lock status there are only 2 conflicting transactions 80000028 and 80000029 and they are only contending on a single page. This is one of the most elementary deadlock situations. You might try different settings for the deadlock detector, but ultimately this appears to be a BDB bug and the choice of detector shouldn't matter. > Configuration > > olc cn=config (part): > dn: cn=config > objectClass: olcGlobal > cn: config > olcConcurrency: 0 > olcConnMaxPending: 100 > olcConnMaxPendingAuth: 1000 > olcSockbufMaxIncoming: 262143 > olcSockbufMaxIncomingAuth: 16777215 > olcThreads: 32 > > olc DB hdb config (part): > dn: olcDatabase={1}hdb,cn=config > objectClass: olcHdbConfig > objectClass: olcDatabaseConfig > olcDatabase: {1}hdb > olcDbCacheSize: 80000 > olcDbCheckpoint: 128 5 > olcDbConfig: {0}set_cachesize 0 268435456 1 > olcDbConfig: {1}set_lg_max 10485760 > olcDbConfig: {2}set_lg_bsize 2097152 > olcDbConfig: {3}set_lg_dir /pkg/openldap/dblog > olcDbConfig: {4}set_lg_regionmax 262144 > olcDbConfig: {5}set_lk_detect DB_LOCK_EXPIRE > olcDbConfig: {6}set_flags DB_TXN_NOSYNC > olcDbDirtyRead: FALSE > olcDbDNcacheSize: 0 > olcDbIDLcacheSize: 240000 > olcDbIndex: default eq,sub > olcDbIndex: objectClass eq > olcDbIndex: cn eq,sub > olcDbIndex: uid eq,sub > olcDbIndex: mail pres,eq > olcDbIndex: sn eq,sub > olcDbIndex: member eq > olcDbLinearIndex: FALSE > olcDbMode: 0600 > olcDbNoSync: TRUE > olcDbSearchStack: 20 > olcDbShmKey: 0 > olcLastMod: TRUE > olcMaxDerefDepth: 15 > olcMonitoring: TRUE > olcReadOnly: FALSE > > We have managed to collect db_stat lock information, which indicates > the same issue with DB write locks on both DB versions. > > db_stat -C ol (4.8.30) > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Lock REGINFO information: > Lock Region type > 5 Region ID > /apps/DECCLASA-1/data/openldap/__db.005 Region name > 0x2ab41cdc3000 Region address > 0x2ab41cdc3138 Region primary address > 0 Region maximum allocation > 0 Region allocated > Region allocations: 3006 allocations, 0 failures, 0 frees, 1 longest > REGION_JOIN_OK Region flags > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Locks grouped by lockers: > Locker Mode Count Status ----------------- Object --------------- > 1 dd= 0 locks held 1 write locks 0 pid/thread 30034/47555767609232 > 1 READ 1 HELD id2entry.bdb handle 0 > 2 dd= 0 locks held 0 write locks 0 pid/thread 30034/47555767609232 > 3 dd= 0 locks held 1 write locks 0 pid/thread 30034/47555767609232 > 3 READ 1 HELD dn2id.bdb handle 0 > 4 dd= 0 locks held 0 write locks 0 pid/thread 30034/1147971904 > 5 dd= 0 locks held 0 write locks 0 pid/thread 30034/47555767609232 > 6 dd= 0 locks held 0 write locks 0 pid/thread 30034/1139579200 > 7 dd= 0 locks held 0 write locks 0 pid/thread 30034/1147971904 > 8 dd= 0 locks held 0 write locks 0 pid/thread 30034/1131186496 > 9 dd= 0 locks held 1 write locks 0 pid/thread 30034/1122793792 > 9 READ 1 HELD objectClass.bdb handle 0 > a dd= 0 locks held 0 write locks 0 pid/thread 30034/1122793792 > b dd= 0 locks held 0 write locks 0 pid/thread 30034/1122793792 > c dd= 0 locks held 1 write locks 0 pid/thread 30034/1122793792 > c READ 1 HELD uid.bdb handle 0 > d dd= 0 locks held 0 write locks 0 pid/thread 30034/1122793792 > e dd= 0 locks held 0 write locks 0 pid/thread 30034/1122793792 > f dd= 0 locks held 0 write locks 0 pid/thread 30034/1122793792 > 10 dd= 0 locks held 1 write locks 0 pid/thread 30034/1147971904 > 10 READ 1 HELD member.bdb handle 0 > 11 dd= 0 locks held 0 write locks 0 pid/thread 30034/1147971904 > 12 dd= 0 locks held 0 write locks 0 pid/thread 30034/1147971904 > 13 dd= 0 locks held 1 write locks 0 pid/thread 30034/1147971904 > 13 READ 1 HELD mail.bdb handle 0 > 14 dd= 0 locks held 0 write locks 0 pid/thread 30034/1147971904 > 15 dd= 0 locks held 0 write locks 0 pid/thread 30034/1147971904 > 16 dd= 0 locks held 0 write locks 0 pid/thread 30034/1147971904 > 17 dd= 0 locks held 0 write locks 0 pid/thread 30034/1147971904 > 18 dd= 0 locks held 1 write locks 0 pid/thread 30034/1147971904 > 18 READ 1 HELD sn.bdb handle 0 > 19 dd= 0 locks held 0 write locks 0 pid/thread 30034/1147971904 > 1a dd= 0 locks held 0 write locks 0 pid/thread 30034/1147971904 > 1b dd= 0 locks held 1 write locks 0 pid/thread 30034/1147971904 > 1b READ 1 HELD cn.bdb handle 0 > 1c dd= 0 locks held 0 write locks 0 pid/thread 30034/1147971904 > 1d dd= 0 locks held 0 write locks 0 pid/thread 30034/1147971904 > 1e dd= 0 locks held 0 write locks 0 pid/thread 30034/1122793792 > 1f dd= 0 locks held 0 write locks 0 pid/thread 30034/1131186496 > 80000003 dd= 0 locks held 0 write locks 0 pid/thread 30034/47555767609232 > 80000004 dd= 0 locks held 0 write locks 0 pid/thread 30034/1139579200 > 80000005 dd= 0 locks held 0 write locks 0 pid/thread 30034/1147971904 > 80000006 dd= 0 locks held 0 write locks 0 pid/thread 30034/1131186496 > 80000007 dd= 0 locks held 0 write locks 0 pid/thread 30034/1122793792 > 80000026 dd= 0 locks held 1 write locks 0 pid/thread 30034/1122793792 > 80000026 READ 1 HELD 0x5e948 len: 9 data: 0x560x0500000000000000 > 80000027 dd= 0 locks held 1 write locks 0 pid/thread 30034/1131186496 > 80000027 READ 1 HELD 0x36490 len: 9 data: 0x370000000000000000 > 80000028 dd= 0 locks held 1 write locks 0 pid/thread 30034/1131186496 > 80000028 WRITE 1 WAIT mail.bdb page 3 > 80000028 READ 1 HELD mail.bdb page 3 > 80000029 dd= 0 locks held 1 write locks 0 pid/thread 30034/1122793792 > 80000029 WRITE 1 WAIT mail.bdb page 3 > 80000029 READ 1 HELD mail.bdb page 3 > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Locks grouped by object: > Locker Mode Count Status ----------------- Object --------------- > 80000027 READ 1 HELD 0x36490 len: 9 data: 0x370000000000000000 > > 1b READ 1 HELD cn.bdb handle 0 > > 10 READ 1 HELD member.bdb handle 0 > > 9 READ 1 HELD objectClass.bdb handle 0 > > c READ 1 HELD uid.bdb handle 0 > > 80000026 READ 1 HELD 0x5e948 len: 9 data: 0x560x0500000000000000 > > 1 READ 1 HELD id2entry.bdb handle 0 > > 18 READ 1 HELD sn.bdb handle 0 > > 3 READ 1 HELD dn2id.bdb handle 0 > > 80000029 READ 1 HELD mail.bdb page 3 > 80000028 READ 1 HELD mail.bdb page 3 > 80000029 WRITE 1 WAIT mail.bdb page 3 > 80000028 WRITE 1 WAIT mail.bdb page 3 > > 13 READ 1 HELD mail.bdb handle 0 > > db_stat -C ol (4.7.25) > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Lock REGINFO information: > Lock Region type > 5 Region ID > /apps/DECCLASA-1/data/openldap/__db.005 Region name > 0x2b4a8a577000 Original region address > 0x2b4a8a577000 Region address > 0x2b4a8a577138 Region primary address > 0 Region maximum allocation > 0 Region allocated > Region allocations: 3006 allocations, 0 failures, 0 frees, 1 longest > REGION_JOIN_OK Region flags > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Locks grouped by lockers: > Locker Mode Count Status ----------------- Object --------------- > 1 dd= 0 locks held 1 write locks 0 pid/thread 32447/47463753631632 > 1 READ 1 HELD id2entry.bdb handle 0 > 2 dd= 0 locks held 0 write locks 0 pid/thread 32447/47463753631632 > 3 dd= 0 locks held 1 write locks 0 pid/thread 32447/47463753631632 > 3 READ 1 HELD dn2id.bdb handle 0 > 4 dd= 0 locks held 0 write locks 0 pid/thread 32447/1114126656 > 5 dd= 0 locks held 0 write locks 0 pid/thread 32447/47463753631632 > 6 dd= 0 locks held 0 write locks 0 pid/thread 32447/1097341248 > 7 dd= 0 locks held 1 write locks 0 pid/thread 32447/1097341248 > 7 READ 1 HELD objectClass.bdb handle 0 > 8 dd= 0 locks held 0 write locks 0 pid/thread 32447/1097341248 > 9 dd= 0 locks held 0 write locks 0 pid/thread 32447/1097341248 > a dd= 0 locks held 0 write locks 0 pid/thread 32447/1097341248 > b dd= 0 locks held 0 write locks 0 pid/thread 32447/1097341248 > c dd= 0 locks held 1 write locks 0 pid/thread 32447/1097341248 > c READ 1 HELD cn.bdb handle 0 > d dd= 0 locks held 0 write locks 0 pid/thread 32447/1097341248 > e dd= 0 locks held 0 write locks 0 pid/thread 32447/1097341248 > f dd= 0 locks held 1 write locks 0 pid/thread 32447/1097341248 > f READ 1 HELD uid.bdb handle 0 > 10 dd= 0 locks held 0 write locks 0 pid/thread 32447/1097341248 > 11 dd= 0 locks held 0 write locks 0 pid/thread 32447/1097341248 > 12 dd= 0 locks held 1 write locks 0 pid/thread 32447/1097341248 > 12 READ 1 HELD member.bdb handle 0 > 13 dd= 0 locks held 0 write locks 0 pid/thread 32447/1097341248 > 14 dd= 0 locks held 0 write locks 0 pid/thread 32447/1097341248 > 15 dd= 0 locks held 1 write locks 0 pid/thread 32447/1105733952 > 15 READ 1 HELD mail.bdb handle 0 > 16 dd= 0 locks held 0 write locks 0 pid/thread 32447/1105733952 > 17 dd= 0 locks held 0 write locks 0 pid/thread 32447/1105733952 > 18 dd= 0 locks held 0 write locks 0 pid/thread 32447/1105733952 > 19 dd= 0 locks held 0 write locks 0 pid/thread 32447/1105733952 > 1a dd= 0 locks held 1 write locks 0 pid/thread 32447/1105733952 > 1a READ 1 HELD sn.bdb handle 0 > 1b dd= 0 locks held 0 write locks 0 pid/thread 32447/1105733952 > 1c dd= 0 locks held 0 write locks 0 pid/thread 32447/1105733952 > 1d dd= 0 locks held 0 write locks 0 pid/thread 32447/1105733952 > 1e dd= 0 locks held 0 write locks 0 pid/thread 32447/1105733952 > 1f dd= 0 locks held 0 write locks 0 pid/thread 32447/1097341248 > 80000003 dd= 0 locks held 0 write locks 0 pid/thread 32447/47463753631632 > 80000004 dd= 0 locks held 0 write locks 0 pid/thread 32447/1097341248 > 80000008 dd= 0 locks held 0 write locks 0 pid/thread 32447/1105733952 > 80000038 dd= 0 locks held 0 write locks 0 pid/thread 32447/1114126656 > 800000a9 dd= 0 locks held 1 write locks 0 pid/thread 32447/1097341248 > 800000a9 READ 1 HELD 0x2d228 len: 9 data: 0x370000000000000000 > 800000aa dd= 0 locks held 2 write locks 0 pid/thread 32447/1097341248 > 800000aa WRITE 1 WAIT mail.bdb page 3 > 800000aa READ 1 HELD mail.bdb page 1 > 800000aa READ 1 HELD mail.bdb page 3 > 800000ab dd= 0 locks held 1 write locks 0 pid/thread 32447/1105733952 > 800000ab READ 1 HELD 0x43d58 len: 9 data: 0x540x0500000000000000 > 800000ac dd= 0 locks held 2 write locks 0 pid/thread 32447/1105733952 > 800000ac WRITE 1 WAIT mail.bdb page 3 > 800000ac READ 1 HELD mail.bdb page 1 > 800000ac READ 1 HELD mail.bdb page 3 > 800000b1 dd= 0 locks held 0 write locks 0 pid/thread 32447/1122519360 > 800000b2 dd= 0 locks held 0 write locks 0 pid/thread 32447/1130912064 > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Locks grouped by object: > Locker Mode Count Status ----------------- Object --------------- > 800000a9 READ 1 HELD 0x2d228 len: 9 data: 0x370000000000000000 > > 1 READ 1 HELD id2entry.bdb handle 0 > > 3 READ 1 HELD dn2id.bdb handle 0 > > 7 READ 1 HELD objectClass.bdb handle 0 > > f READ 1 HELD uid.bdb handle 0 > > 1a READ 1 HELD sn.bdb handle 0 > > 800000aa READ 1 HELD mail.bdb page 3 > 800000ac READ 1 HELD mail.bdb page 3 > 800000aa WRITE 1 WAIT mail.bdb page 3 > 800000ac WRITE 1 WAIT mail.bdb page 3 > > c READ 1 HELD cn.bdb handle 0 > > 15 READ 1 HELD mail.bdb handle 0 > > 800000aa READ 1 HELD mail.bdb page 1 > 800000ac READ 1 HELD mail.bdb page 1 > > 12 READ 1 HELD member.bdb handle 0 > > 800000ab READ 1 HELD 0x43d58 len: 9 data: 0x540x0500000000000000 > > > We have also collected the backtrace of threads for both DB versions > which I have uploaded to: > https://dl.dropboxusercontent.com/u/92115703/dusan_gdb_threads_4.8.30_ > 20130625.txt > > https://dl.dropboxusercontent.com/u/92115703/dusan_gdb_threads_4.7.25_ > 20130625.txt > > -- -- 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#7377) Poor libmdb error handling
by h.b.furuseth＠usit.uio.no 26 Jun '13

26 Jun '13

I wrote: > at > least MDB_KEYEXIST can happen after touching pages, which affects > the txn size even if the change "does nothing". Only when updating subDBs, I think. -- Hallvard

1 0

Re: (ITS#7377) Poor libmdb error handling
by h.b.furuseth＠usit.uio.no 26 Jun '13

26 Jun '13

Howard Chu writes: > h.b.furuseth(a)usit.uio.no wrote: >> Changes from a failed liblmdb operation can be visible. Sometimes >> the resulting DB will also be inconsistent. The operation should >> invalidate the affected transaction/cursors or revert the change. > > The transaction should be invalidated. Nothing more can be done > once any error occurs in a transaction. That would break back-mdb for MDB_NOTFOUND/MDB_KEYEXIST. And at least MDB_KEYEXIST can happen after touching pages, which affects the txn size even if the change "does nothing". I expected to generally invalidate except in necessary cases, and from then on make more cases "gentle" at our convenience without spending much time on it. >> put(MDB_MULTIPLE) can write some of the provided items and then >> fail, but be able to keep the txn usable. (...) > > No, "partial success" is not allowed. A transaction is atomic, all > or nothing. It would be atomic like a partial OS write(). It'd be up to the user what to do next. Not that I care myself if it is supported. >> A failed txn could still grow the txn size, unless MDB "un-touches" >> pages which memcmp says have not changed, rewinds me_pglast and >> me_pghead, etc. Which seems a lot of work, likely not worth the >> trouble. > > pghead/pglast should not persist into the environment until a successful > commit. Until then any error should just discard them. Sorry, I meant a failed _operation_ could grow them and thus affect the committed freelist size. >> I think cursors need a C_INVALID flag, so future ops cannot give a >> surprising success result instead of failing: get(MDB_NEXT/MDB_PREV) >> take ~C_INITIALIZED to mean (re)start from the beginning/end. > > Good idea. ...or C_VALID so a single OR/AND can set/clear them both. >> Don't know how often reverting is a relevant option. (...) > > Reverting is irrelevant. Once a txn is aborted no changes are visible. True, but I meant while the txn is still live and usable. Hopefully it's only relevant for "nice to have" cases. -- Hallvard

1 0

Re: (ITS#7377) Poor libmdb error handling
by hyc＠symas.com 26 Jun '13

26 Jun '13

h.b.furuseth(a)usit.uio.no wrote: > Changes from a failed liblmdb operation can be visible. Sometimes > the resulting DB will also be inconsistent. The operation should > invalidate the affected transaction/cursors or revert the change. The transaction should be invalidated. Nothing more can be done once any error occurs in a transaction. > At least I hope it's feasible to invalidate so the user cannot see > surprising results, instead of just documenting "don't do that". > > Related issues: > > put(MDB_MULTIPLE) can write some of the provided items and then > fail, but be able to keep the txn usable. It should invalidate the > txn anyway, or document that the caller must check for e.g. return > value MDB_PARTIAL_SUCCESS. Maybe invalidate unless the the caller > requests support for partial success. put() would update the input > params to indicate which items remain unwritten. No, "partial success" is not allowed. A transaction is atomic, all or nothing. > A failed txn could still grow the txn size, unless MDB "un-touches" > pages which memcmp says have not changed, rewinds me_pglast and > me_pghead, etc. Which seems a lot of work, likely not worth the > trouble. pghead/pglast should not persist into the environment until a successful commit. Until then any error should just discard them. > > I think cursors need a C_INVALID flag, so future ops cannot give a > surprising success result instead of failing: get(MDB_NEXT/MDB_PREV) > take ~C_INITIALIZED to mean (re)start from the beginning/end. Good idea. > Don't know how often reverting is a relevant option. Rearranging > code can help, but maybe not much. E.g. the mdb_del() in mdb_drop() > can do some harmless touches and then fail cleanly - but mdb_drop() > must invalidate the txn anyway since mdb_drop0() has deleted pages. > Unless it does extra work - remember mt_free_pgs[0] before and after > mdb_drop0(), then delete from mt_free_pgs[] the pages added by > drop0. Or drop0 could be done last since it can fail cleanly just > by resetting mt_free_pgs[0]. But I don't know if del(MDB_MULTIPLE) > can also do that if the DB used a subpage. drop0 can't examine the > subpage after it got deleted. > Reverting is irrelevant. Once a txn is aborted no changes are visible. -- -- 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#7377) Poor libmdb error handling
by h.b.furuseth＠usit.uio.no 26 Jun '13

26 Jun '13

Changes from a failed liblmdb operation can be visible. Sometimes the resulting DB will also be inconsistent. The operation should invalidate the affected transaction/cursors or revert the change. At least I hope it's feasible to invalidate so the user cannot see surprising results, instead of just documenting "don't do that". Related issues: put(MDB_MULTIPLE) can write some of the provided items and then fail, but be able to keep the txn usable. It should invalidate the txn anyway, or document that the caller must check for e.g. return value MDB_PARTIAL_SUCCESS. Maybe invalidate unless the the caller requests support for partial success. put() would update the input params to indicate which items remain unwritten. A failed txn could still grow the txn size, unless MDB "un-touches" pages which memcmp says have not changed, rewinds me_pglast and me_pghead, etc. Which seems a lot of work, likely not worth the trouble. I think cursors need a C_INVALID flag, so future ops cannot give a surprising success result instead of failing: get(MDB_NEXT/MDB_PREV) take ~C_INITIALIZED to mean (re)start from the beginning/end. Don't know how often reverting is a relevant option. Rearranging code can help, but maybe not much. E.g. the mdb_del() in mdb_drop() can do some harmless touches and then fail cleanly - but mdb_drop() must invalidate the txn anyway since mdb_drop0() has deleted pages. Unless it does extra work - remember mt_free_pgs[0] before and after mdb_drop0(), then delete from mt_free_pgs[] the pages added by drop0. Or drop0 could be done last since it can fail cleanly just by resetting mt_free_pgs[0]. But I don't know if del(MDB_MULTIPLE) can also do that if the DB used a subpage. drop0 can't examine the subpage after it got deleted. -- Hallvard

1 0

Re: (ITS#7633) Slapd hangs on hdb write lock
by hyc＠symas.com 26 Jun '13

26 Jun '13

dusan.fric(a)t-systems.sk wrote: > Full_Name: Dusan Fric > Version: 2.4.32 > OS: RHEL 5.7 x64 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (88.212.40.139) > > > We are experiencing frequent hangs in slapd. Once hung we usualy cannot continue > to > connect until we kill -9 the slapd process and restart it. The directory is used > for 2 applications as user eDir and we are using it in production over 1 month - > we have noted the busier the directory becomes the more often it hangs (now > twice per week). > > We have installed identical configurations on 3 environments, each has only one > single server (no replication). There are 30k entries in the directory > (production). > > We are running: > > RHEL 5.7 x64 (VMWare with NFS mountpoints) > OpenLDAP 2.4.32 > Berkeley DB 4.8.30 (4.7.25) > > We were starting with DB 4.8.30, after downgrade to version 4.7.25 (according to > ITS#7378 - https://www.openldap.org/its/index.cgi/Incoming?id=7378;selectid=7378) > we are facing the same issue. Note that BDB 4.7.25 is known to self-deadlock if you haven't applied all of the patches. http://www.oracle.com/technetwork/products/berkeleydb/patch-088170.html -- -- 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#7633) Slapd hangs on hdb write lock
by hyc＠symas.com 26 Jun '13

26 Jun '13

dusan.fric(a)t-systems.sk wrote: > Full_Name: Dusan Fric > Version: 2.4.32 > OS: RHEL 5.7 x64 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (88.212.40.139) > > > We are experiencing frequent hangs in slapd. Once hung we usualy cannot continue > to > connect until we kill -9 the slapd process and restart it. The directory is used > for 2 applications as user eDir and we are using it in production over 1 month - > we have noted the busier the directory becomes the more often it hangs (now > twice per week). > > We have installed identical configurations on 3 environments, each has only one > single server (no replication). There are 30k entries in the directory > (production). > > We are running: > > RHEL 5.7 x64 (VMWare with NFS mountpoints) > OpenLDAP 2.4.32 > Berkeley DB 4.8.30 (4.7.25) > > We were starting with DB 4.8.30, after downgrade to version 4.7.25 (according to > ITS#7378 - https://www.openldap.org/its/index.cgi/Incoming?id=7378;selectid=7378) > we are facing the same issue. > > The problem occurs when two requests simultaneously try to update attributes of > a record and in most cases of the same DN value. > We can easily reproduce it with a java test program running 2 threads each > connecting to the ldap server and updating the record for a particular DN > value. > It need not be the same DN value but DN values which reside on the same BDB > page. Thanks for the traces, but the information you've provided shows that this is a BDB problem, not an OpenLDAP bug. You'll have to contact Oracle for help. The BDB deadlock detector is supposed to handle these situations. For example in your 4.8.30 lock status there are only 2 conflicting transactions 80000028 and 80000029 and they are only contending on a single page. This is one of the most elementary deadlock situations. You might try different settings for the deadlock detector, but ultimately this appears to be a BDB bug and the choice of detector shouldn't matter. > Configuration > > olc cn=config (part): > dn: cn=config > objectClass: olcGlobal > cn: config > olcConcurrency: 0 > olcConnMaxPending: 100 > olcConnMaxPendingAuth: 1000 > olcSockbufMaxIncoming: 262143 > olcSockbufMaxIncomingAuth: 16777215 > olcThreads: 32 > > olc DB hdb config (part): > dn: olcDatabase={1}hdb,cn=config > objectClass: olcHdbConfig > objectClass: olcDatabaseConfig > olcDatabase: {1}hdb > olcDbCacheSize: 80000 > olcDbCheckpoint: 128 5 > olcDbConfig: {0}set_cachesize 0 268435456 1 > olcDbConfig: {1}set_lg_max 10485760 > olcDbConfig: {2}set_lg_bsize 2097152 > olcDbConfig: {3}set_lg_dir /pkg/openldap/dblog > olcDbConfig: {4}set_lg_regionmax 262144 > olcDbConfig: {5}set_lk_detect DB_LOCK_EXPIRE > olcDbConfig: {6}set_flags DB_TXN_NOSYNC > olcDbDirtyRead: FALSE > olcDbDNcacheSize: 0 > olcDbIDLcacheSize: 240000 > olcDbIndex: default eq,sub > olcDbIndex: objectClass eq > olcDbIndex: cn eq,sub > olcDbIndex: uid eq,sub > olcDbIndex: mail pres,eq > olcDbIndex: sn eq,sub > olcDbIndex: member eq > olcDbLinearIndex: FALSE > olcDbMode: 0600 > olcDbNoSync: TRUE > olcDbSearchStack: 20 > olcDbShmKey: 0 > olcLastMod: TRUE > olcMaxDerefDepth: 15 > olcMonitoring: TRUE > olcReadOnly: FALSE > > We have managed to collect db_stat lock information, which indicates the same > issue with DB write locks on both DB versions. > > db_stat -C ol (4.8.30) > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Lock REGINFO information: > Lock Region type > 5 Region ID > /apps/DECCLASA-1/data/openldap/__db.005 Region name > 0x2ab41cdc3000 Region address > 0x2ab41cdc3138 Region primary address > 0 Region maximum allocation > 0 Region allocated > Region allocations: 3006 allocations, 0 failures, 0 frees, 1 longest > REGION_JOIN_OK Region flags > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Locks grouped by lockers: > Locker Mode Count Status ----------------- Object --------------- > 1 dd= 0 locks held 1 write locks 0 pid/thread 30034/47555767609232 > 1 READ 1 HELD id2entry.bdb handle 0 > 2 dd= 0 locks held 0 write locks 0 pid/thread 30034/47555767609232 > 3 dd= 0 locks held 1 write locks 0 pid/thread 30034/47555767609232 > 3 READ 1 HELD dn2id.bdb handle 0 > 4 dd= 0 locks held 0 write locks 0 pid/thread 30034/1147971904 > 5 dd= 0 locks held 0 write locks 0 pid/thread 30034/47555767609232 > 6 dd= 0 locks held 0 write locks 0 pid/thread 30034/1139579200 > 7 dd= 0 locks held 0 write locks 0 pid/thread 30034/1147971904 > 8 dd= 0 locks held 0 write locks 0 pid/thread 30034/1131186496 > 9 dd= 0 locks held 1 write locks 0 pid/thread 30034/1122793792 > 9 READ 1 HELD objectClass.bdb handle 0 > a dd= 0 locks held 0 write locks 0 pid/thread 30034/1122793792 > b dd= 0 locks held 0 write locks 0 pid/thread 30034/1122793792 > c dd= 0 locks held 1 write locks 0 pid/thread 30034/1122793792 > c READ 1 HELD uid.bdb handle 0 > d dd= 0 locks held 0 write locks 0 pid/thread 30034/1122793792 > e dd= 0 locks held 0 write locks 0 pid/thread 30034/1122793792 > f dd= 0 locks held 0 write locks 0 pid/thread 30034/1122793792 > 10 dd= 0 locks held 1 write locks 0 pid/thread 30034/1147971904 > 10 READ 1 HELD member.bdb handle 0 > 11 dd= 0 locks held 0 write locks 0 pid/thread 30034/1147971904 > 12 dd= 0 locks held 0 write locks 0 pid/thread 30034/1147971904 > 13 dd= 0 locks held 1 write locks 0 pid/thread 30034/1147971904 > 13 READ 1 HELD mail.bdb handle 0 > 14 dd= 0 locks held 0 write locks 0 pid/thread 30034/1147971904 > 15 dd= 0 locks held 0 write locks 0 pid/thread 30034/1147971904 > 16 dd= 0 locks held 0 write locks 0 pid/thread 30034/1147971904 > 17 dd= 0 locks held 0 write locks 0 pid/thread 30034/1147971904 > 18 dd= 0 locks held 1 write locks 0 pid/thread 30034/1147971904 > 18 READ 1 HELD sn.bdb handle 0 > 19 dd= 0 locks held 0 write locks 0 pid/thread 30034/1147971904 > 1a dd= 0 locks held 0 write locks 0 pid/thread 30034/1147971904 > 1b dd= 0 locks held 1 write locks 0 pid/thread 30034/1147971904 > 1b READ 1 HELD cn.bdb handle 0 > 1c dd= 0 locks held 0 write locks 0 pid/thread 30034/1147971904 > 1d dd= 0 locks held 0 write locks 0 pid/thread 30034/1147971904 > 1e dd= 0 locks held 0 write locks 0 pid/thread 30034/1122793792 > 1f dd= 0 locks held 0 write locks 0 pid/thread 30034/1131186496 > 80000003 dd= 0 locks held 0 write locks 0 pid/thread 30034/47555767609232 > 80000004 dd= 0 locks held 0 write locks 0 pid/thread 30034/1139579200 > 80000005 dd= 0 locks held 0 write locks 0 pid/thread 30034/1147971904 > 80000006 dd= 0 locks held 0 write locks 0 pid/thread 30034/1131186496 > 80000007 dd= 0 locks held 0 write locks 0 pid/thread 30034/1122793792 > 80000026 dd= 0 locks held 1 write locks 0 pid/thread 30034/1122793792 > 80000026 READ 1 HELD 0x5e948 len: 9 data: 0x560x0500000000000000 > 80000027 dd= 0 locks held 1 write locks 0 pid/thread 30034/1131186496 > 80000027 READ 1 HELD 0x36490 len: 9 data: 0x370000000000000000 > 80000028 dd= 0 locks held 1 write locks 0 pid/thread 30034/1131186496 > 80000028 WRITE 1 WAIT mail.bdb page 3 > 80000028 READ 1 HELD mail.bdb page 3 > 80000029 dd= 0 locks held 1 write locks 0 pid/thread 30034/1122793792 > 80000029 WRITE 1 WAIT mail.bdb page 3 > 80000029 READ 1 HELD mail.bdb page 3 > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Locks grouped by object: > Locker Mode Count Status ----------------- Object --------------- > 80000027 READ 1 HELD 0x36490 len: 9 data: 0x370000000000000000 > > 1b READ 1 HELD cn.bdb handle 0 > > 10 READ 1 HELD member.bdb handle 0 > > 9 READ 1 HELD objectClass.bdb handle 0 > > c READ 1 HELD uid.bdb handle 0 > > 80000026 READ 1 HELD 0x5e948 len: 9 data: 0x560x0500000000000000 > > 1 READ 1 HELD id2entry.bdb handle 0 > > 18 READ 1 HELD sn.bdb handle 0 > > 3 READ 1 HELD dn2id.bdb handle 0 > > 80000029 READ 1 HELD mail.bdb page 3 > 80000028 READ 1 HELD mail.bdb page 3 > 80000029 WRITE 1 WAIT mail.bdb page 3 > 80000028 WRITE 1 WAIT mail.bdb page 3 > > 13 READ 1 HELD mail.bdb handle 0 > > db_stat -C ol (4.7.25) > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Lock REGINFO information: > Lock Region type > 5 Region ID > /apps/DECCLASA-1/data/openldap/__db.005 Region name > 0x2b4a8a577000 Original region address > 0x2b4a8a577000 Region address > 0x2b4a8a577138 Region primary address > 0 Region maximum allocation > 0 Region allocated > Region allocations: 3006 allocations, 0 failures, 0 frees, 1 longest > REGION_JOIN_OK Region flags > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Locks grouped by lockers: > Locker Mode Count Status ----------------- Object --------------- > 1 dd= 0 locks held 1 write locks 0 pid/thread 32447/47463753631632 > 1 READ 1 HELD id2entry.bdb handle 0 > 2 dd= 0 locks held 0 write locks 0 pid/thread 32447/47463753631632 > 3 dd= 0 locks held 1 write locks 0 pid/thread 32447/47463753631632 > 3 READ 1 HELD dn2id.bdb handle 0 > 4 dd= 0 locks held 0 write locks 0 pid/thread 32447/1114126656 > 5 dd= 0 locks held 0 write locks 0 pid/thread 32447/47463753631632 > 6 dd= 0 locks held 0 write locks 0 pid/thread 32447/1097341248 > 7 dd= 0 locks held 1 write locks 0 pid/thread 32447/1097341248 > 7 READ 1 HELD objectClass.bdb handle 0 > 8 dd= 0 locks held 0 write locks 0 pid/thread 32447/1097341248 > 9 dd= 0 locks held 0 write locks 0 pid/thread 32447/1097341248 > a dd= 0 locks held 0 write locks 0 pid/thread 32447/1097341248 > b dd= 0 locks held 0 write locks 0 pid/thread 32447/1097341248 > c dd= 0 locks held 1 write locks 0 pid/thread 32447/1097341248 > c READ 1 HELD cn.bdb handle 0 > d dd= 0 locks held 0 write locks 0 pid/thread 32447/1097341248 > e dd= 0 locks held 0 write locks 0 pid/thread 32447/1097341248 > f dd= 0 locks held 1 write locks 0 pid/thread 32447/1097341248 > f READ 1 HELD uid.bdb handle 0 > 10 dd= 0 locks held 0 write locks 0 pid/thread 32447/1097341248 > 11 dd= 0 locks held 0 write locks 0 pid/thread 32447/1097341248 > 12 dd= 0 locks held 1 write locks 0 pid/thread 32447/1097341248 > 12 READ 1 HELD member.bdb handle 0 > 13 dd= 0 locks held 0 write locks 0 pid/thread 32447/1097341248 > 14 dd= 0 locks held 0 write locks 0 pid/thread 32447/1097341248 > 15 dd= 0 locks held 1 write locks 0 pid/thread 32447/1105733952 > 15 READ 1 HELD mail.bdb handle 0 > 16 dd= 0 locks held 0 write locks 0 pid/thread 32447/1105733952 > 17 dd= 0 locks held 0 write locks 0 pid/thread 32447/1105733952 > 18 dd= 0 locks held 0 write locks 0 pid/thread 32447/1105733952 > 19 dd= 0 locks held 0 write locks 0 pid/thread 32447/1105733952 > 1a dd= 0 locks held 1 write locks 0 pid/thread 32447/1105733952 > 1a READ 1 HELD sn.bdb handle 0 > 1b dd= 0 locks held 0 write locks 0 pid/thread 32447/1105733952 > 1c dd= 0 locks held 0 write locks 0 pid/thread 32447/1105733952 > 1d dd= 0 locks held 0 write locks 0 pid/thread 32447/1105733952 > 1e dd= 0 locks held 0 write locks 0 pid/thread 32447/1105733952 > 1f dd= 0 locks held 0 write locks 0 pid/thread 32447/1097341248 > 80000003 dd= 0 locks held 0 write locks 0 pid/thread 32447/47463753631632 > 80000004 dd= 0 locks held 0 write locks 0 pid/thread 32447/1097341248 > 80000008 dd= 0 locks held 0 write locks 0 pid/thread 32447/1105733952 > 80000038 dd= 0 locks held 0 write locks 0 pid/thread 32447/1114126656 > 800000a9 dd= 0 locks held 1 write locks 0 pid/thread 32447/1097341248 > 800000a9 READ 1 HELD 0x2d228 len: 9 data: 0x370000000000000000 > 800000aa dd= 0 locks held 2 write locks 0 pid/thread 32447/1097341248 > 800000aa WRITE 1 WAIT mail.bdb page 3 > 800000aa READ 1 HELD mail.bdb page 1 > 800000aa READ 1 HELD mail.bdb page 3 > 800000ab dd= 0 locks held 1 write locks 0 pid/thread 32447/1105733952 > 800000ab READ 1 HELD 0x43d58 len: 9 data: 0x540x0500000000000000 > 800000ac dd= 0 locks held 2 write locks 0 pid/thread 32447/1105733952 > 800000ac WRITE 1 WAIT mail.bdb page 3 > 800000ac READ 1 HELD mail.bdb page 1 > 800000ac READ 1 HELD mail.bdb page 3 > 800000b1 dd= 0 locks held 0 write locks 0 pid/thread 32447/1122519360 > 800000b2 dd= 0 locks held 0 write locks 0 pid/thread 32447/1130912064 > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Locks grouped by object: > Locker Mode Count Status ----------------- Object --------------- > 800000a9 READ 1 HELD 0x2d228 len: 9 data: 0x370000000000000000 > > 1 READ 1 HELD id2entry.bdb handle 0 > > 3 READ 1 HELD dn2id.bdb handle 0 > > 7 READ 1 HELD objectClass.bdb handle 0 > > f READ 1 HELD uid.bdb handle 0 > > 1a READ 1 HELD sn.bdb handle 0 > > 800000aa READ 1 HELD mail.bdb page 3 > 800000ac READ 1 HELD mail.bdb page 3 > 800000aa WRITE 1 WAIT mail.bdb page 3 > 800000ac WRITE 1 WAIT mail.bdb page 3 > > c READ 1 HELD cn.bdb handle 0 > > 15 READ 1 HELD mail.bdb handle 0 > > 800000aa READ 1 HELD mail.bdb page 1 > 800000ac READ 1 HELD mail.bdb page 1 > > 12 READ 1 HELD member.bdb handle 0 > > 800000ab READ 1 HELD 0x43d58 len: 9 data: 0x540x0500000000000000 > > > We have also collected the backtrace of threads for both DB versions which I > have uploaded to: > https://dl.dropboxusercontent.com/u/92115703/dusan_gdb_threads_4.8.30_20130… > > https://dl.dropboxusercontent.com/u/92115703/dusan_gdb_threads_4.7.25_20130… > > -- -- 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#7633) Slapd hangs on hdb write lock
by dusan.fric＠t-systems.sk 26 Jun '13

26 Jun '13

Full_Name: Dusan Fric Version: 2.4.32 OS: RHEL 5.7 x64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (88.212.40.139) We are experiencing frequent hangs in slapd. Once hung we usualy cannot continue to connect until we kill -9 the slapd process and restart it. The directory is used for 2 applications as user eDir and we are using it in production over 1 month - we have noted the busier the directory becomes the more often it hangs (now twice per week). We have installed identical configurations on 3 environments, each has only one single server (no replication). There are 30k entries in the directory (production). We are running: RHEL 5.7 x64 (VMWare with NFS mountpoints) OpenLDAP 2.4.32 Berkeley DB 4.8.30 (4.7.25) We were starting with DB 4.8.30, after downgrade to version 4.7.25 (according to ITS#7378 - https://www.openldap.org/its/index.cgi/Incoming?id=7378;selectid=7378) we are facing the same issue. The problem occurs when two requests simultaneously try to update attributes of a record and in most cases of the same DN value. We can easily reproduce it with a java test program running 2 threads each connecting to the ldap server and updating the record for a particular DN value. It need not be the same DN value but DN values which reside on the same BDB page. Configuration olc cn=config (part): dn: cn=config objectClass: olcGlobal cn: config olcConcurrency: 0 olcConnMaxPending: 100 olcConnMaxPendingAuth: 1000 olcSockbufMaxIncoming: 262143 olcSockbufMaxIncomingAuth: 16777215 olcThreads: 32 olc DB hdb config (part): dn: olcDatabase={1}hdb,cn=config objectClass: olcHdbConfig objectClass: olcDatabaseConfig olcDatabase: {1}hdb olcDbCacheSize: 80000 olcDbCheckpoint: 128 5 olcDbConfig: {0}set_cachesize 0 268435456 1 olcDbConfig: {1}set_lg_max 10485760 olcDbConfig: {2}set_lg_bsize 2097152 olcDbConfig: {3}set_lg_dir /pkg/openldap/dblog olcDbConfig: {4}set_lg_regionmax 262144 olcDbConfig: {5}set_lk_detect DB_LOCK_EXPIRE olcDbConfig: {6}set_flags DB_TXN_NOSYNC olcDbDirtyRead: FALSE olcDbDNcacheSize: 0 olcDbIDLcacheSize: 240000 olcDbIndex: default eq,sub olcDbIndex: objectClass eq olcDbIndex: cn eq,sub olcDbIndex: uid eq,sub olcDbIndex: mail pres,eq olcDbIndex: sn eq,sub olcDbIndex: member eq olcDbLinearIndex: FALSE olcDbMode: 0600 olcDbNoSync: TRUE olcDbSearchStack: 20 olcDbShmKey: 0 olcLastMod: TRUE olcMaxDerefDepth: 15 olcMonitoring: TRUE olcReadOnly: FALSE We have managed to collect db_stat lock information, which indicates the same issue with DB write locks on both DB versions. db_stat -C ol (4.8.30) =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Lock REGINFO information: Lock Region type 5 Region ID /apps/DECCLASA-1/data/openldap/__db.005 Region name 0x2ab41cdc3000 Region address 0x2ab41cdc3138 Region primary address 0 Region maximum allocation 0 Region allocated Region allocations: 3006 allocations, 0 failures, 0 frees, 1 longest REGION_JOIN_OK Region flags =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Locks grouped by lockers: Locker Mode Count Status ----------------- Object --------------- 1 dd= 0 locks held 1 write locks 0 pid/thread 30034/47555767609232 1 READ 1 HELD id2entry.bdb handle 0 2 dd= 0 locks held 0 write locks 0 pid/thread 30034/47555767609232 3 dd= 0 locks held 1 write locks 0 pid/thread 30034/47555767609232 3 READ 1 HELD dn2id.bdb handle 0 4 dd= 0 locks held 0 write locks 0 pid/thread 30034/1147971904 5 dd= 0 locks held 0 write locks 0 pid/thread 30034/47555767609232 6 dd= 0 locks held 0 write locks 0 pid/thread 30034/1139579200 7 dd= 0 locks held 0 write locks 0 pid/thread 30034/1147971904 8 dd= 0 locks held 0 write locks 0 pid/thread 30034/1131186496 9 dd= 0 locks held 1 write locks 0 pid/thread 30034/1122793792 9 READ 1 HELD objectClass.bdb handle 0 a dd= 0 locks held 0 write locks 0 pid/thread 30034/1122793792 b dd= 0 locks held 0 write locks 0 pid/thread 30034/1122793792 c dd= 0 locks held 1 write locks 0 pid/thread 30034/1122793792 c READ 1 HELD uid.bdb handle 0 d dd= 0 locks held 0 write locks 0 pid/thread 30034/1122793792 e dd= 0 locks held 0 write locks 0 pid/thread 30034/1122793792 f dd= 0 locks held 0 write locks 0 pid/thread 30034/1122793792 10 dd= 0 locks held 1 write locks 0 pid/thread 30034/1147971904 10 READ 1 HELD member.bdb handle 0 11 dd= 0 locks held 0 write locks 0 pid/thread 30034/1147971904 12 dd= 0 locks held 0 write locks 0 pid/thread 30034/1147971904 13 dd= 0 locks held 1 write locks 0 pid/thread 30034/1147971904 13 READ 1 HELD mail.bdb handle 0 14 dd= 0 locks held 0 write locks 0 pid/thread 30034/1147971904 15 dd= 0 locks held 0 write locks 0 pid/thread 30034/1147971904 16 dd= 0 locks held 0 write locks 0 pid/thread 30034/1147971904 17 dd= 0 locks held 0 write locks 0 pid/thread 30034/1147971904 18 dd= 0 locks held 1 write locks 0 pid/thread 30034/1147971904 18 READ 1 HELD sn.bdb handle 0 19 dd= 0 locks held 0 write locks 0 pid/thread 30034/1147971904 1a dd= 0 locks held 0 write locks 0 pid/thread 30034/1147971904 1b dd= 0 locks held 1 write locks 0 pid/thread 30034/1147971904 1b READ 1 HELD cn.bdb handle 0 1c dd= 0 locks held 0 write locks 0 pid/thread 30034/1147971904 1d dd= 0 locks held 0 write locks 0 pid/thread 30034/1147971904 1e dd= 0 locks held 0 write locks 0 pid/thread 30034/1122793792 1f dd= 0 locks held 0 write locks 0 pid/thread 30034/1131186496 80000003 dd= 0 locks held 0 write locks 0 pid/thread 30034/47555767609232 80000004 dd= 0 locks held 0 write locks 0 pid/thread 30034/1139579200 80000005 dd= 0 locks held 0 write locks 0 pid/thread 30034/1147971904 80000006 dd= 0 locks held 0 write locks 0 pid/thread 30034/1131186496 80000007 dd= 0 locks held 0 write locks 0 pid/thread 30034/1122793792 80000026 dd= 0 locks held 1 write locks 0 pid/thread 30034/1122793792 80000026 READ 1 HELD 0x5e948 len: 9 data: 0x560x0500000000000000 80000027 dd= 0 locks held 1 write locks 0 pid/thread 30034/1131186496 80000027 READ 1 HELD 0x36490 len: 9 data: 0x370000000000000000 80000028 dd= 0 locks held 1 write locks 0 pid/thread 30034/1131186496 80000028 WRITE 1 WAIT mail.bdb page 3 80000028 READ 1 HELD mail.bdb page 3 80000029 dd= 0 locks held 1 write locks 0 pid/thread 30034/1122793792 80000029 WRITE 1 WAIT mail.bdb page 3 80000029 READ 1 HELD mail.bdb page 3 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Locks grouped by object: Locker Mode Count Status ----------------- Object --------------- 80000027 READ 1 HELD 0x36490 len: 9 data: 0x370000000000000000 1b READ 1 HELD cn.bdb handle 0 10 READ 1 HELD member.bdb handle 0 9 READ 1 HELD objectClass.bdb handle 0 c READ 1 HELD uid.bdb handle 0 80000026 READ 1 HELD 0x5e948 len: 9 data: 0x560x0500000000000000 1 READ 1 HELD id2entry.bdb handle 0 18 READ 1 HELD sn.bdb handle 0 3 READ 1 HELD dn2id.bdb handle 0 80000029 READ 1 HELD mail.bdb page 3 80000028 READ 1 HELD mail.bdb page 3 80000029 WRITE 1 WAIT mail.bdb page 3 80000028 WRITE 1 WAIT mail.bdb page 3 13 READ 1 HELD mail.bdb handle 0 db_stat -C ol (4.7.25) =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Lock REGINFO information: Lock Region type 5 Region ID /apps/DECCLASA-1/data/openldap/__db.005 Region name 0x2b4a8a577000 Original region address 0x2b4a8a577000 Region address 0x2b4a8a577138 Region primary address 0 Region maximum allocation 0 Region allocated Region allocations: 3006 allocations, 0 failures, 0 frees, 1 longest REGION_JOIN_OK Region flags =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Locks grouped by lockers: Locker Mode Count Status ----------------- Object --------------- 1 dd= 0 locks held 1 write locks 0 pid/thread 32447/47463753631632 1 READ 1 HELD id2entry.bdb handle 0 2 dd= 0 locks held 0 write locks 0 pid/thread 32447/47463753631632 3 dd= 0 locks held 1 write locks 0 pid/thread 32447/47463753631632 3 READ 1 HELD dn2id.bdb handle 0 4 dd= 0 locks held 0 write locks 0 pid/thread 32447/1114126656 5 dd= 0 locks held 0 write locks 0 pid/thread 32447/47463753631632 6 dd= 0 locks held 0 write locks 0 pid/thread 32447/1097341248 7 dd= 0 locks held 1 write locks 0 pid/thread 32447/1097341248 7 READ 1 HELD objectClass.bdb handle 0 8 dd= 0 locks held 0 write locks 0 pid/thread 32447/1097341248 9 dd= 0 locks held 0 write locks 0 pid/thread 32447/1097341248 a dd= 0 locks held 0 write locks 0 pid/thread 32447/1097341248 b dd= 0 locks held 0 write locks 0 pid/thread 32447/1097341248 c dd= 0 locks held 1 write locks 0 pid/thread 32447/1097341248 c READ 1 HELD cn.bdb handle 0 d dd= 0 locks held 0 write locks 0 pid/thread 32447/1097341248 e dd= 0 locks held 0 write locks 0 pid/thread 32447/1097341248 f dd= 0 locks held 1 write locks 0 pid/thread 32447/1097341248 f READ 1 HELD uid.bdb handle 0 10 dd= 0 locks held 0 write locks 0 pid/thread 32447/1097341248 11 dd= 0 locks held 0 write locks 0 pid/thread 32447/1097341248 12 dd= 0 locks held 1 write locks 0 pid/thread 32447/1097341248 12 READ 1 HELD member.bdb handle 0 13 dd= 0 locks held 0 write locks 0 pid/thread 32447/1097341248 14 dd= 0 locks held 0 write locks 0 pid/thread 32447/1097341248 15 dd= 0 locks held 1 write locks 0 pid/thread 32447/1105733952 15 READ 1 HELD mail.bdb handle 0 16 dd= 0 locks held 0 write locks 0 pid/thread 32447/1105733952 17 dd= 0 locks held 0 write locks 0 pid/thread 32447/1105733952 18 dd= 0 locks held 0 write locks 0 pid/thread 32447/1105733952 19 dd= 0 locks held 0 write locks 0 pid/thread 32447/1105733952 1a dd= 0 locks held 1 write locks 0 pid/thread 32447/1105733952 1a READ 1 HELD sn.bdb handle 0 1b dd= 0 locks held 0 write locks 0 pid/thread 32447/1105733952 1c dd= 0 locks held 0 write locks 0 pid/thread 32447/1105733952 1d dd= 0 locks held 0 write locks 0 pid/thread 32447/1105733952 1e dd= 0 locks held 0 write locks 0 pid/thread 32447/1105733952 1f dd= 0 locks held 0 write locks 0 pid/thread 32447/1097341248 80000003 dd= 0 locks held 0 write locks 0 pid/thread 32447/47463753631632 80000004 dd= 0 locks held 0 write locks 0 pid/thread 32447/1097341248 80000008 dd= 0 locks held 0 write locks 0 pid/thread 32447/1105733952 80000038 dd= 0 locks held 0 write locks 0 pid/thread 32447/1114126656 800000a9 dd= 0 locks held 1 write locks 0 pid/thread 32447/1097341248 800000a9 READ 1 HELD 0x2d228 len: 9 data: 0x370000000000000000 800000aa dd= 0 locks held 2 write locks 0 pid/thread 32447/1097341248 800000aa WRITE 1 WAIT mail.bdb page 3 800000aa READ 1 HELD mail.bdb page 1 800000aa READ 1 HELD mail.bdb page 3 800000ab dd= 0 locks held 1 write locks 0 pid/thread 32447/1105733952 800000ab READ 1 HELD 0x43d58 len: 9 data: 0x540x0500000000000000 800000ac dd= 0 locks held 2 write locks 0 pid/thread 32447/1105733952 800000ac WRITE 1 WAIT mail.bdb page 3 800000ac READ 1 HELD mail.bdb page 1 800000ac READ 1 HELD mail.bdb page 3 800000b1 dd= 0 locks held 0 write locks 0 pid/thread 32447/1122519360 800000b2 dd= 0 locks held 0 write locks 0 pid/thread 32447/1130912064 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Locks grouped by object: Locker Mode Count Status ----------------- Object --------------- 800000a9 READ 1 HELD 0x2d228 len: 9 data: 0x370000000000000000 1 READ 1 HELD id2entry.bdb handle 0 3 READ 1 HELD dn2id.bdb handle 0 7 READ 1 HELD objectClass.bdb handle 0 f READ 1 HELD uid.bdb handle 0 1a READ 1 HELD sn.bdb handle 0 800000aa READ 1 HELD mail.bdb page 3 800000ac READ 1 HELD mail.bdb page 3 800000aa WRITE 1 WAIT mail.bdb page 3 800000ac WRITE 1 WAIT mail.bdb page 3 c READ 1 HELD cn.bdb handle 0 15 READ 1 HELD mail.bdb handle 0 800000aa READ 1 HELD mail.bdb page 1 800000ac READ 1 HELD mail.bdb page 1 12 READ 1 HELD member.bdb handle 0 800000ab READ 1 HELD 0x43d58 len: 9 data: 0x540x0500000000000000 We have also collected the backtrace of threads for both DB versions which I have uploaded to: https://dl.dropboxusercontent.com/u/92115703/dusan_gdb_threads_4.8.30_20130… https://dl.dropboxusercontent.com/u/92115703/dusan_gdb_threads_4.7.25_20130…

1 0

(ITS#7632) ldap_start_tls_s core dumps for 64 bit
by a16474＠gmail.com 25 Jun '13

25 Jun '13

Full_Name: Amit Sinha Version: openldap-2.4.35 OS: Linux 2.6.18-308.11.1.el5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (72.163.217.105) When i compile and run the below code on linux 64 bit, it core dumps in ldap_start_tls_s(). #include <ldap.h> #include <iostream> using namespace std; int main() { char* hostname = "myhost.mydomain.com" ; LDAP* l=ldap_init(hostname,389); int version = LDAP_VERSION3 ; if( LDAP_SUCCESS != ldap_set_option(NULL, LDAP_OPT_DEBUG_LEVEL, "7")) { cout << "error LDAP_OPT_DEBUG_LEVEL" << endl ; } if( LDAP_SUCCESS != ldap_set_option(l, LDAP_OPT_PROTOCOL_VERSION, &version )) { cout << "error LDAP_OPT_PROTOCOL_VERSION\n" ; } if( LDAP_SUCCESS != ldap_set_option(l, LDAP_OPT_REFERRALS, LDAP_OPT_OFF)) { cout << "error LDAP_OPT_REFERRALS\n" ; } if( LDAP_SUCCESS != ldap_set_option( NULL,LDAP_OPT_X_TLS_CTX,NULL )) { cout << "error LDAP_OPT_X_TLS_CTX\n" ; } /if( LDAP_SUCCESS != ldap_set_option( NULL,LDAP_OPT_X_TLS_CACERTDIR,"/myDirOfCert")) { cout << "error LDAP_OPT_X_TLS_CACERTDIR\n" ; } int rc ; if( LDAP_SUCCESS != ( rc = ldap_start_tls_s(l, NULL, NULL)) ) { cout << "error ldap_start_tls_s:" << ldap_err2string(rc) << endl ; } } BACKTRACE: (gdb) bt #0 0x00002b7d266bbbff in sk_value () from /root/openssl/openssl-1.0.1e/libcrypto.so.1.0.0 #1 0x00002b7d264a62fe in ssl3_output_cert_chain () from /root/openssl/openssl-1.0.1e/libssl.so.1.0.0 #2 0x00002b7d2649fffd in ssl3_send_client_certificate () from /root/openssl/openssl-1.0.1e/libssl.so.1.0.0 #3 0x00002b7d264a0531 in ssl3_connect () from /root/openssl/openssl-1.0.1e/libssl.so.1.0.0 #4 0x00002b7d264a9487 in ssl23_connect () from /root/openssl/openssl-1.0.1e/libssl.so.1.0.0 #5 0x00002b7d263676ec in tlso_session_connect (ld=<value optimized out>, sess=0x0) at tls_o.c:363 #6 0x00002b7d2636698d in ldap_int_tls_connect (ld=0x3d44e80, conn=0x3d675f0, srv=<value optimized out>) at tls2.c:362 #7 ldap_int_tls_start (ld=0x3d44e80, conn=0x3d675f0, srv=<value optimized out>) at tls2.c:860 #8 0x00002b7d26366d35 in ldap_start_tls_s (ld=0x3d44e80, serverctrls=0x0, clientctrls=<value optimized out>) at tls2.c:1040 #9 0x0000000000400dd2 in main () The open ssl version i am using is openssl-1.0.1e

1 0

Re: (ITS#7631) Overlay to rewrite value of attribute using regex
by bart＠icm.edu.pl 24 Jun '13

24 Jun '13

--=_c864110a076fc513331e0370bcb9adbe Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=UTF-8; format=flowed I put patch here because the ftp server is full. DB --=_c864110a076fc513331e0370bcb9adbe Content-Transfer-Encoding: base64 Content-Type: text/plain; name=bart-130624.patch Content-Disposition: attachment; filename=bart-130624.patch RnJvbSBiOTM0MjdiZDVjYmNkMmJmOWMzYmM3M2IxYzE2NWYzNDY3MGRkOWY5IE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBiYXJ0IDxiYXJ0QG5iLWJhcnQuKG5vbmUpPgpEYXRlOiBNb24s IDI0IEp1biAyMDEzIDIzOjA2OjEwICswMjAwClN1YmplY3Q6IFtQQVRDSF0gT3ZlcmxheSB0byBy ZXdyaXRlIHZhbHVlIG9mIGF0dHJpYnV0ZSB1c2luZyByZWdleAoKLS0tCiBjb250cmliL3NsYXBk LW1vZHVsZXMvcmV3YXR0L01ha2VmaWxlIHwgICA0NiArKysrCiBjb250cmliL3NsYXBkLW1vZHVs ZXMvcmV3YXR0L3Jld2F0dC5jIHwgIDQ2NyArKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysKIDIgZmlsZXMgY2hhbmdlZCwgNTEzIGluc2VydGlvbnMoKyksIDAgZGVsZXRpb25zKC0pCiBj cmVhdGUgbW9kZSAxMDA2NDQgY29udHJpYi9zbGFwZC1tb2R1bGVzL3Jld2F0dC9NYWtlZmlsZQog Y3JlYXRlIG1vZGUgMTAwNjQ0IGNvbnRyaWIvc2xhcGQtbW9kdWxlcy9yZXdhdHQvcmV3YXR0LmMK CmRpZmYgLS1naXQgYS9jb250cmliL3NsYXBkLW1vZHVsZXMvcmV3YXR0L01ha2VmaWxlIGIvY29u dHJpYi9zbGFwZC1tb2R1bGVzL3Jld2F0dC9NYWtlZmlsZQpuZXcgZmlsZSBtb2RlIDEwMDY0NApp bmRleCAwMDAwMDAwLi5kNWQ5ZDEyCi0tLSAvZGV2L251bGwKKysrIGIvY29udHJpYi9zbGFwZC1t b2R1bGVzL3Jld2F0dC9NYWtlZmlsZQpAQCAtMCwwICsxLDQ2IEBACisjICRPcGVuTERBUCQKKwor TERBUF9TUkMgPSAuLi8uLi8uLgorTERBUF9CVUlMRCA9IC4uLy4uLy4uCitMREFQX0lOQyA9IC1J JChMREFQX0JVSUxEKS9pbmNsdWRlIC1JJChMREFQX1NSQykvaW5jbHVkZSAtSSQoTERBUF9TUkMp L3NlcnZlcnMvc2xhcGQKK0xEQVBfTElCID0gJChMREFQX0JVSUxEKS9saWJyYXJpZXMvbGlibGRh cF9yL2xpYmxkYXBfci5sYSBcCisJJChMREFQX0JVSUxEKS9saWJyYXJpZXMvbGlibGJlci9saWJs YmVyLmxhCisKK0xJQlRPT0wgPSAkKExEQVBfQlVJTEQpL2xpYnRvb2wKK0NDID0gZ2NjCitPUFQg PSAtZyAtTzIgLVdhbGwgLWdnZGIKK0RFRlMgPSAKK0lOQ1MgPSAkKExEQVBfSU5DKQorTElCUyA9 ICQoTERBUF9MSUIpCisKK1BST0dSQU1TID0gcmV3YXR0LmxhCitMVFZFUiA9IDA6MDowCisKK3By ZWZpeD0vdXNyL2xvY2FsCitleGVjX3ByZWZpeD0kKHByZWZpeCkKK2xkYXBfc3ViZGlyPS9vcGVu bGRhcAorCitsaWJkaXI9JChleGVjX3ByZWZpeCkvbGliCitsaWJleGVjZGlyPSQoZXhlY19wcmVm aXgpL2xpYmV4ZWMKK21vZHVsZWRpciA9ICQobGliZXhlY2RpcikkKGxkYXBfc3ViZGlyKQorCisu U1VGRklYRVM6IC5jIC5vIC5sbworCisuYy5sbzoKKwkkKExJQlRPT0wpIC0tbW9kZT1jb21waWxl ICQoQ0MpICQoT1BUKSAkKERFRlMpICQoSU5DUykgLWMgJDwKKworYWxsOiAkKFBST0dSQU1TKQor CityZXdhdHQubGE6IHJld2F0dC5sbworCSQoTElCVE9PTCkgLS1tb2RlPWxpbmsgJChDQykgJChP UFQpIC12ZXJzaW9uLWluZm8gJChMVFZFUikgXAorCS1ycGF0aCAkKG1vZHVsZWRpcikgLW1vZHVs ZSAtbyAkQCAkPyAkKExJQlMpCisKK2NsZWFuOgorCXJtIC1yZiAqLm8gKi5sbyAqLmxhIC5saWJz CisKK2luc3RhbGw6ICQoUFJPR1JBTVMpCisJbWtkaXIgLXAgJChERVNURElSKSQobW9kdWxlZGly KQorCWZvciBwIGluICQoUFJPR1JBTVMpIDsgZG8gXAorCQkkKExJQlRPT0wpIC0tbW9kZT1pbnN0 YWxsIGNwICQkcCAkKERFU1RESVIpJChtb2R1bGVkaXIpIDsgXAorCWRvbmUKKwpkaWZmIC0tZ2l0 IGEvY29udHJpYi9zbGFwZC1tb2R1bGVzL3Jld2F0dC9yZXdhdHQuYyBiL2NvbnRyaWIvc2xhcGQt bW9kdWxlcy9yZXdhdHQvcmV3YXR0LmMKbmV3IGZpbGUgbW9kZSAxMDA2NDQKaW5kZXggMDAwMDAw MC4uNjgzYmVjYwotLS0gL2Rldi9udWxsCisrKyBiL2NvbnRyaWIvc2xhcGQtbW9kdWxlcy9yZXdh dHQvcmV3YXR0LmMKQEAgLTAsMCArMSw0NjcgQEAKKy8qIHJld2F0dC5jIC0gT3ZlcmxheSB0byBy ZXdyaXRlIHNvbWUgYXR0cmlidXRlICAqLworLyogUmVkaXN0cmlidXRpb24gYW5kIHVzZSBpbiBz b3VyY2UgYW5kIGJpbmFyeSBmb3Jtcywgd2l0aCBvciB3aXRob3V0CisgKiBtb2RpZmljYXRpb24s IGFyZSBwZXJtaXR0ZWQgb25seSBhcyBhdXRob3JpemVkIGJ5IHRoZSBPcGVuTERBUAorICogUHVi bGljIExpY2Vuc2UuCisgKgorICogQSBjb3B5IG9mIHRoaXMgbGljZW5zZSBpcyBhdmFpbGFibGUg aW4gdGhlIGZpbGUgTElDRU5TRSBpbiB0aGUKKyAqIHRvcC1sZXZlbCBkaXJlY3Rvcnkgb2YgdGhl IGRpc3RyaWJ1dGlvbiBvciwgYWx0ZXJuYXRpdmVseSwgYXQKKyAqIDxodHRwOi8vd3d3Lk9wZW5M REFQLm9yZy9saWNlbnNlLmh0bWw+LgorICovCisvKiBBQ0tOT1dMRURHRU1FTlRTOgorICogVGhp cyB3b3JrIHdhcyBvcmlnaW5hbGx5IGRldmVsb3BlZCBieSB0aGUgRG9taW5payBCYXJ0a2lld2lj eiBiYXJ0QGljbS5lZHUucGwgZm9yCisgKiBpbmNsdXNpb24gaW4gT3BlbkxEQVAgU29mdHdhcmUu CisgKi8KKworI2luY2x1ZGUgInBvcnRhYmxlLmgiCisKKyNpbmNsdWRlIDxzdGRpby5oPgorI2lu Y2x1ZGUgPHJlZ2V4Lmg+CisKKyNpbmNsdWRlICJhYy9zdHJpbmcuaCIKKyNpbmNsdWRlICJhYy9z b2NrZXQuaCIKKworI2luY2x1ZGUgImx1dGlsLmgiCisjaW5jbHVkZSAic2xhcC5oIgorI2luY2x1 ZGUgImNvbmZpZy5oIgorCisjZGVmaW5lIE1BWF9NQVRDSEVTIDEKKworZW51bSB7CisJUkVXQVRU X0FUVFJJQlVURT0xLAorCVJFV0FUVF9SRUdFWCwKKwlSRVdBVFRfU1VCLAorCVJFV0FUVF9BVFRS SUJVVEVfVCwKKwlSRVdBVFRfUkVHRVhfVAorfTsKKworCit0eXBlZGVmIHN0cnVjdCByZXdhdHRf aW5mb190IHsKKwlBdHRyaWJ1dGVEZXNjcmlwdGlvbgkqcmFfYXR0cmlidXRlOworCXJlZ2V4X3QJ CQkqcmFfcmVnZXg7CisJY2hhcgkJKnJhX3N1YjsKKwlBdHRyaWJ1dGVEZXNjcmlwdGlvbgkqcmFf YXR0cmlidXRlX3Q7CisJcmVnZXhfdAkJCSpyYV9yZWdleF90OworCXN0cnVjdCByZXdhdHRfaW5m b190CSpyYV9uZXh0OworfSByZXdhdHRfaW5mb190OworCitzdGF0aWMgaW50CityZXdhdHRfY2Zn ZW4oIENvbmZpZ0FyZ3MgKmMgKQoreworCXNsYXBfb3Zlcmluc3QJKm9uID0gKHNsYXBfb3Zlcmlu c3QgKiljLT5iaTsKKwlyZXdhdHRfaW5mb190CSpjaSA9IChyZXdhdHRfaW5mb190ICopb24tPm9u X2JpLmJpX3ByaXZhdGUgOworCisgICAgICAgIGlmKCBjaSA9PSBOVUxMICkgeworICAgICAgICAg ICAgICAgIGNpID0gKHJld2F0dF9pbmZvX3QqKWNoX2NhbGxvYyggMSwgc2l6ZW9mKHJld2F0dF9p bmZvX3QpICk7CisJCWNpIC0+IHJhX3JlZ2V4ID0gTlVMTDsKKwkJY2kgLT4gcmFfcmVnZXggPSBO VUxMOworCQljaSAtPiByYV9zdWIgPSBOVUxMOworCQljaSAtPiByYV9hdHRyaWJ1dGUgPSBOVUxM OworCQljaSAtPiByYV9hdHRyaWJ1dGVfdCA9IE5VTEw7CisJCWNpIC0+IHJhX25leHQgPSBOVUxM OworCQlvbi0+b25fYmkuYmlfcHJpdmF0ZT0gKHZvaWQgKikgY2k7CisJCURlYnVnKCBMREFQX0RF QlVHX1RSQUNFLCAicmV3YXR0X2NmZ2VuOiAgIG9uLT5vbl9iaS5iaV9wcml2YXRlPSAlcCBcbiIs IG9uLT5vbl9iaS5iaV9wcml2YXRlLCAwLCAwKTsKKyAgICAgICAgfSBlbHNlIHsKKwkJZm9yICg7 Y2k7Y2k9Y2ktPnJhX25leHQpIHsKKyAgICAgICAgCQlpZiggY2ktPnJhX25leHQgPT0gTlVMTCAp IHsKKwkJCQlpZihjaS0+cmFfYXR0cmlidXRlICE9IE5VTEwgJiYgYy0+dHlwZSA9PSBSRVdBVFRf QVRUUklCVVRFICYmICBjLT5vcCAhPSBTTEFQX0NPTkZJR19FTUlUICYmIGMtPm9wICE9ICBMREFQ X01PRF9ERUxFVEUpeworICAgICAgICAgICAgICAgIAkJCWNpLT5yYV9uZXh0ID0gKHJld2F0dF9p bmZvX3QqKWNoX2NhbGxvYyggMSwgc2l6ZW9mKHJld2F0dF9pbmZvX3QpICk7CisJCQkJCWNpLT5y YV9uZXh0IC0+IHJhX3JlZ2V4ID0gTlVMTDsKKwkJCQkJY2ktPnJhX25leHQgLT4gcmFfcmVnZXhf dCA9IE5VTEw7CisJCQkJCWNpLT5yYV9uZXh0IC0+IHJhX3N1YiA9IE5VTEw7CisJCQkJCWNpLT5y YV9uZXh0IC0+IHJhX2F0dHJpYnV0ZSA9IE5VTEw7CisJCQkJCWNpLT5yYV9uZXh0IC0+IHJhX2F0 dHJpYnV0ZV90ID0gTlVMTDsKKwkJCQkJY2ktPnJhX25leHQgLT4gcmFfbmV4dCA9IE5VTEw7CisJ CQkJCURlYnVnKCBMREFQX0RFQlVHX1RSQUNFLCAicmV3YXR0X2NmZ2VuOiAgIG9uLT5vbl9iaS5i aV9wcml2YXRlPSAlcCBcbiIsIG9uLT5vbl9iaS5iaV9wcml2YXRlLCAwLCAwKTsKKwkJCQl9IGVs c2UgeworCQkJCQlicmVhazsKKwkJCQl9CisgICAgICAgIAkJfQorCQkJCisJCX0KKworCX0KKwor CWNvbnN0IGNoYXIJCSp0ZXh0OworCWludCByYyA9IDE7CisJaW50IHIgPSAxOworCWludCBpID0g MDsKKwlpbnQgbGVuID0gMDsKKwlmb3IoaT0wO2k8Yy0+YXJnYztpKyspeworCQlEZWJ1ZyggTERB UF9ERUJVR19UUkFDRSwgInJld2F0dF9jZmdlbjogICBjLT5hcmd2WyVkXTogJXNcbiIsIGksIGMt PmFyZ3ZbaV0sIDApOworCX0KKwlEZWJ1ZyggTERBUF9ERUJVR19UUkFDRSwgInJld2F0dF9jZmdl bjogICBjLT5vcDogJWRcbiIsICBjLT5vcCwgMCwwKTsKKwlpZiAoIGMtPm9wID09IFNMQVBfQ09O RklHX0VNSVQgKSB7CisJCWNpID0gb24tPm9uX2JpLmJpX3ByaXZhdGUgOworCQlzdHJ1Y3QgYmVy dmFsCWJ2OworCQlEZWJ1ZyggTERBUF9ERUJVR19UUkFDRSwgInJld2F0dF9jZmdlbiBTTEFQX0NP TkZJR19FTUlUIDogICBjLT50eXBlOiAlZFxuIiwgIGMtPnR5cGUsIDAsMCk7CisJCXN3aXRjaChj LT50eXBlKSB7CisJCWNhc2UgUkVXQVRUX0FUVFJJQlVURToKKwkJCWxlbiA9IHNucHJpbnRmKCBj LT5jcl9tc2csIHNpemVvZiggYy0+Y3JfbXNnICksCisJCQkJICIlcyIsIAorCQkJCWNpLT5yYV9h dHRyaWJ1dGUtPmFkX2NuYW1lLmJ2X3ZhbCApOworCisJCQlidi5idl92YWwgPSBjLT5jcl9tc2c7 CisJCQlEZWJ1ZyggTERBUF9ERUJVR19UUkFDRSwgInJld2F0dF9jZmdlbiBSRVdBVFRfQVRUUklC VVRFOiAgIGMtPmNyX21zZzogJXNcbiIsICBjLT5jcl9tc2csIDAsMCk7CisJCQlidi5idl9sZW4g PSBsZW47CisJCQl2YWx1ZV9hZGRfb25lICggJmMtPnJ2YWx1ZV92YWxzLCAmYnYgKTsKKwkJCXJj ID0gMDsKKwkJCWJyZWFrOworCQljYXNlIFJFV0FUVF9SRUdFWDoKKworCQkJLy9sZW4gPSBzbnBy aW50ZiggYy0+Y3JfbXNnLCBzaXplb2YoIGMtPmNyX21zZyApLCAiJXMiLCBjaS0+cmFfcmVnZXhw ICk7CisJCQkvL2J2LmJ2X3ZhbCA9IGMtPmNyX21zZzsKKwkJCS8vRGVidWcoIExEQVBfREVCVUdf VFJBQ0UsICJyZXdhdHRfY2ZnZW4gUkVXQVRUX1JFR0VYUDogICBjLT5jcl9tc2c6ICVzXG4iLCAg Yy0+Y3JfbXNnLCAwLDApOworCQkJLy9idi5idl9sZW4gPSBsZW47CisJCQkvL3ZhbHVlX2FkZF9v bmUgKCAmYy0+cnZhbHVlX3ZhbHMsICZidiApOworCQkJcmMgPSAwOworCQkJYnJlYWs7CisJCWNh c2UgUkVXQVRUX1NVQjoKKwkJCWlmICggY2ktPnJhX3N1YiApeworCQkJCWxlbiA9IHNucHJpbnRm KCBjLT5jcl9tc2csIHNpemVvZiggYy0+Y3JfbXNnICksCisJCQkJCSIlcyIsCisJCQkJCWNpLT5y YV9zdWIgKTsKKworCQkJCWJ2LmJ2X3ZhbCA9IGMtPmNyX21zZzsKKwkJCQlEZWJ1ZyggTERBUF9E RUJVR19UUkFDRSwgInJld2F0dF9jZmdlbiBSRVdBVFRfU1VCOiAgIGMtPmNyX21zZzogJXNcbiIs ICBjLT5jcl9tc2csIDAsMCk7CisJCQkJYnYuYnZfbGVuID0gbGVuOworCQkJCXZhbHVlX2FkZF9v bmUgKCAmYy0+cnZhbHVlX3ZhbHMsICZidiApOworCQkJfQorCQkJcmMgPSAwOworCQkJYnJlYWs7 CisJCWNhc2UgUkVXQVRUX0FUVFJJQlVURV9UOgorCQkJaWYoY2ktPnJhX2F0dHJpYnV0ZV90KXsK KwkJCQlsZW4gPSBzbnByaW50ZiggYy0+Y3JfbXNnLCBzaXplb2YoIGMtPmNyX21zZyApLAorCQkJ CQkgIiVzIiwgCisJCQkJCWNpLT5yYV9hdHRyaWJ1dGVfdC0+YWRfY25hbWUuYnZfdmFsICk7CisJ CQkJYnYuYnZfdmFsID0gYy0+Y3JfbXNnOworCQkJCURlYnVnKCBMREFQX0RFQlVHX1RSQUNFLCAi cmV3YXR0X2NmZ2VuIFJFV0FUVF9BVFRSSUJVVEU6ICAgYy0+Y3JfbXNnOiAlc1xuIiwgIGMtPmNy X21zZywgMCwwKTsKKwkJCQlidi5idl9sZW4gPSBsZW47CisJCQkJdmFsdWVfYWRkX29uZSAoICZj LT5ydmFsdWVfdmFscywgJmJ2ICk7CisJCQl9CisJCQlyYyA9IDA7CisJCQlicmVhazsKKwkJY2Fz ZSBSRVdBVFRfUkVHRVhfVDoKKwkJCXJjID0gMDsKKwkJCWJyZWFrOworCisJCWRlZmF1bHQ6CisJ CQlyYyA9IDE7CisJCQlicmVhazsKKwkJfQorCQlyZXR1cm4gcmM7CisJfSBlbHNlIGlmICggYy0+ b3AgPT0gTERBUF9NT0RfREVMRVRFICkgeworCSAgICAgICAgLyogRklYTUUgKi8KKwkgICAgICAg IHJldHVybiAxOworCX0KKwlEZWJ1ZyggTERBUF9ERUJVR19UUkFDRSwgInJld2F0dF9jZmdlbjog ICBjLT50eXBlOiAlZFxuIiwgIGMtPnR5cGUsIDAsMCk7CisJc3dpdGNoKCBjLT50eXBlICkgewor CWNhc2UgUkVXQVRUX0FUVFJJQlVURToKKwkJaWYgKCBjLT5hcmdjID09IDIgKXsKKwkJCXIgPSBz bGFwX3N0cjJhZCggYy0+YXJndlsxXSwgJihjaS0+cmFfYXR0cmlidXRlKSwgJnRleHQgKTsKKwkJ CWlmICggciAhPSBMREFQX1NVQ0NFU1MgKSB7CisJCQkJRGVidWcoIExEQVBfREVCVUdfVFJBQ0Us ICJyZXdhdHRfY2ZnZW46ICBzbGFwX3N0cjJhZDogcmV0dXJuIGNvZGUgPSAlZFxuIiwgciwgMCww KTsKKwkJCQlyYyA9IDE7CisJCQl9IGVsc2UgeworCQkJCURlYnVnKCBMREFQX0RFQlVHX1RSQUNF LCAicmV3YXR0X2NmZ2VuOiAgIGNpLT5yYV9hdHRyaWJ1dGUtPmFkX2NuYW1lLmJ2X3ZhbCA9ICVz XG4iLCAgY2ktPnJhX2F0dHJpYnV0ZS0+YWRfY25hbWUuYnZfdmFsICwgMCwwKTsKKwkJCQlyYyA9 IDA7CisJCQl9CisJCX0KKwkJYnJlYWs7CisJY2FzZSBSRVdBVFRfUkVHRVg6CisJCWlmICggYy0+ YXJnYyA9PSAyICl7CisJCQljaS0+cmFfcmVnZXg9KHJlZ2V4X3QgKilTTEFQX01BTExPQyhzaXpl b2YocmVnZXhfdCkpOworCQkJciA9IHJlZ2NvbXAoY2ktPnJhX3JlZ2V4LCBjLT5hcmd2WzFdLCBS RUdfRVhURU5ERUQpOworCQkJaWYoIHIgKXsKKwkJCQlEZWJ1ZyggTERBUF9ERUJVR19UUkFDRSwg InJld2F0dF9jZmdlbjogQ291bGQgbm90IGNvbXBpbGUgcmVnZXggciA9ICVkXG4iLCByICwgMCww KTsKKwkJCQlyZWdmcmVlKGNpLT5yYV9yZWdleCk7CisJCQkJY2ktPnJhX3JlZ2V4PU5VTEw7CisJ CQkJcmMgPSAxOworCQkJfSBlbHNlIHsKKwkJCQlEZWJ1ZyggTERBUF9ERUJVR19UUkFDRSwgInJl d2F0dF9jZmdlbjogICBjaS0+cmFfcmVnZXggbWFrZSBmcm9tICM+ICVzIDwjJ1xuIiwgIGMtPmFy Z3ZbMV0gLCAwLDApOworCQkJCXJjID0gMDsKKwkJCX0KKwkJfQorCQlicmVhazsKKwljYXNlIFJF V0FUVF9TVUI6CisJCWlmICggYy0+YXJnYyA9PSAyICl7CisJCQljaS0+cmFfc3ViPVNMQVBfTUFM TE9DKChzdHJsZW4oYy0+YXJndlsxXSkrMSkqIHNpemVvZihjaGFyKSApOworCQkJRGVidWcoIExE QVBfREVCVUdfVFJBQ0UsICJyZXdhdHRfY2ZnZW46ICAgY2ktPnJhX3N1Yj1tYWxsb2MoJWx1KVxu IiwgICgoc3RybGVuKGMtPmFyZ3ZbMV0pKzEpKiBzaXplb2YoY2hhcikgKSwgMCwwKTsKKwkJCXN0 cm5jcHkoY2ktPnJhX3N1YixjLT5hcmd2WzFdLHN0cmxlbihjLT5hcmd2WzFdKSk7CisJCQljaS0+ cmFfc3ViW3N0cmxlbihjLT5hcmd2WzFdKV09J1wwJzsKKwkJCURlYnVnKCBMREFQX0RFQlVHX1RS QUNFLCAicmV3YXR0X2NmZ2VuOiAgIGNpLT5yYV9zdWI9ICVzXG4iLCAgY2ktPnJhX3N1YiwgMCww KTsKKwkJCXJjID0gMDsKKwkJfSBlbHNlIHsKKwkJCWNpLT5yYV9zdWI9bWFsbG9jKHNpemVvZihj aGFyKSk7CisJCQljaS0+cmFfc3ViWzBdPSdcMCc7CisJCQlyYyA9IDA7CisJCX0KKwkJYnJlYWs7 CisJY2FzZSBSRVdBVFRfQVRUUklCVVRFX1Q6CisJCWlmICggYy0+YXJnYyA9PSAyICl7CisJCQly ID0gc2xhcF9zdHIyYWQoIGMtPmFyZ3ZbMV0sICYoY2ktPnJhX2F0dHJpYnV0ZV90KSwgJnRleHQg KTsKKwkJCWlmICggciAhPSBMREFQX1NVQ0NFU1MgKSB7CisJCQkJRGVidWcoIExEQVBfREVCVUdf VFJBQ0UsICJyZXdhdHRfY2ZnZW46ICBzbGFwX3N0cjJhZDogcmV0dXJuIGNvZGUgPSAlZFxuIiwg ciwgMCwwKTsKKwkJCQlyYyA9IDE7CisJCQl9IGVsc2UgeworCQkJCURlYnVnKCBMREFQX0RFQlVH X1RSQUNFLCAicmV3YXR0X2NmZ2VuOiAgIGNpLT5yYV9hdHRyaWJ1dGVfdC0+YWRfY25hbWUuYnZf dmFsID0gJXNcbiIsICBjaS0+cmFfYXR0cmlidXRlX3QtPmFkX2NuYW1lLmJ2X3ZhbCAsIDAsMCk7 CisJCQkJcmMgPSAwOworCQkJfQorCQl9CisJCWJyZWFrOworCWNhc2UgUkVXQVRUX1JFR0VYX1Q6 CisJCWlmICggYy0+YXJnYyA9PSAyICl7CisJCQljaS0+cmFfcmVnZXhfdD0ocmVnZXhfdCAqKVNM QVBfTUFMTE9DKHNpemVvZihyZWdleF90KSk7CisJCQlyID0gcmVnY29tcChjaS0+cmFfcmVnZXhf dCwgYy0+YXJndlsxXSwgUkVHX0VYVEVOREVEKTsKKwkJCWlmKCByICl7CisJCQkJRGVidWcoIExE QVBfREVCVUdfVFJBQ0UsICJyZXdhdHRfY2ZnZW46IENvdWxkIG5vdCBjb21waWxlIHJlZ2V4IHIg PSAlZFxuIiwgciAsIDAsMCk7CisJCQkJcmVnZnJlZShjaS0+cmFfcmVnZXhfdCk7CisJCQkJY2kt PnJhX3JlZ2V4X3Q9TlVMTDsKKwkJCQlyYyA9IDE7CisJCQl9IGVsc2UgeworCQkJCURlYnVnKCBM REFQX0RFQlVHX1RSQUNFLCAicmV3YXR0X2NmZ2VuOiAgIGNpLT5yYV9yZWdleF90IG1ha2UgZnJv bSAjPiAlcyA8IydcbiIsICBjLT5hcmd2WzFdICwgMCwwKTsKKwkJCQlyYyA9IDA7CisJCQl9CisJ CX0KKwkJYnJlYWs7CisKKworCWRlZmF1bHQ6CQkKKwkJcmV0dXJuIDE7CisJCWJyZWFrOworCX0K KwlyZXR1cm4gcmM7Cit9CitzdGF0aWMgaW50CityZXdhdHRfc2VhcmNoX3Jlc3BvbnNlX2NiKCBP cGVyYXRpb24gKm9wLCBTbGFwUmVwbHkgKnJzICkKK3sKKwlzbGFwX2NhbGxiYWNrICAgKnNjOwor CXJld2F0dF9pbmZvX3QJKnJhaTsKKwlFbnRyeQkJKmUgPSBOVUxMOworCUF0dHJpYnV0ZSAqYTsK KwljaGFyIG1zZ2J1ZlsxMDBdOworCWludCByZXRpOworCWludCBpOworCisJYXNzZXJ0KCBvcCAm JiBvcC0+b19jYWxsYmFjayAmJiBycyApOworCURlYnVnKCBMREFQX0RFQlVHX1RSQUNFLCAicmV3 YXR0X3NlYXJjaF9yZXNwb25zZV9jYiBcbiIsIDAsIDAsMCk7CisJaWYgKCBycy0+c3JfdHlwZSAh PSBSRVBfU0VBUkNIIHx8ICFycy0+c3JfZW50cnkgKSB7CisJCXNsYXBfZnJlZXNlbGZfY2IoIG9w LCBycyApOworCQlyZXR1cm4gKCBTTEFQX0NCX0NPTlRJTlVFICk7CisJfQorCXNjID0gb3AtPm9f Y2FsbGJhY2s7CisJcmFpID0gKHJld2F0dF9pbmZvX3QgKilzYy0+c2NfcHJpdmF0ZTsKKworCWZv ciAocmFpID0gKHJld2F0dF9pbmZvX3QgKilzYy0+c2NfcHJpdmF0ZTtyYWk7cmFpPXJhaS0+cmFf bmV4dCl7CisJCS8vRGVidWcoIExEQVBfREVCVUdfVFJBQ0UsICJyZXdhdHRfc2VhcmNoX3Jlc3Bv bnNlX2NiOiByYWkgPSAlcCBcbiIsIHJhaSwgMCwgMCk7CisJCWUgPSBycy0+c3JfZW50cnk7CisJ CWZvciAoIGEgPSBlLT5lX2F0dHJzOyBhOyBhID0gYS0+YV9uZXh0ICkgeworCQkJaWYgKCBhLT5h X2Rlc2MgPT0gcmFpLT5yYV9hdHRyaWJ1dGUgKSB7CisJCQkJRGVidWcoIExEQVBfREVCVUdfVFJB Q0UsICJyZXdhdHRfc2VhcmNoX3Jlc3BvbnNlX2NiOiByZXdhdHQgZmluZDogJXNcbiIsIGEtPmFf ZGVzYy0+YWRfY25hbWUuYnZfdmFsLCAwLDApOworCQkJCWJyZWFrOworCQkJCX0KKwkJfQorCisJ CWlmICggYSA9PSBOVUxMICkgeworCQkJRGVidWcoIExEQVBfREVCVUdfVFJBQ0UsICJyZXdhdHRf c2VhcmNoX3Jlc3BvbnNlX2NiOiByZXdhdHQgbm90IGZpbmQ6ICVzXG4iLCByYWktPnJhX2F0dHJp YnV0ZS0+YWRfY25hbWUuYnZfdmFsLCAwLDApOworCQkJY29udGludWU7CisJCX0KKworCQlEZWJ1 ZyggTERBUF9ERUJVR19UUkFDRSwgInJld2F0dF9zZWFyY2hfcmVzcG9uc2VfY2I6IGEtPmFfZGVz Yy0+YWRfY25hbWUuYnZfdmFsOiAlc1xuIiwgYS0+YV9kZXNjLT5hZF9jbmFtZS5idl92YWwsIDAs MCk7CisKKwkJaWYgKCByYWktPnJhX2F0dHJpYnV0ZV90ICE9IE5VTEwgKXsKKwkJCWZvciAoIGEg PSBlLT5lX2F0dHJzOyBhOyBhID0gYS0+YV9uZXh0ICkgeworCQkJCWlmICggYS0+YV9kZXNjID09 IHJhaS0+cmFfYXR0cmlidXRlX3QgKSB7CisJCQkJCWJyZWFrOworCQkJCQl9CisJCQl9CisJCisJ CQlpZiAoIGEgPT0gTlVMTCApIHsKKwkJCQlEZWJ1ZyggTERBUF9ERUJVR19UUkFDRSwgInJld2F0 dF9zZWFyY2hfcmVzcG9uc2VfY2I6IHJld2F0dCBub3QgZmluZCByYV9hdHRyaWJ1dGVfdCA6ICVz XG4iLCByYWktPnJhX2F0dHJpYnV0ZV90LT5hZF9jbmFtZS5idl92YWwsIDAsMCk7CisJCQkJY29u dGludWU7CisJCQl9CisJCX0KKwkJaWYgKCByYWktPnJhX2F0dHJpYnV0ZV90ICE9IE5VTEwgJiYg cmFpLT5yYV9yZWdleF90ICE9IE5VTEwpeworCQkJZm9yICggYSA9IGUtPmVfYXR0cnM7IGE7IGEg PSBhLT5hX25leHQgKSB7CisJCQkJaWYgKCBhLT5hX2Rlc2MgPT0gcmFpLT5yYV9hdHRyaWJ1dGVf dCApIHsKKwkJCQkJCWZvcihpPTA7aSA8IGEtPmFfbnVtdmFscyA7aSsrKXsKKwkJCQkJCQkgcmV0 aSA9IHJlZ2V4ZWMocmFpLT5yYV9yZWdleF90LCBhLT5hX3ZhbHNbaV0uYnZfdmFsICwgMCAsIE5V TEwgLCBSRUdfTk9UQk9MIHwgUkVHX05PVEVPTCk7CisJCQkJCQkJIGlmIChyZXRpID09IDApIGJy ZWFrOworCQkJCQkJfQorCQkJCQkJaWYgKHJldGkgPT0gMCApIGJyZWFrOworCQkJCQl9CisJCQl9 CisJCisJCQlpZiAoIGEgPT0gTlVMTCApIHsKKwkJCQlEZWJ1ZyggTERBUF9ERUJVR19UUkFDRSwg InJld2F0dF9zZWFyY2hfcmVzcG9uc2VfY2I6IHJhX3JlZ2V4X3QgUkVHX05PTUFUQ0ggaW4gJXMg XG4iLCAgcmFpLT5yYV9hdHRyaWJ1dGVfdC0+YWRfY25hbWUuYnZfdmFsICwgMCwwKTsKKwkJCQlj b250aW51ZTsKKwkJCX0KKworCQl9CisKKwkJLy9OZXcgZnVuY3Rpb24gZm9yIHNsYXBkID4gMi40 LjI0CisJCXJzX2VudHJ5Mm1vZGlmaWFibGUoIG9wLCBycywgKHNsYXBfb3Zlcmluc3QgKikgb3At Pm9fYmQtPmJkX2luZm8gKTsKKwkJLy9yc19lbnN1cmVfZW50cnlfbW9kaWZpYWJsZSggb3AsIHJz LCAoc2xhcF9vdmVyaW5zdCAqKSBvcC0+b19iZC0+YmRfaW5mbyApOworCQllID0gcnMtPnNyX2Vu dHJ5OworCisJCWZvciAoIGEgPSBlLT5lX2F0dHJzOyBhOyBhID0gYS0+YV9uZXh0ICkgeworCQkJ aWYgKCBhLT5hX2Rlc2MgIT0gIHJhaS0+cmFfYXR0cmlidXRlICkKKwkJCQljb250aW51ZTsKKwkJ CWZvcihpPTA7aSA8IGEtPmFfbnVtdmFscyA7aSsrKXsKKworCisJCQkJRGVidWcoIExEQVBfREVC VUdfVFJBQ0UsICJyZXdhdHRfc2VhcmNoX3Jlc3BvbnNlX2NiOiBvbGQgIHZhbHVlICAlc1xuIiwg YS0+YV92YWxzW2ldLmJ2X3ZhbCwgMCwwICk7CisJCQkJRGVidWcoIExEQVBfREVCVUdfVFJBQ0Us ICJyZXdhdHRfc2VhcmNoX3Jlc3BvbnNlX2NiOiBvbGQgbnZhbHVlICAlc1xuIiwgYS0+YV9udmFs c1tpXS5idl92YWwsIDAsMCApOworCisJCQkJaW50IGo7CisJCQkJY2hhciAqIHZhbF90bXA9TlVM TDsKKwkJCQlyZWdtYXRjaF90IG1hdGNoZXNbTUFYX01BVENIRVNdOworCQkJCQorCQkJCS8qIEV4 ZWN1dGUgcmVndWxhciBleHByZXNzaW9uICovCisJCQkJcmV0aSA9IHJlZ2V4ZWMocmFpLT5yYV9y ZWdleCwgYS0+YV92YWxzW2ldLmJ2X3ZhbCAsIE1BWF9NQVRDSEVTICwgbWF0Y2hlcyAsIFJFR19O T1RCT0wgfCBSRUdfTk9URU9MKTsKKworCQkJCWlmKCAhcmV0aSApeworCQkJCQlmb3IgKGogPSAw OyBqIDwgIE1BWF9NQVRDSEVTOyBqKyspIHsKKwkJCQkJCWlmIChtYXRjaGVzW2pdLnJtX3NvID09 IC0xKSB7CisJCQkJCQkgICAgYnJlYWs7CisJCQkJCQl9CisJCQkJCQlpZiAoaiA9PSAwICkgewor CQkJCQkJCXZhbF90bXAgPSByZWFsbG9jKHZhbF90bXAgLCAoc3RybGVuKHJhaS0+cmFfc3ViKSAt IG1hdGNoZXNbal0ucm1fZW8gKyBtYXRjaGVzW2pdLnJtX3NvICsxICsgc3RybGVuKGEtPmFfdmFs c1tpXS5idl92YWwpICkgKiBzaXplb2YoY2hhcikpOworCQkJCQkJCWlmKG1hdGNoZXNbal0ucm1f c28gPiAwKQorCQkJCQkJCQlzdHJuY3B5KCB2YWxfdG1wLCAgYS0+YV92YWxzW2ldLmJ2X3ZhbCwg bWF0Y2hlc1tqXS5ybV9zbyk7CisJCQkJCQkJc3RyY3B5KCB2YWxfdG1wICsgbWF0Y2hlc1tqXS5y bV9zbywgIHJhaS0+cmFfc3ViKTsKKwkJCQkJCQlzdHJjcHkoIHZhbF90bXAgKyBzdHJsZW4odmFs X3RtcCkgLCBhLT5hX3ZhbHNbaV0uYnZfdmFsICsgbWF0Y2hlc1tqXS5ybV9lbyApOworCQkJCQkJ fQorCQkJCQl9CisJCQkJCURlYnVnKCBMREFQX0RFQlVHX1RSQUNFLCAicmV3YXR0X3NlYXJjaF9y ZXNwb25zZV9jYjogdmFsX3RtcCB2YWx1ZTogJXNcbiIsIHZhbF90bXAsIDAsIDAgKTsKKwkJCQkJ YS0+YV92YWxzW2ldLmJ2X3ZhbCA9IHJlYWxsb2MoIGEtPmFfdmFsc1tpXS5idl92YWwgLCAoIHN0 cmxlbih2YWxfdG1wKSArIDEgKSAqIHNpemVvZihjaGFyKSAgKTsKKwkJCQkJYS0+YV9udmFsc1tp XS5idl92YWwgPSByZWFsbG9jKCBhLT5hX252YWxzW2ldLmJ2X3ZhbCAsICggc3RybGVuKHZhbF90 bXApICsgMSApICAqIHNpemVvZihjaGFyKSAgKTsKKwkJCQkJRGVidWcoIExEQVBfREVCVUdfVFJB Q0UsICJyZXdhdHRfc2VhcmNoX3Jlc3BvbnNlX2NiOiBhZnRlciBTTEFQX1JFQUxMT0MgYS0+YV9b bl12YWxzWyVkXS0+YnZfdmFsIHRvICAlbHVcbiIsIGkgLChzdHJsZW4odmFsX3RtcCkrMSkqc2l6 ZW9mKGNoYXIpLCAwICk7CisJCQkJCXN0cmNweSggYS0+YV92YWxzW2ldLmJ2X3ZhbCAsdmFsX3Rt cCk7CisJCQkJCXN0cmNweSggYS0+YV9udmFsc1tpXS5idl92YWwgLHZhbF90bXApOworCQkJCQlE ZWJ1ZyggTERBUF9ERUJVR19UUkFDRSwgInJld2F0dF9zZWFyY2hfcmVzcG9uc2VfY2I6IG5ldyBh LT5hX1tuXXZhbHNbJWRdLmJ2X3ZhbD0gJXNcbiIsaSwgYS0+YV9udmFsc1tpXS5idl92YWwsIDAg KTsKKwkJCQkJYS0+YV92YWxzW2ldLmJ2X2xlbj0gc3RybGVuKHZhbF90bXApIDsKKwkJCQkJYS0+ YV9udmFsc1tpXS5idl9sZW49IHN0cmxlbih2YWxfdG1wKSA7CisJCQkJCURlYnVnKCBMREFQX0RF QlVHX1RSQUNFLCAicmV3YXR0X3NlYXJjaF9yZXNwb25zZV9jYjogbmV3IGEtPmFfW25ddmFsc1sl ZF0uYnZfbGVuPSAlenVcbiIsaSwgc3RybGVuKHZhbF90bXApLCAwICk7CisJCQkJCWlmICh2YWxf dG1wKSBmcmVlKHZhbF90bXApOworCQkJCX0KKwkJCQllbHNlIGlmKCByZXRpID09IFJFR19OT01B VENIICl7CisJCQkJCURlYnVnKCBMREFQX0RFQlVHX1RSQUNFLCAicmV3YXR0X3NlYXJjaF9yZXNw b25zZV9jYjogUkVHX05PTUFUQ0ggaW4gOiAlc1xuIiwgIGEtPmFfdmFsc1tpXS5idl92YWwgICwg MCwwKTsKKwkJCQl9CisJCQkJZWxzZXsKKwkJCQkgICAgICAgIHJlZ2Vycm9yKHJldGksIHJhaS0+ cmFfcmVnZXgsIG1zZ2J1Ziwgc2l6ZW9mKG1zZ2J1ZikpOworCQkJCQlEZWJ1ZyggTERBUF9ERUJV R19UUkFDRSwgInJld2F0dF9zZWFyY2hfcmVzcG9uc2VfY2I6IFJlZ2V4IG1hdGNoIGZhaWxlZDog JXNcbiIsICBtc2didWYgLCAwLDApOworCQkJCQlicmVhazsKKwkJCQl9CisJCQl9CisKKyAgICAg ICAgCX0KKwl9CisJcmV0dXJuICggU0xBUF9DQl9DT05USU5VRSApOworfQorCitzdGF0aWMgaW50 CityZXdhdHRfc2VhcmNoX2NsZWFudXBfY2IoIE9wZXJhdGlvbiAqb3AsIFNsYXBSZXBseSAqcnMg KQoreworCWlmICggcnMtPnNyX3R5cGUgPT0gUkVQX1JFU1VMVCB8fCBycy0+c3JfZXJyICE9IExE QVBfU1VDQ0VTUyApIHsKKwkJc2xhcF9mcmVlc2VsZl9jYiggb3AsIHJzICk7CisJfQorCisJcmV0 dXJuIFNMQVBfQ0JfQ09OVElOVUU7Cit9CisKK3N0YXRpYyBpbnQKK3Jld2F0dF9zZWFyY2goIE9w ZXJhdGlvbiAqb3AsIFNsYXBSZXBseSAqcnMgKQoreworICAgICAgICBzbGFwX292ZXJpbnN0ICAg Km9uID0gKHNsYXBfb3Zlcmluc3QgKilvcC0+b19iZC0+YmRfaW5mbzsKKyAgICAgICAgcmV3YXR0 X2luZm9fdCAgICAqY2kgPSAocmV3YXR0X2luZm9fdCAqKW9uLT5vbl9iaS5iaV9wcml2YXRlOwor CXNsYXBfY2FsbGJhY2sJKnNjOworCisJRGVidWcoIExEQVBfREVCVUdfVFJBQ0UsICJyZXdhdHRf c2VhcmNoIFxuIiwgMCwgMCwgMCApOworCXNjID0gb3AtPm9fdG1wY2FsbG9jKCAxLCBzaXplb2Yo ICpzYyApLCBvcC0+b190bXBtZW1jdHggKTsKKwlzYy0+c2NfcmVzcG9uc2UgPSByZXdhdHRfc2Vh cmNoX3Jlc3BvbnNlX2NiOworCXNjLT5zY19jbGVhbnVwID0gcmV3YXR0X3NlYXJjaF9jbGVhbnVw X2NiOworCXNjLT5zY19uZXh0ID0gb3AtPm9fY2FsbGJhY2s7CisgICAgICAgIHNjLT5zY19wcml2 YXRlID0gY2k7CisJb3AtPm9fY2FsbGJhY2sgPSBzYzsKKworCXJldHVybiBTTEFQX0NCX0NPTlRJ TlVFOworCit9CitzdGF0aWMgaW50CityZXdhdHRfZGJfZGVzdHJveSgKKyAgICAgICAgQmFja2Vu ZERCICpiZSwKKyAgICAgICAgQ29uZmlnUmVwbHkgKmNyICkKK3sKKyAgICAgICAgc2xhcF9vdmVy aW5zdCAqb24gPSAoc2xhcF9vdmVyaW5zdCAqKWJlLT5iZF9pbmZvOworCisgICAgICAgIG9uLT5v bl9iaS5iaV9wcml2YXRlID0gTlVMTDsKKworICAgICAgICByZXR1cm4gMDsKK30KKworc3RhdGlj IHNsYXBfb3Zlcmluc3QgcmV3YXR0X292bDsKKworc3RhdGljIENvbmZpZ0RyaXZlciAgICAgcmV3 YXR0X2NmZ2VuOworCitzdGF0aWMgQ29uZmlnVGFibGUgcmV3YXR0X2NmZ1tdID0geworCXsgInJh X2F0dHJpYnV0ZSIsIE5VTEwsIDIsIDIsIDAsIEFSR19NQUdJQ3xSRVdBVFRfQVRUUklCVVRFLAor CQlyZXdhdHRfY2ZnZW4sICIoT0xjZmdDdEF0OjIyLjEgTkFNRSAnb2xjUmV3YXR0QXR0cmlidXRl JyAiCisJCQkiREVTQyAnQXR0cmlidXRlIE5hbWUnICIKKwkJCSJFUVVBTElUWSBjYXNlSWdub3Jl TWF0Y2ggIgorCQkJIlNZTlRBWCBPTXNEaXJlY3RvcnlTdHJpbmcgIgorCQkJIlgtT1JERVJFRCAn VkFMVUVTJyApIiwgTlVMTCwgTlVMTCB9LAorCXsgInJhX3JlZ2V4IiwgTlVMTCwgMiwgMiwgMCwg QVJHX01BR0lDfFJFV0FUVF9SRUdFWCwKKwkJcmV3YXR0X2NmZ2VuLCAiKE9MY2ZnQ3RBdDoyMi4y IE5BTUUgJ29sY1Jld2F0dFJlZ2V4JyAiCisJCQkiREVTQyAnUmVnZXgnICIKKwkJCSJTWU5UQVgg T01zRGlyZWN0b3J5U3RyaW5nICIKKwkJCSJYLU9SREVSRUQgJ1ZBTFVFUycgKSIsIE5VTEwsIE5V TEwgfSwKKwl7ICJyYV9zdWIiLCBOVUxMLCAxLCAyLCAwLCBBUkdfTUFHSUN8UkVXQVRUX1NVQiwK KwkJcmV3YXR0X2NmZ2VuLCAiKE9MY2ZnQ3RBdDoyMi4zIE5BTUUgJ29sY1Jld2F0dFN1YicgIgor CQkJIkRFU0MgJ1N1YnN0aXR1dGlvbicgIgorCQkJIlNZTlRBWCBPTXNEaXJlY3RvcnlTdHJpbmcg IgorCQkJIlgtT1JERVJFRCAnVkFMVUVTJyApIiwgTlVMTCwgTlVMTCB9LAorCXsgInJhX2F0dHJp YnV0ZV90IiwgTlVMTCwgMiwgMiwgMCwgQVJHX01BR0lDfFJFV0FUVF9BVFRSSUJVVEVfVCwKKwkJ cmV3YXR0X2NmZ2VuLCAiKE9MY2ZnQ3RBdDoyMi40IE5BTUUgJ29sY1Jld2F0dEF0dHJpYnV0ZVQn ICIKKwkJCSJERVNDICdUcmlnZ2VyaW5nIEF0dHJpYnV0ZSBOYW1lJyAiCisJCQkiU1lOVEFYIE9N c0RpcmVjdG9yeVN0cmluZyAiCisJCQkiWC1PUkRFUkVEICdWQUxVRVMnICkiLCBOVUxMLCBOVUxM IH0sCisJeyAicmFfcmVnZXhfdCIsIE5VTEwsIDIsIDIsIDAsIEFSR19NQUdJQ3xSRVdBVFRfUkVH RVhfVCwKKwkJcmV3YXR0X2NmZ2VuLCAiKE9MY2ZnQ3RBdDoyMi41IE5BTUUgJ29sY1Jld2F0dFJl Z2V4VCcgIgorCQkJIkRFU0MgJ1RyaWdnZXJpbmcgUmVnZXgnICIKKwkJCSJTWU5UQVggT01zRGly ZWN0b3J5U3RyaW5nICIKKwkJCSJYLU9SREVSRUQgJ1ZBTFVFUycgKSIsIE5VTEwsIE5VTEwgfSwK Kwl7IE5VTEwsIE5VTEwsIDAsIDAsIDAsIEFSR19JR05PUkVEIH0KK307CisKK3N0YXRpYyBDb25m aWdPQ3MgcmV3YXR0X29jc1tdID0geworCXsgIiggT0xjZmdDdE9jOjIyLjEgIgorCSAgIk5BTUUg J29sY1Jld2F0dENvbmZpZycgIgorCSAgIkRFU0MgJ0F0dHJpYnV0ZSBSZXdhdHQgY29uZmlndXJh dGlvbicgIgorCSAgIlNVUCBvbGNPdmVybGF5Q29uZmlnICIKKwkgICJNVVNUICggb2xjUmV3YXR0 QXR0cmlidXRlICQgb2xjUmV3YXR0UmVnZXgpICIgCisJICAiTUFZICggb2xjUmV3YXR0UmVnZXhU ICQgb2xjUmV3YXR0U3ViICQgb2xjUmV3YXR0QXR0cmlidXRlVCApICIgCisJICAiICkgIiwgCisJ ICBDZnRfT3ZlcmxheSwgcmV3YXR0X2NmZyB9LAorCXsgTlVMTCwgMCwgTlVMTCB9Cit9OworCitz dGF0aWMgaW50CityZXdhdHRfaW5pdGlhbGl6ZSggdm9pZCApIHsKKwlpbnQgcmM7CisJcmV3YXR0 X292bC5vbl9iaS5iaV90eXBlID0gInJld2F0dCI7CisKKwlyZXdhdHRfb3ZsLm9uX2JpLmJpX2Ri X2Rlc3Ryb3kgPSByZXdhdHRfZGJfZGVzdHJveTsKKwlyZXdhdHRfb3ZsLm9uX2JpLmJpX29wX3Nl YXJjaCA9IHJld2F0dF9zZWFyY2g7CisJcmV3YXR0X292bC5vbl9iaS5iaV9jZl9vY3MgPSByZXdh dHRfb2NzOworCQorCURlYnVnKCBMREFQX0RFQlVHX1RSQUNFLCAicmV3YXR0X2luaXRpYWxpemU6 IHJld2F0dF9vdmwub25fYmkuYmlfdHlwZT0gICVzXG4iLCByZXdhdHRfb3ZsLm9uX2JpLmJpX3R5 cGUgLCAwLDAgKTsKKwlyYyA9IGNvbmZpZ19yZWdpc3Rlcl9zY2hlbWEgKCByZXdhdHRfY2ZnLHJl d2F0dF9vY3MgKTsKKwlpZiAoIHJjICkgCisJCXJldHVybiByYzsKKwlyZXR1cm4gb3ZlcmxheV9y ZWdpc3RlciggJnJld2F0dF9vdmwgKTsKK30KKworaW50IGluaXRfbW9kdWxlKGludCBhcmdjLCBj aGFyICphcmd2W10pIHsKKwlyZXR1cm4gcmV3YXR0X2luaXRpYWxpemUoKTsKK30KKwotLSAKMS43 LjUuNAoK --=_c864110a076fc513331e0370bcb9adbe--

1 0

(ITS#7631) Overlay to rewrite value of attribute using regex
by bart＠icm.edu.pl 24 Jun '13

24 Jun '13

Full_Name: Dominik Bartkiewicz Version: OS: Linux URL: Submission from: (NULL) (89.73.105.138) A simple overlay allows override attribute values. In our case, it we replicate users date from three different servers and we wanted to override attributes such as homeDirectory, shell. a sample config: overlay rewatt ra_attribute homeDirectory ra_regex "home/(users|staff|guest)" ra_sub "icm/hydra/home/local" DB

1 0

Re: (ITS#7627) [Patch] Fix segfault in slaptest
by hyc＠symas.com 23 Jun '13

23 Jun '13

jsynacek(a)redhat.com wrote: > Full_Name: Jan Synacek > Version: master > OS: Linux - Fedora 18 > URL: http://jsynacek.fedorapeople.org/openldap/slaptest/0001-Fix-segfault-in-sla… > Submission from: (NULL) (209.132.186.34) > > > Consider the following configuration: > http://jsynacek.fedorapeople.org/openldap/slaptest/slapd-segfault.conf > > When an overlay is specified after the 'database monitor', slaptest segfaults. > I'm not sure whether such configuration makes much sense, however I think that > slaptest shouldn't segfault. > > To reproduce, use the above config and run: > slapd -Tt -f slapd-segfault.conf -F /path/to/a/dir Unable to reproduce any of this. No crash, and no uninit'd memory references in valgrind. I think something is corrupted in your source or build tree. > > Backtrace: > #0 0x0000003385009b70 in pthread_mutex_lock () from /usr/lib64/libpthread.so.0 > #1 0x00007ffff7da524d in ldap_pvt_thread_mutex_lock (mutex=0x25) at > thr_posix.c:296 > #2 0x00000000005574b9 in monitor_cache_get (mi=0x1d, ndn=0x7fffffffde30, > ep=0x7fffffffde28) at cache.c:161 > #3 0x000000000051a10d in monitor_back_unregister_entry_attrs (ndn_in=0x908230, > target_a=0x0, target_cb=0xa70030, > nbase=0x0, scope=0, filter=0x0) at init.c:1520 > #4 0x000000000051a5b0 in monitor_back_unregister_entry_callback (ndn=0x908230, > cb=0xa70030, nbase=0x0, scope=0, > filter=0x0) at init.c:1632 > #5 0x00000000004f6f19 in bdb_monitor_db_close (be=0x907d70) at monitor.c:500 > #6 0x00000000004ef0b4 in bdb_db_close (be=0x907d70, cr=0x0) at init.c:595 > #7 0x0000000000454ad5 in backend_shutdown (be=0x907d70) at backend.c:383 > #8 0x00000000004814a9 in slap_shutdown (be=0x0) at init.c:232 > #9 0x00000000004de90d in slap_tool_destroy () at slapcommon.c:936 > #10 0x00000000004e0435 in slaptest (argc=6, argv=0x7fffffffe228) at > slaptest.c:116 > #11 0x000000000041a9f5 in main (argc=6, argv=0x7fffffffe228) at main.c:665 > > Notice the corrupt 'mi' pointer in frame #2. > > The segfault does not always appear, so here is the corresponding valgrind > output: > ==6751== Memcheck, a memory error detector > ==6751== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al. > ==6751== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info > ==6751== Command: /home/jsynacek/work/2-upstream/openldap-git/servers/slapd/.libs/lt-slapd > -Tt -f slapd-segfault.conf -F ./testconf > ==6751== > 51c1a34e bdb_db_open: database "dc=example,dc=com": unclean shutdown detected; > attempting recovery. > 51c1a34e bdb_db_open: warning - no DB_CONFIG file found in directory > /var/lib/ldap: (2). > Expect poor performance for suffix "dc=example,dc=com". > 51c1a34e bdb_db_open: database "dc=example,dc=com": recovery skipped in > read-only mode. Run manual recovery if errors are encountered. > config file testing succeeded > ==6751== Conditional jump or move depends on uninitialised value(s) > ==6751== at 0x519E9D: monitor_back_unregister_entry_attrs (init.c:1473) > ==6751== by 0x51A5AF: monitor_back_unregister_entry_callback (init.c:1632) > ==6751== by 0x4F6F18: bdb_monitor_db_close (monitor.c:500) > ==6751== by 0x4EF0B3: bdb_db_close (init.c:595) > ==6751== by 0x454AD4: backend_shutdown (backend.c:383) > ==6751== by 0x4814A8: slap_shutdown (init.c:232) > ==6751== by 0x4DE90C: slap_tool_destroy (slapcommon.c:936) > ==6751== by 0x4E0434: slaptest (slaptest.c:116) > ==6751== by 0x41A9F4: main (main.c:665) > ==6751== > ==6751== Conditional jump or move depends on uninitialised value(s) > ==6751== at 0x5573EA: monitor_cache_get (cache.c:150) > ==6751== by 0x51A10C: monitor_back_unregister_entry_attrs (init.c:1520) > ==6751== by 0x51A5AF: monitor_back_unregister_entry_callback (init.c:1632) > ==6751== by 0x4F6F18: bdb_monitor_db_close (monitor.c:500) > ==6751== by 0x4EF0B3: bdb_db_close (init.c:595) > ==6751== by 0x454AD4: backend_shutdown (backend.c:383) > ==6751== by 0x4814A8: slap_shutdown (init.c:232) > ==6751== by 0x4DE90C: slap_tool_destroy (slapcommon.c:936) > ==6751== by 0x4E0434: slaptest (slaptest.c:116) > ==6751== by 0x41A9F4: main (main.c:665) > ==6751== > ==6751== Use of uninitialised value of size 8 > ==6751== at 0x3385009B70: pthread_mutex_lock (in > /usr/lib64/libpthread-2.16.so) > ==6751== by 0x4C2524C: ldap_pvt_thread_mutex_lock (thr_posix.c:296) > ==6751== by 0x5574B8: monitor_cache_get (cache.c:161) > ==6751== by 0x51A10C: monitor_back_unregister_entry_attrs (init.c:1520) > ==6751== by 0x51A5AF: monitor_back_unregister_entry_callback (init.c:1632) > ==6751== by 0x4F6F18: bdb_monitor_db_close (monitor.c:500) > ==6751== by 0x4EF0B3: bdb_db_close (init.c:595) > ==6751== by 0x454AD4: backend_shutdown (backend.c:383) > ==6751== by 0x4814A8: slap_shutdown (init.c:232) > ==6751== by 0x4DE90C: slap_tool_destroy (slapcommon.c:936) > ==6751== by 0x4E0434: slaptest (slaptest.c:116) > ==6751== by 0x41A9F4: main (main.c:665) > ==6751== > ==6751== Invalid read of size 4 > ==6751== at 0x3385009B70: pthread_mutex_lock (in > /usr/lib64/libpthread-2.16.so) > ==6751== by 0x4C2524C: ldap_pvt_thread_mutex_lock (thr_posix.c:296) > ==6751== by 0x5574B8: monitor_cache_get (cache.c:161) > ==6751== by 0x51A10C: monitor_back_unregister_entry_attrs (init.c:1520) > ==6751== by 0x51A5AF: monitor_back_unregister_entry_callback (init.c:1632) > ==6751== by 0x4F6F18: bdb_monitor_db_close (monitor.c:500) > ==6751== by 0x4EF0B3: bdb_db_close (init.c:595) > ==6751== by 0x454AD4: backend_shutdown (backend.c:383) > ==6751== by 0x4814A8: slap_shutdown (init.c:232) > ==6751== by 0x4DE90C: slap_tool_destroy (slapcommon.c:936) > ==6751== by 0x4E0434: slaptest (slaptest.c:116) > ==6751== by 0x41A9F4: main (main.c:665) > ==6751== Address 0x37 is not stack'd, malloc'd or (recently) free'd > ==6751== > ==6751== > ==6751== Process terminating with default action of signal 11 (SIGSEGV) > ==6751== Access not within mapped region at address 0x37 > ==6751== at 0x3385009B70: pthread_mutex_lock (in > /usr/lib64/libpthread-2.16.so) > ==6751== by 0x4C2524C: ldap_pvt_thread_mutex_lock (thr_posix.c:296) > ==6751== by 0x5574B8: monitor_cache_get (cache.c:161) > ==6751== by 0x51A10C: monitor_back_unregister_entry_attrs (init.c:1520) > ==6751== by 0x51A5AF: monitor_back_unregister_entry_callback (init.c:1632) > ==6751== by 0x4F6F18: bdb_monitor_db_close (monitor.c:500) > ==6751== by 0x4EF0B3: bdb_db_close (init.c:595) > ==6751== by 0x454AD4: backend_shutdown (backend.c:383) > ==6751== by 0x4814A8: slap_shutdown (init.c:232) > ==6751== by 0x4DE90C: slap_tool_destroy (slapcommon.c:936) > ==6751== by 0x4E0434: slaptest (slaptest.c:116) > ==6751== by 0x41A9F4: main (main.c:665) > ==6751== If you believe this happened as a result of a stack > ==6751== overflow in your program's main thread (unlikely but > ==6751== possible), you can try to increase the size of the > ==6751== main thread stack using the --main-stacksize= flag. > ==6751== The main thread stack size used in this run was 8388608. > ==6751== > ==6751== HEAP SUMMARY: > ==6751== in use at exit: 1,784,260 bytes in 10,532 blocks > ==6751== total heap usage: 20,806 allocs, 10,274 frees, 4,333,045 bytes > allocated > ==6751== > ==6751== LEAK SUMMARY: > ==6751== definitely lost: 16 bytes in 1 blocks > ==6751== indirectly lost: 0 bytes in 0 blocks > ==6751== possibly lost: 0 bytes in 0 blocks > ==6751== still reachable: 1,784,244 bytes in 10,531 blocks > ==6751== suppressed: 0 bytes in 0 blocks > ==6751== Rerun with --leak-check=full to see details of leaked memory > ==6751== > ==6751== For counts of detected and suppressed errors, rerun with: -v > ==6751== Use --track-origins=yes to see where uninitialised values come from > ==6751== ERROR SUMMARY: 11 errors from 9 contexts (suppressed: 2 from 2) > > I'm not sure if my patch is correct. I feel it's more like a workaround, so feel > free to modify it if that's the case. > > -- -- 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#7628) back-mdb bug with test064-constraint
by hyc＠symas.com 23 Jun '13

23 Jun '13

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: master, 7c6b599de6d7c0e10aa8bf6920ca07d94605e8c2 > OS: Linux amd64 > URL: > Submission from: (NULL) (129.240.203.186) > Submitted by: hallvard > > > id2entry.c:mdb_opinfo_get() renews a txn which is in use. It gets > EINVAL, which it does not catch. Caught by this patch and test064: Fixed now in master. I've left this assert in place as well, it obviously Should Never Happen. > > index 84de09d..a247974 100644 > --- a/servers/slapd/back-mdb/id2entry.c > +++ b/servers/slapd/back-mdb/id2entry.c > @@ -507,3 +507,4 @@ mdb_opinfo_get( Operation *op, struct mdb_info *mdb, int > rdonly, mdb_op_info **m > if ( renew ) { > - mdb_txn_renew( moi->moi_txn ); > + rc = mdb_txn_renew( moi->moi_txn ); > + assert(rc == MDB_SUCCESS); > } > > Core file in ada:/home/hallvard/openldap.g/tests/core. > > > > #2 0x00007ff6a1609301 in *__GI___assert_fail (assertion=0x601014 "rc == 0", > file=<value optimized out>, line=509, > function=0x601141 "mdb_opinfo_get") at assert.c:81 > #3 0x0000000000515db1 in mdb_opinfo_get (op=0x7ff69e411130, mdb=0x7ff6a2a02010, > rdonly=1, moip=0x7ff69e280d08) > at id2entry.c:509 > #4 0x00000000004f2bed in mdb_search (op=0x7ff69e411130, rs=0x7ff69e4112a0) at > search.c:343 > #5 0x00000000004c4f08 in overlay_op_walk (op=0x7ff69e411130, rs=0x7ff69e4112a0, > which=op_search, oi=0x15b30e0, on=0x0) > at backover.c:691 > #6 0x00000000004c511f in over_op_func (op=0x7ff69e411130, rs=0x7ff69e4112a0, > which=op_search) at backover.c:743 > #7 0x00000000004c5207 in over_op_search (op=0x7ff69e411130, rs=0x7ff69e4112a0) > at backover.c:770 > #8 0x000000000052a197 in constraint_violation (c=0x15dc620, bv=0x1af6f90, > op=0x17c8cf0) at constraint.c:666 > #9 0x000000000052a82a in constraint_add (op=0x17c8cf0, rs=0x7ff69e411a60) at > constraint.c:812 > #10 0x00000000004c4e69 in overlay_op_walk (op=0x17c8cf0, rs=0x7ff69e411a60, > which=op_add, oi=0x15b30e0, on=0x15b32c0) > at backover.c:681 > #11 0x00000000004c511f in over_op_func (op=0x17c8cf0, rs=0x7ff69e411a60, > which=op_add) at backover.c:743 > #12 0x00000000004c52af in over_op_add (op=0x17c8cf0, rs=0x7ff69e411a60) at > backover.c:794 > #13 0x000000000043aa44 in fe_op_add (op=0x17c8cf0, rs=0x7ff69e411a60) at > add.c:334 > #14 0x000000000043a341 in do_add (op=0x17c8cf0, rs=0x7ff69e411a60) at add.c:194 > #15 0x0000000000430da3 in connection_operation (ctx=0x7ff69e411b90, > arg_v=0x17c8cf0) at connection.c:1155 > #16 0x0000000000431344 in connection_read_thread (ctx=0x7ff69e411b90, argv=0xb) > at connection.c:1291 > #17 0x00000000005953c5 in ldap_int_thread_pool_wrapper (xpool=0x1543920) at > tpool.c:688 > > > (gdb) frame 3 > #3 0x0000000000515db1 in mdb_opinfo_get (op=0x7ff69e411130, mdb=0x7ff6a2a02010, > rdonly=1, moip=0x7ff69e280d08) > at id2entry.c:509 > 509 assert(rc == MDB_SUCCESS); > (gdb) info locals > rc = 22 > renew = 1 > data = 0x1af36b0 > ctx = 0x7ff69e411b90 > moi = 0x7ff69e280d10 > oex = 0x0 > __PRETTY_FUNCTION__ = "mdb_opinfo_get" > (gdb) p *moi > $1 = {moi_oe = {oe_next = {sle_next = 0x7ff69e411850}, oe_key = 0x7ff6a2a02010}, > moi_txn = 0x1af36b0, moi_ref = 0, > moi_flag = 1 '\001'} > (gdb) p *moi->moi_txn > $2 = {mt_parent = 0x0, mt_child = 0x0, mt_next_pgno = 31, mt_txnid = 51, mt_env > = 0x17c0920, mt_free_pgs = 0x0, > mt_u = {dirty_list = 0x7ff6a2bd5080, reader = 0x7ff6a2bd5080}, mt_dbxs = > 0x17baa80, mt_dbs = 0x1af3718, > mt_cursors = 0x0, mt_dbflags = 0x1af4f78 "\b\b\n\b\b\b\n\n\n\n\n", mt_numdbs = > 11, mt_flags = 1, mt_dirty_room = 0, > mt_toggle = 1} > > The EINVAL was returned because mt_dbxs != NULL. > > -- -- 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#6970)
by michael＠stroeder.com 19 Jun '13

19 Jun '13

breuil(a)craig.fr wrote: > after being adviced to try with mdb backend instead, which doesnt use > locking, slapd exploded as soon as i had enabled the memberOf & > autoGroup overlays and one client tried to connect to the server: The last release you mentioned in this ITS was 2.4.31. Is that the version you're still using? You should not use back-mdb with this release. Use at least 2.4.35 or better current RE24 from git repo. http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=tree;h=refs/heads… Ciao, Michael.

1 0

(ITS#7628) back-mdb bug with test064-constraint
by h.b.furuseth＠usit.uio.no 19 Jun '13

19 Jun '13

Full_Name: Hallvard B Furuseth Version: master, 7c6b599de6d7c0e10aa8bf6920ca07d94605e8c2 OS: Linux amd64 URL: Submission from: (NULL) (129.240.203.186) Submitted by: hallvard id2entry.c:mdb_opinfo_get() renews a txn which is in use. It gets EINVAL, which it does not catch. Caught by this patch and test064: index 84de09d..a247974 100644 --- a/servers/slapd/back-mdb/id2entry.c +++ b/servers/slapd/back-mdb/id2entry.c @@ -507,3 +507,4 @@ mdb_opinfo_get( Operation *op, struct mdb_info *mdb, int rdonly, mdb_op_info **m if ( renew ) { - mdb_txn_renew( moi->moi_txn ); + rc = mdb_txn_renew( moi->moi_txn ); + assert(rc == MDB_SUCCESS); } Core file in ada:/home/hallvard/openldap.g/tests/core. #2 0x00007ff6a1609301 in *__GI___assert_fail (assertion=0x601014 "rc == 0", file=<value optimized out>, line=509, function=0x601141 "mdb_opinfo_get") at assert.c:81 #3 0x0000000000515db1 in mdb_opinfo_get (op=0x7ff69e411130, mdb=0x7ff6a2a02010, rdonly=1, moip=0x7ff69e280d08) at id2entry.c:509 #4 0x00000000004f2bed in mdb_search (op=0x7ff69e411130, rs=0x7ff69e4112a0) at search.c:343 #5 0x00000000004c4f08 in overlay_op_walk (op=0x7ff69e411130, rs=0x7ff69e4112a0, which=op_search, oi=0x15b30e0, on=0x0) at backover.c:691 #6 0x00000000004c511f in over_op_func (op=0x7ff69e411130, rs=0x7ff69e4112a0, which=op_search) at backover.c:743 #7 0x00000000004c5207 in over_op_search (op=0x7ff69e411130, rs=0x7ff69e4112a0) at backover.c:770 #8 0x000000000052a197 in constraint_violation (c=0x15dc620, bv=0x1af6f90, op=0x17c8cf0) at constraint.c:666 #9 0x000000000052a82a in constraint_add (op=0x17c8cf0, rs=0x7ff69e411a60) at constraint.c:812 #10 0x00000000004c4e69 in overlay_op_walk (op=0x17c8cf0, rs=0x7ff69e411a60, which=op_add, oi=0x15b30e0, on=0x15b32c0) at backover.c:681 #11 0x00000000004c511f in over_op_func (op=0x17c8cf0, rs=0x7ff69e411a60, which=op_add) at backover.c:743 #12 0x00000000004c52af in over_op_add (op=0x17c8cf0, rs=0x7ff69e411a60) at backover.c:794 #13 0x000000000043aa44 in fe_op_add (op=0x17c8cf0, rs=0x7ff69e411a60) at add.c:334 #14 0x000000000043a341 in do_add (op=0x17c8cf0, rs=0x7ff69e411a60) at add.c:194 #15 0x0000000000430da3 in connection_operation (ctx=0x7ff69e411b90, arg_v=0x17c8cf0) at connection.c:1155 #16 0x0000000000431344 in connection_read_thread (ctx=0x7ff69e411b90, argv=0xb) at connection.c:1291 #17 0x00000000005953c5 in ldap_int_thread_pool_wrapper (xpool=0x1543920) at tpool.c:688 (gdb) frame 3 #3 0x0000000000515db1 in mdb_opinfo_get (op=0x7ff69e411130, mdb=0x7ff6a2a02010, rdonly=1, moip=0x7ff69e280d08) at id2entry.c:509 509 assert(rc == MDB_SUCCESS); (gdb) info locals rc = 22 renew = 1 data = 0x1af36b0 ctx = 0x7ff69e411b90 moi = 0x7ff69e280d10 oex = 0x0 __PRETTY_FUNCTION__ = "mdb_opinfo_get" (gdb) p *moi $1 = {moi_oe = {oe_next = {sle_next = 0x7ff69e411850}, oe_key = 0x7ff6a2a02010}, moi_txn = 0x1af36b0, moi_ref = 0, moi_flag = 1 '\001'} (gdb) p *moi->moi_txn $2 = {mt_parent = 0x0, mt_child = 0x0, mt_next_pgno = 31, mt_txnid = 51, mt_env = 0x17c0920, mt_free_pgs = 0x0, mt_u = {dirty_list = 0x7ff6a2bd5080, reader = 0x7ff6a2bd5080}, mt_dbxs = 0x17baa80, mt_dbs = 0x1af3718, mt_cursors = 0x0, mt_dbflags = 0x1af4f78 "\b\b\n\b\b\b\n\n\n\n\n", mt_numdbs = 11, mt_flags = 1, mt_dirty_room = 0, mt_toggle = 1} The EINVAL was returned because mt_dbxs != NULL.

1 0

(ITS#6970)
by breuil＠craig.fr 19 Jun '13

19 Jun '13

Hi, after being adviced to try with mdb backend instead, which doesnt use locking, slapd exploded as soon as i had enabled the memberOf & autoGroup overlays and one client tried to connect to the server: 51c1b560 => mdb_search 51c1b560 mdb_dn2entry("dc=myorg") 51c1b560 => mdb_dn2id("dc=myorg") 51c1b560 <= mdb_dn2id: got id=0x1 51c1b560 => mdb_entry_decode: 51c1b560 <= mdb_entry_decode Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffb1fd3700 (LWP 15475)] autogroup_response (op=0x7ffff82d52b0, rs=0x7fffb1fd2a50) at autogroup.c:927 927 autogroup_def_t *agd = agi->agi_def; (gdb) bt #0 autogroup_response (op=0x7ffff82d52b0, rs=0x7fffb1fd2a50) at autogroup.c:927 #1 0x00007ffff7f7f598 in over_back_response (op=0x7ffff82d52b0, rs=0x7fffb1fd2a50) at ../../../../servers/slapd/backover.c:237 #2 0x00007ffff7f227d6 in slap_response_play (op=op@entry=0x7ffff82d52b0, rs=rs@entry=0x7fffb1fd2a50) at ../../../../servers/slapd/result.c:507 #3 0x00007ffff7f25261 in slap_send_search_entry (op=0x7ffff82d52b0, rs=0x7fffb1fd2a50) at ../../../../servers/slapd/result.c:1008 #4 0x00007ffff3213600 in mdb_search (op=0x7ffff82d52b0, rs=<optimized out>) at ../../../../../servers/slapd/back-mdb/search.c:852 #5 0x00007ffff7f801c6 in overlay_op_walk (op=op@entry=0x7ffff82d52b0, rs=0x7fffb1fd2a50, which=op_search, oi=0x7ffff82e6e50, on=0x0) at ../../../../servers/slapd/backover.c:671 #6 0x00007ffff7f8031b in over_op_func (op=0x7ffff82d52b0, rs=<optimized out>, which=<optimized out>) at ../../../../servers/slapd/backover.c:723 #7 0x00007ffff7f15641 in fe_op_search (op=0x7ffff82d52b0, rs=0x7fffb1fd2a50) at ../../../../servers/slapd/search.c:402 #8 0x00007ffff7f14f06 in do_search (op=0x7ffff82d52b0, rs=0x7fffb1fd2a50) at ../../../../servers/slapd/search.c:247 #9 0x00007ffff7f12961 in connection_operation (ctx=ctx@entry=0x7fffb1fd2ba0, arg_v=arg_v@entry=0x7ffff82d52b0) at ../../../../servers/slapd/connection.c:1150 #10 0x00007ffff7f12c84 in connection_read_thread (ctx=0x7fffb1fd2ba0, argv=<optimized out>) at ../../../../servers/slapd/connection.c:1286 #11 0x00007ffff7a73ff3 in ?? () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2 #12 0x00007ffff5c66b50 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #13 0x00007ffff59b0a7d in clone () from /lib/x86_64-linux-gnu/libc.so.6 #14 0x0000000000000000 in ?? () (gdb) p agi $1 = (autogroup_info_t *) 0x0 So mdb doesnt seem to be an option here... -- Landry Breuil Mouton a 5 pattes du CRAIG

1 0

(ITS#7627) [Patch] Fix segfault in slaptest
by jsynacek＠redhat.com 19 Jun '13

19 Jun '13

Full_Name: Jan Synacek Version: master OS: Linux - Fedora 18 URL: http://jsynacek.fedorapeople.org/openldap/slaptest/0001-Fix-segfault-in-sla… Submission from: (NULL) (209.132.186.34) Consider the following configuration: http://jsynacek.fedorapeople.org/openldap/slaptest/slapd-segfault.conf When an overlay is specified after the 'database monitor', slaptest segfaults. I'm not sure whether such configuration makes much sense, however I think that slaptest shouldn't segfault. To reproduce, use the above config and run: slapd -Tt -f slapd-segfault.conf -F /path/to/a/dir Backtrace: #0 0x0000003385009b70 in pthread_mutex_lock () from /usr/lib64/libpthread.so.0 #1 0x00007ffff7da524d in ldap_pvt_thread_mutex_lock (mutex=0x25) at thr_posix.c:296 #2 0x00000000005574b9 in monitor_cache_get (mi=0x1d, ndn=0x7fffffffde30, ep=0x7fffffffde28) at cache.c:161 #3 0x000000000051a10d in monitor_back_unregister_entry_attrs (ndn_in=0x908230, target_a=0x0, target_cb=0xa70030, nbase=0x0, scope=0, filter=0x0) at init.c:1520 #4 0x000000000051a5b0 in monitor_back_unregister_entry_callback (ndn=0x908230, cb=0xa70030, nbase=0x0, scope=0, filter=0x0) at init.c:1632 #5 0x00000000004f6f19 in bdb_monitor_db_close (be=0x907d70) at monitor.c:500 #6 0x00000000004ef0b4 in bdb_db_close (be=0x907d70, cr=0x0) at init.c:595 #7 0x0000000000454ad5 in backend_shutdown (be=0x907d70) at backend.c:383 #8 0x00000000004814a9 in slap_shutdown (be=0x0) at init.c:232 #9 0x00000000004de90d in slap_tool_destroy () at slapcommon.c:936 #10 0x00000000004e0435 in slaptest (argc=6, argv=0x7fffffffe228) at slaptest.c:116 #11 0x000000000041a9f5 in main (argc=6, argv=0x7fffffffe228) at main.c:665 Notice the corrupt 'mi' pointer in frame #2. The segfault does not always appear, so here is the corresponding valgrind output: ==6751== Memcheck, a memory error detector ==6751== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al. ==6751== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info ==6751== Command: /home/jsynacek/work/2-upstream/openldap-git/servers/slapd/.libs/lt-slapd -Tt -f slapd-segfault.conf -F ./testconf ==6751== 51c1a34e bdb_db_open: database "dc=example,dc=com": unclean shutdown detected; attempting recovery. 51c1a34e bdb_db_open: warning - no DB_CONFIG file found in directory /var/lib/ldap: (2). Expect poor performance for suffix "dc=example,dc=com". 51c1a34e bdb_db_open: database "dc=example,dc=com": recovery skipped in read-only mode. Run manual recovery if errors are encountered. config file testing succeeded ==6751== Conditional jump or move depends on uninitialised value(s) ==6751== at 0x519E9D: monitor_back_unregister_entry_attrs (init.c:1473) ==6751== by 0x51A5AF: monitor_back_unregister_entry_callback (init.c:1632) ==6751== by 0x4F6F18: bdb_monitor_db_close (monitor.c:500) ==6751== by 0x4EF0B3: bdb_db_close (init.c:595) ==6751== by 0x454AD4: backend_shutdown (backend.c:383) ==6751== by 0x4814A8: slap_shutdown (init.c:232) ==6751== by 0x4DE90C: slap_tool_destroy (slapcommon.c:936) ==6751== by 0x4E0434: slaptest (slaptest.c:116) ==6751== by 0x41A9F4: main (main.c:665) ==6751== ==6751== Conditional jump or move depends on uninitialised value(s) ==6751== at 0x5573EA: monitor_cache_get (cache.c:150) ==6751== by 0x51A10C: monitor_back_unregister_entry_attrs (init.c:1520) ==6751== by 0x51A5AF: monitor_back_unregister_entry_callback (init.c:1632) ==6751== by 0x4F6F18: bdb_monitor_db_close (monitor.c:500) ==6751== by 0x4EF0B3: bdb_db_close (init.c:595) ==6751== by 0x454AD4: backend_shutdown (backend.c:383) ==6751== by 0x4814A8: slap_shutdown (init.c:232) ==6751== by 0x4DE90C: slap_tool_destroy (slapcommon.c:936) ==6751== by 0x4E0434: slaptest (slaptest.c:116) ==6751== by 0x41A9F4: main (main.c:665) ==6751== ==6751== Use of uninitialised value of size 8 ==6751== at 0x3385009B70: pthread_mutex_lock (in /usr/lib64/libpthread-2.16.so) ==6751== by 0x4C2524C: ldap_pvt_thread_mutex_lock (thr_posix.c:296) ==6751== by 0x5574B8: monitor_cache_get (cache.c:161) ==6751== by 0x51A10C: monitor_back_unregister_entry_attrs (init.c:1520) ==6751== by 0x51A5AF: monitor_back_unregister_entry_callback (init.c:1632) ==6751== by 0x4F6F18: bdb_monitor_db_close (monitor.c:500) ==6751== by 0x4EF0B3: bdb_db_close (init.c:595) ==6751== by 0x454AD4: backend_shutdown (backend.c:383) ==6751== by 0x4814A8: slap_shutdown (init.c:232) ==6751== by 0x4DE90C: slap_tool_destroy (slapcommon.c:936) ==6751== by 0x4E0434: slaptest (slaptest.c:116) ==6751== by 0x41A9F4: main (main.c:665) ==6751== ==6751== Invalid read of size 4 ==6751== at 0x3385009B70: pthread_mutex_lock (in /usr/lib64/libpthread-2.16.so) ==6751== by 0x4C2524C: ldap_pvt_thread_mutex_lock (thr_posix.c:296) ==6751== by 0x5574B8: monitor_cache_get (cache.c:161) ==6751== by 0x51A10C: monitor_back_unregister_entry_attrs (init.c:1520) ==6751== by 0x51A5AF: monitor_back_unregister_entry_callback (init.c:1632) ==6751== by 0x4F6F18: bdb_monitor_db_close (monitor.c:500) ==6751== by 0x4EF0B3: bdb_db_close (init.c:595) ==6751== by 0x454AD4: backend_shutdown (backend.c:383) ==6751== by 0x4814A8: slap_shutdown (init.c:232) ==6751== by 0x4DE90C: slap_tool_destroy (slapcommon.c:936) ==6751== by 0x4E0434: slaptest (slaptest.c:116) ==6751== by 0x41A9F4: main (main.c:665) ==6751== Address 0x37 is not stack'd, malloc'd or (recently) free'd ==6751== ==6751== ==6751== Process terminating with default action of signal 11 (SIGSEGV) ==6751== Access not within mapped region at address 0x37 ==6751== at 0x3385009B70: pthread_mutex_lock (in /usr/lib64/libpthread-2.16.so) ==6751== by 0x4C2524C: ldap_pvt_thread_mutex_lock (thr_posix.c:296) ==6751== by 0x5574B8: monitor_cache_get (cache.c:161) ==6751== by 0x51A10C: monitor_back_unregister_entry_attrs (init.c:1520) ==6751== by 0x51A5AF: monitor_back_unregister_entry_callback (init.c:1632) ==6751== by 0x4F6F18: bdb_monitor_db_close (monitor.c:500) ==6751== by 0x4EF0B3: bdb_db_close (init.c:595) ==6751== by 0x454AD4: backend_shutdown (backend.c:383) ==6751== by 0x4814A8: slap_shutdown (init.c:232) ==6751== by 0x4DE90C: slap_tool_destroy (slapcommon.c:936) ==6751== by 0x4E0434: slaptest (slaptest.c:116) ==6751== by 0x41A9F4: main (main.c:665) ==6751== If you believe this happened as a result of a stack ==6751== overflow in your program's main thread (unlikely but ==6751== possible), you can try to increase the size of the ==6751== main thread stack using the --main-stacksize= flag. ==6751== The main thread stack size used in this run was 8388608. ==6751== ==6751== HEAP SUMMARY: ==6751== in use at exit: 1,784,260 bytes in 10,532 blocks ==6751== total heap usage: 20,806 allocs, 10,274 frees, 4,333,045 bytes allocated ==6751== ==6751== LEAK SUMMARY: ==6751== definitely lost: 16 bytes in 1 blocks ==6751== indirectly lost: 0 bytes in 0 blocks ==6751== possibly lost: 0 bytes in 0 blocks ==6751== still reachable: 1,784,244 bytes in 10,531 blocks ==6751== suppressed: 0 bytes in 0 blocks ==6751== Rerun with --leak-check=full to see details of leaked memory ==6751== ==6751== For counts of detected and suppressed errors, rerun with: -v ==6751== Use --track-origins=yes to see where uninitialised values come from ==6751== ERROR SUMMARY: 11 errors from 9 contexts (suppressed: 2 from 2) I'm not sure if my patch is correct. I feel it's more like a workaround, so feel free to modify it if that's the case.

1 0

Re: (ITS#7623) P_SUBP page inn MDB dirty_list
by h.b.furuseth＠usit.uio.no 18 Jun '13

18 Jun '13

Howard Chu writes: > Try this instead. Currently testing it on my PC. Passes all tests. Dropped P_FAKE and pushed to mdb.master. -- Hallvard

1 0

Re: (ITS#7623) P_SUBP page inn MDB dirty_list
by hyc＠symas.com 17 Jun '13

17 Jun '13

This is a multi-part message in MIME format. --------------010507020109080701050704 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hallvard Breien Furuseth wrote: > Howard Chu writes: >> The flag is being propagated when the page grows and turns into a real page. >> Fixed by this simple patch. >> (...) >> mp->mp_flags = fp->mp_flags | P_DIRTY; >> + mp->mp_flags &= ~(P_SUBP|P_FAKE); >> mp->mp_pad = fp->mp_pad; > > This fixes test043, but breaks test046-dds: ldapexop exits with 49 > (invalidCredentials) for "Refreshing the meeting as $BJORNSDN...". > It passes without the patch. This is RE24 (4dc62839c2324b46bfd6) > or RE24 + mdb.master (60086c1bc77fafecef27). Try this instead. Currently testing it on my PC. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --------------010507020109080701050704 Content-Type: text/plain; charset=UTF-8; name="dif.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="dif.txt" diff --git a/libraries/liblmdb/mdb.c b/libraries/liblmdb/mdb.c index c9f98cc..33642c8 100644 --- a/libraries/liblmdb/mdb.c +++ b/libraries/liblmdb/mdb.c @@ -5190,6 +5190,7 @@ more: MDB_page *mp; unsigned int offset; unsigned int i; + uint16_t fp_flags; fp = NODEDATA(leaf); if (flags == MDB_CURRENT) { @@ -5209,6 +5210,7 @@ reuse: offset = NODESIZE + sizeof(indx_t) + data->mv_size; } offset += offset & 1; + fp_flags = fp->mp_flags; if (NODESIZE + sizeof(indx_t) + NODEKSZ(leaf) + NODEDSZ(leaf) + offset >= mc->mc_txn->mt_env->me_nodemax) { /* yes, convert it */ @@ -5232,6 +5234,7 @@ reuse: offset = mc->mc_txn->mt_env->me_psize - NODEDSZ(leaf); flags |= F_DUPDATA|F_SUBDATA; dummy.md_root = mp->mp_pgno; + fp_flags &= ~(P_SUBP|P_FAKE); } else { /* no, just grow it */ rdata = &xdata; @@ -5241,7 +5244,7 @@ reuse: mp->mp_pgno = mc->mc_pg[mc->mc_top]->mp_pgno; flags |= F_DUPDATA; } - mp->mp_flags = fp->mp_flags | P_DIRTY; + mp->mp_flags = fp_flags | P_DIRTY; mp->mp_pad = fp->mp_pad; mp->mp_lower = fp->mp_lower; mp->mp_upper = fp->mp_upper + offset; --------------010507020109080701050704--

1 0

Re: (ITS#7623) P_SUBP page inn MDB dirty_list
by h.b.furuseth＠usit.uio.no 17 Jun '13

17 Jun '13

Howard Chu writes: > The flag is being propagated when the page grows and turns into a real page. > Fixed by this simple patch. > (...) > mp->mp_flags = fp->mp_flags | P_DIRTY; > + mp->mp_flags &= ~(P_SUBP|P_FAKE); > mp->mp_pad = fp->mp_pad; This fixes test043, but breaks test046-dds: ldapexop exits with 49 (invalidCredentials) for "Refreshing the meeting as $BJORNSDN...". It passes without the patch. This is RE24 (4dc62839c2324b46bfd6) or RE24 + mdb.master (60086c1bc77fafecef27). Ignoring 2nd patch, it did did not fix test043: ldapadd fails (32) when populating provider. -- Hallvard

1 0

Re: (ITS#7626) [Patch] Fix config_build_schema_inc
by jsynacek＠redhat.com 17 Jun '13

17 Jun '13

On 06/17/2013 02:41 PM, Howard Chu wrote: > jsynacek(a)redhat.com wrote: >> Full_Name: Jan Synacek >> Version: master >> OS: Linux - Fedora 18 >> URL: >> http://jsynacek.fedorapeople.org/openldap/0001-Fix-config_build_schema_inc.… >> Submission from: (NULL) (209.132.186.34) >> >> >> When converting a slapd.conf into the DIT configuration, slaptest incorrectly >> handles 'include' directives containing a custom file instead of a schema file. >> >> Example: >> custom.file: >> include /etc/ldap/schema/cosine.ldif >> >> slapd.conf >> ... >> include /path/to/custom.file >> ... >> >> Slaptest does not properly include cosine.ldif into the new configuration. > > Your example is invalid since slapd.conf format doesn't support including LDIF > files. > Sorry, I meant "schema" instead of "ldif". s/cosine.ldif/cosine.schema

1 0

Re: (ITS#7626) [Patch] Fix config_build_schema_inc
by hyc＠symas.com 17 Jun '13

17 Jun '13

jsynacek(a)redhat.com wrote: > Full_Name: Jan Synacek > Version: master > OS: Linux - Fedora 18 > URL: http://jsynacek.fedorapeople.org/openldap/0001-Fix-config_build_schema_inc.… > Submission from: (NULL) (209.132.186.34) > > > When converting a slapd.conf into the DIT configuration, slaptest incorrectly > handles 'include' directives containing a custom file instead of a schema file. > > Example: > custom.file: > include /etc/ldap/schema/cosine.ldif > > slapd.conf > ... > include /path/to/custom.file > ... > > Slaptest does not properly include cosine.ldif into the new configuration. Your example is invalid since slapd.conf format doesn't support including LDIF files. -- -- 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#7626) [Patch] Fix config_build_schema_inc
by jsynacek＠redhat.com 16 Jun '13

16 Jun '13

Full_Name: Jan Synacek Version: master OS: Linux - Fedora 18 URL: http://jsynacek.fedorapeople.org/openldap/0001-Fix-config_build_schema_inc.… Submission from: (NULL) (209.132.186.34) When converting a slapd.conf into the DIT configuration, slaptest incorrectly handles 'include' directives containing a custom file instead of a schema file. Example: custom.file: include /etc/ldap/schema/cosine.ldif slapd.conf ... include /path/to/custom.file ... Slaptest does not properly include cosine.ldif into the new configuration.

1 0

Re: (ITS#7623) P_SUBP page inn MDB dirty_list
by h.b.furuseth＠usit.uio.no 16 Jun '13

16 Jun '13

I wrote: >Howard Chu writes: >> Obviously this and the preceding line can be reduced to >> mp->mp_flags = fp->mp_flags ^ (P_DIRTY|P_SUBP|P_FAKE); > > They are not equivalent. fp->mp_flags can be P_LEAF|P_DIRTY in branch > "yes, convert it" and P_LEAF|P_DIRTY|P_SUBP|P_FAKE in the other branch. Found by test043 + assert(the patches were equivalent). -- Hallvard

1 0

Re: (ITS#7623) P_SUBP page inn MDB dirty_list
by h.b.furuseth＠usit.uio.no 16 Jun '13

16 Jun '13

Howard Chu writes: > Obviously this and the preceding line can be reduced to > mp->mp_flags = fp->mp_flags ^ (P_DIRTY|P_SUBP|P_FAKE); They are not equivalent. fp->mp_flags can be P_LEAF|P_DIRTY in branch "yes, convert it" and P_LEAF|P_DIRTY|P_SUBP|P_FAKE in the other branch. > With P_FAKE removed if your patch isn't kept. No, I don't want to steal a bit just for debugging either. I'm happy with "mp->mp_flags = (fp->mp_flags | P_DIRTY) & ~P_SUBP;" if the above was just a thinko. Well, I might include P_FAKE in my mdb/tests branch, #defined as 0 except when the MDB_TEST macro turns it on. -- Hallvard

1 0

Re: (ITS#7623) P_SUBP page inn MDB dirty_list
by hyc＠symas.com 16 Jun '13

16 Jun '13

hyc(a)symas.com wrote: > This is a multi-part message in MIME format. > --------------010403050509060707070108 > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > Content-Transfer-Encoding: 7bit > > h.b.furuseth(a)usit.uio.no wrote: >> Full_Name: Hallvard B Furuseth >> Version: RE24 + mdb.master 2d0b362b6f2b1247eb693008a39efaf341f15e82 >> OS: Linux x86_64 >> URL: >> Submission from: (NULL) (193.69.163.163) >> Submitted by: hallvard >> >> >> test043-delta-syncrepl crashes in RE24 + mdb.master + this patch. >> A sub-cursor sees a regular (non-sub) page which has P_SUB set, >> in dirty_list. The flag comes from the fake page in cursor_put. > > The flag is being propagated when the page grows and turns into a real page. > Fixed by this simple patch. Obviously this and the preceding line can be reduced to mp->mp_flags = fp->mp_flags ^ (P_DIRTY|P_SUBP|P_FAKE); With P_FAKE removed if your patch isn't kept. -- -- 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#7623) P_SUBP page inn MDB dirty_list
by hyc＠symas.com 16 Jun '13

16 Jun '13

This is a multi-part message in MIME format. --------------010403050509060707070108 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: RE24 + mdb.master 2d0b362b6f2b1247eb693008a39efaf341f15e82 > OS: Linux x86_64 > URL: > Submission from: (NULL) (193.69.163.163) > Submitted by: hallvard > > > test043-delta-syncrepl crashes in RE24 + mdb.master + this patch. > A sub-cursor sees a regular (non-sub) page which has P_SUB set, > in dirty_list. The flag comes from the fake page in cursor_put. The flag is being propagated when the page grows and turns into a real page. Fixed by this simple patch. I don't think we actually want to keep the debug code/flag you added, but I'll leave it to you to commit. > > Patch: > - Set P_FAKE flag for debugging, to see where the flag comes from. > - assert(not P_SUB) in page_get. > - valloc pages so we can see from the page address that it is > a regular page. > > --- libraries/liblmdb/mdb.c > +++ libraries/liblmdb/mdb.c > @@ -59,2 +59,3 @@ > #include <unistd.h> > +#include <malloc.h> > > @@ -582,2 +583,3 @@ typedef struct MDB_page { > #define P_SUBP 0x40 /**< for #MDB_DUPSORT sub-pages */ > +#define P_FAKE 0x80 /**< fake page */ > /** @} */ > @@ -1271,3 +1273,3 @@ mdb_page_malloc(MDB_cursor *mc, unsigned num) > } > - if ((ret = malloc(sz)) != NULL) { > + if ((ret = valloc(sz)) != NULL) { > VGMEMP_ALLOC(env, ret, sz); > @@ -2478,2 +2480,3 @@ mdb_txn_commit(MDB_txn *txn) > dp = txn->mt_u.dirty_list[i].mptr; > + assert(!(dp->mp_flags & P_SUBP)); > if (dp->mp_pgno != next) { > @@ -4069,2 +4072,3 @@ mdb_page_get(MDB_txn *txn, pgno_t pgno, MDB_page **ret, > int *lvl) > p = dl[x].mptr; > + /* assert(!(p->mp_flags & P_SUBP)); */ > goto done; > @@ -5164,3 +5168,3 @@ more: > fp->mp_pgno = mc->mc_pg[mc->mc_top]->mp_pgno; > - fp->mp_flags = P_LEAF|P_DIRTY|P_SUBP; > + fp->mp_flags = P_LEAF|P_DIRTY|P_SUBP|P_FAKE; > fp->mp_lower = PAGEHDRSZ; > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --------------010403050509060707070108 Content-Type: text/plain; charset=UTF-8; name="dif.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="dif.txt" diff --git a/libraries/liblmdb/mdb.c b/libraries/liblmdb/mdb.c index c9f98cc..1bc0f14 100644 --- a/libraries/liblmdb/mdb.c +++ b/libraries/liblmdb/mdb.c @@ -5242,6 +5242,7 @@ reuse: flags |= F_DUPDATA; } mp->mp_flags = fp->mp_flags | P_DIRTY; + mp->mp_flags &= ~(P_SUBP|P_FAKE); mp->mp_pad = fp->mp_pad; mp->mp_lower = fp->mp_lower; mp->mp_upper = fp->mp_upper + offset; --------------010403050509060707070108--

1 0

(ITS#7625) ppolicy doesn't support changing olcPasswordHash without restart
by joke＠seiken.de 14 Jun '13

14 Jun '13

Full_Name: Joke de Buhr Version: 2.4.35 OS: fedora 18 64bit URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (37.5.143.82) While using the password policy overlay changing the parameter olcPasswordHash causes an error upon password update. When changing the password via ldappasswd after changing the parameter olcPasswordHash the error Constraint violation (19) Password policy only allows one password value if returned to the client. Changing the password isn't possible until slapd is restarted. After restarting slapd changing the password works again. Please refer to my postings [1] on the mailing list. [1] http://www.openldap.org/lists/openldap-technical/201306/msg00122.html

1 0

(ITS#6970)
by breuil＠craig.fr 14 Jun '13

14 Jun '13

Hi, i'm also experiencing slapd deadlocks/lockups when using memberOf & autogroup, w/ 2.4.31. Both modules/overlays seem to step on each other's toes when updating an entry. Not 100% sure if it's the same issue as the OP was experiencing though. My config is the following : - i have a ou=people branch with inetOrgPerson objects, each one having an organization attr. - i have a ou=groups branch with groupOfNames objects, each populated by autogroup by using a labeledURI doing a filter on the organization attr (among other conditions) of the inetOrgPerson objects. - and finally, i have memberOf overlay that updates the inetOrgPerson objects with the final groups membership. When modifiying the organization attribute of an inetOrgPerson (and thus triggering an update of groups & membership at the same time), slapd deadlocks. It happens both if the inetOrgPerson gets out of a group, or is now a new member of a group (only showing the tail of the debug log, but i can provide it all): 51bb233b oc_check_required entry (uid=person,ou=people,dc=myorg,dc=fr), objectClass "inetOrgPerson" 51bb233b oc_check_allowed type "cn" 51bb233b oc_check_allowed type "structuralObjectClass" 51bb233b oc_check_allowed type "entryUUID" 51bb233b oc_check_allowed type "creatorsName" 51bb233b oc_check_allowed type "createTimestamp" 51bb233b oc_check_allowed type "objectClass" 51bb233b oc_check_allowed type "uid" 51bb233b oc_check_allowed type "givenName" 51bb233b oc_check_allowed type "sn" 51bb233b oc_check_allowed type "userPassword" 51bb233b oc_check_allowed type "title" 51bb233b oc_check_allowed type "employeeType" 51bb233b oc_check_allowed type "roomNumber" 51bb233b oc_check_allowed type "mail" 51bb233b oc_check_allowed type "telephoneNumber" 51bb233b oc_check_allowed type "memberOf" 51bb233b oc_check_allowed type "o" 51bb233b oc_check_allowed type "entryCSN" 51bb233b oc_check_allowed type "modifyTimestamp" 51bb233b oc_check_allowed type "modifiersName" 51bb233b => entry_encode(0x00000006): 51bb233b <= entry_encode(0x00000006): At that point, there are three active threads in gdb: ^C Program received signal SIGINT, Interrupt. 0x00007ffff5c67e75 in pthread_join () from /lib/x86_64-linux-gnu/libpthread.so.0 (gdb) info thread Id Target Id Frame 3 Thread 0x7ffff0f53700 (LWP 16492) 0x00007ffff5c6b2d4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/x86_64-linux-gnu/libpthread.so.0 2 Thread 0x7ffff1754700 (LWP 16491) 0x00007ffff59b10d3 in epoll_wait () from /lib/x86_64-linux-gnu/libc.so.6 * 1 Thread 0x7ffff7ebb700 (LWP 16490) 0x00007ffff5c67e75 in pthread_join () from /lib/x86_64-linux-gnu/libpthread.so.0 thread 1 & 2 seem okay... (gdb) bt #0 0x00007ffff5c67e75 in pthread_join () from /lib/x86_64-linux-gnu/libpthread.so.0 #1 0x00007ffff7f0fca9 in slapd_daemon () at ../../../../servers/slapd/daemon.c:2930 #2 0x00007ffff7ef687c in main (argc=<optimized out>, argv=<optimized out>) at ../../../../servers/slapd/main.c:1012 (gdb) thread 2 [Switching to thread 2 (Thread 0x7ffff1754700 (LWP 16491))] #0 0x00007ffff59b10d3 in epoll_wait () from /lib/x86_64-linux-gnu/libc.so.6 (gdb) bt #0 0x00007ffff59b10d3 in epoll_wait () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x00007ffff7f0d721 in slapd_daemon_task (ptr=<optimized out>) at ../../../../servers/slapd/daemon.c:2540 #2 0x00007ffff5c66b50 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #3 0x00007ffff59b0a7d in clone () from /lib/x86_64-linux-gnu/libc.so.6 #4 0x0000000000000000 in ?? () but thread 3 seems to lock with himself, maybe trying to modify the same entry via autogroup & memberof at the same time ? (gdb) thread 3 [Switching to thread 3 (Thread 0x7ffff0f53700 (LWP 16492))] #0 0x00007ffff5c6b2d4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/x86_64-linux-gnu/libpthread.so.0 (gdb) bt #0 0x00007ffff5c6b2d4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/x86_64-linux-gnu/libpthread.so.0 #1 0x00007ffff74fe9ab in __db_pthread_mutex_lock () from /usr/lib/x86_64-linux-gnu/libdb-5.1.so #2 0x00007ffff758d5ca in __lock_get_internal () from /usr/lib/x86_64-linux-gnu/libdb-5.1.so #3 0x00007ffff758e9b3 in __lock_vec () from /usr/lib/x86_64-linux-gnu/libdb-5.1.so #4 0x00007ffff758ef18 in __lock_vec_pp () from /usr/lib/x86_64-linux-gnu/libdb-5.1.so #5 0x00007ffff32234a0 in hdb_cache_entry_db_relock (bdb=bdb@entry=0x7ffff83226a0, txn=<optimized out>, ei=0x7ffff82db7b0, rw=rw@entry=1, tryOnly=tryOnly@entry=0, lock=lock@entry=0x7ffff0f4fc70) at cache.c:198 #6 0x00007ffff3223eb3 in hdb_cache_modify (bdb=bdb@entry=0x7ffff83226a0, e=e@entry=0x7ffff85045c8, newAttrs=0x7ffff8517f48, txn=<optimized out>, lock=lock@entry=0x7ffff0f4fc70) at cache.c:1231 #7 0x00007ffff321255a in hdb_modify (op=0x7ffff0f503b0, rs=0x7ffff0f501d0) at modify.c:711 #8 0x00007ffff7f801c6 in overlay_op_walk (op=op@entry=0x7ffff0f503b0, rs=0x7ffff0f501d0, which=op_modify, oi=0x7ffff8325c90, on=0x0) at ../../../../servers/slapd/backover.c:671 #9 0x00007ffff7f8031b in over_op_func (op=0x7ffff0f503b0, rs=<optimized out>, which=<optimized out>) at ../../../../servers/slapd/backover.c:723 #10 0x00007ffff29dabb9 in memberof_value_modify (op=op@entry=0x7ffff0f50d40, ndn=<optimized out>, ad=0x7ffff82d3420, old_dn=old_dn@entry=0x0, old_ndn=old_ndn@entry=0x0, new_dn=new_dn@entry=0x7ffff0f50d68, new_ndn=new_ndn@entry=0x7ffff0f50d78) at ../../../../../servers/slapd/overlays/memberof.c:411 #11 0x00007ffff29db548 in memberof_res_modify (op=0x7ffff0f50d40, rs=<optimized out>) at ../../../../../servers/slapd/overlays/memberof.c:1457 #12 0x00007ffff7f227d6 in slap_response_play (op=op@entry=0x7ffff0f50d40, rs=rs@entry=0x7ffff0f50cd0) at ../../../../servers/slapd/result.c:507 #13 0x00007ffff7f22d6e in send_ldap_response (op=op@entry=0x7ffff0f50d40, rs=rs@entry=0x7ffff0f50cd0) at ../../../../servers/slapd/result.c:582 #14 0x00007ffff7f23816 in slap_send_ldap_result (op=0x7ffff0f50d40, rs=0x7ffff0f50cd0) at ../../../../servers/slapd/result.c:860 #15 0x00007ffff3211e67 in hdb_modify (op=0x7ffff0f50d40, rs=0x7ffff0f50cd0) at modify.c:749 #16 0x00007ffff7f801c6 in overlay_op_walk (op=op@entry=0x7ffff0f50d40, rs=0x7ffff0f50cd0, which=op_modify, oi=0x7ffff8325c90, on=0x0) at ../../../../servers/slapd/backover.c:671 #17 0x00007ffff7f8031b in over_op_func (op=0x7ffff0f50d40, rs=<optimized out>, which=<optimized out>) at ../../../../servers/slapd/backover.c:723 #18 0x00007ffff2be449f in autogroup_add_member_to_group (op=op@entry=0x7ffff82d9ab0, dn=dn@entry=0x7ffff82d9ad8, ndn=ndn@entry=0x7ffff82d9ae8, age=age@entry=0x7ffff82f8ed0) at autogroup.c:146 #19 0x00007ffff2be6aa2 in autogroup_response (op=0x7ffff82d9ab0, rs=<optimized out>) at autogroup.c:1302 #20 0x00007ffff7f7f598 in over_back_response (op=0x7ffff82d9ab0, rs=0x7ffff0f52a50) at ../../../../servers/slapd/backover.c:237 #21 0x00007ffff7f227d6 in slap_response_play (op=op@entry=0x7ffff82d9ab0, rs=rs@entry=0x7ffff0f52a50) at ../../../../servers/slapd/result.c:507 #22 0x00007ffff7f22d6e in send_ldap_response (op=op@entry=0x7ffff82d9ab0, rs=rs@entry=0x7ffff0f52a50) at ../../../../servers/slapd/result.c:582 #23 0x00007ffff7f23816 in slap_send_ldap_result (op=0x7ffff82d9ab0, rs=0x7ffff0f52a50) at ../../../../servers/slapd/result.c:860 #24 0x00007ffff3211e67 in hdb_modify (op=0x7ffff82d9ab0, rs=0x7ffff0f52a50) at modify.c:749 #25 0x00007ffff7f801c6 in overlay_op_walk (op=op@entry=0x7ffff82d9ab0, rs=0x7ffff0f52a50, which=op_modify, oi=0x7ffff8325c90, on=0x0) at ../../../../servers/slapd/backover.c:671 #26 0x00007ffff7f8031b in over_op_func (op=0x7ffff82d9ab0, rs=<optimized out>, which=<optimized out>) at ../../../../servers/slapd/backover.c:723 #27 0x00007ffff7f2a569 in fe_op_modify (op=0x7ffff82d9ab0, rs=0x7ffff0f52a50) at ../../../../servers/slapd/modify.c:303 #28 0x00007ffff7f2c42d in do_modify (op=0x7ffff82d9ab0, rs=0x7ffff0f52a50) at ../../../../servers/slapd/modify.c:177 #29 0x00007ffff7f12961 in connection_operation (ctx=ctx@entry=0x7ffff0f52ba0, arg_v=arg_v@entry=0x7ffff82d9ab0) at ../../../../servers/slapd/connection.c:1150 #30 0x00007ffff7f12c84 in connection_read_thread (ctx=0x7ffff0f52ba0, argv=<optimized out>) at ../../../../servers/slapd/connection.c:1286 #31 0x00007ffff7a73ff3 in ?? () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2 #32 0x00007ffff5c66b50 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #33 0x00007ffff59b0a7d in clone () from /lib/x86_64-linux-gnu/libc.so.6 #34 0x0000000000000000 in ?? () If i examine the three hdb_modify() calls in that trace, the one in #7 and the one in #24 try to work on the same entry (dummy value is the modified inetOrgPerson), and the one in #15 modifies the groupOfNames from which the inetOrgPerson is a new member. I suppose it shouldn't happen... -- Landry Breuil Mouton a 5 pattes du CRAIG

1 0

Re: (ITS#7580) autogroup module blowing slapd when using a labeledURI without attribute specification ?
by h.b.furuseth＠usit.uio.no 13 Jun '13

13 Jun '13

Pushed to master, along with the same change to autogroup_member_search_modify_cb(). -- Hallvard

1 0

Re: (ITS#7580) autogroup module blowing slapd when using a labeledURI without attribute specification ?
by breuil＠craig.fr 13 Jun '13

13 Jun '13

With help from hbf on #openldap on irc, managed to track this down to autogroup.c:autogroup_member_search_cb(). https://github.com/benegon/openldap/blob/master/contrib/slapd-modules/autog… In my usecase with labeledURI: ldap:///ou=people,dc=example,dc=org??one?(&(objectClass=inetOrgPerson)(o=myorg)) agf->agf_anlist is NULL since no attributes were specified, and the else branch is taken. In that branch, the e_name & e_nname from rs->sr_entry are assigned to lvals[0] & lnvals[0], and those two structs are local to the else branch. Later on, they assigned to vals & nvals, but when you get out of the else branch they're not in the scope anymore -> mod.sm_values & mod.sm_nvalues potentially get garbage. Declaring lvals & lnvals arrays outside of the branch (ie at the same spot as vals & nvals) fixes the assert for me, tested on debian sid with rebuilt 2.4.31 packages, but the fix should probably be the same for git master. Inline patch fixing the issue (probably mangled in the output....) diff --git a/contrib/slapd-modules/autogroup/autogroup.c b/contrib/slapd-modules/autogroup/autogroup.c index 06e1407..091a42f 100644 --- a/contrib/slapd-modules/autogroup/autogroup.c +++ b/contrib/slapd-modules/autogroup/autogroup.c @@ -331,6 +331,7 @@ autogroup_member_search_cb( Operation *op, SlapReply *rs ) const char *text = NULL; char textbuf[1024]; struct berval *vals, *nvals; + struct berval lvals[ 2 ], lnvals[ 2 ]; int numvals; Debug(LDAP_DEBUG_TRACE, "==> autogroup_member_search_cb <%s>\n", @@ -347,7 +348,6 @@ autogroup_member_search_cb( Operation *op, SlapReply *rs ) return 0; } } else { - struct berval lvals[ 2 ], lnvals[ 2 ]; lvals[ 0 ] = rs->sr_entry->e_name; BER_BVZERO( &lvals[ 1 ] ); lnvals[ 0 ] = rs->sr_entry->e_nname; -- Landry Breuil

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs