openldap-bugs July 2017

openldap-bugs@openldap.org

22 participants
41 discussions

Re: (ITS#8692) back-sock does not create LDAP_MOD_INCREMENT message (unsigned)
by michael＠stroeder.com 12 Jul '17

12 Jul '17

(Re-sent without S/MIME sign. for better readability in ITS) This seems really trivial to fix - even for me. ;-) I've successfully tested it with Python module slapdsock (and ldif module in python-ldap 2.4.41+). I, Michael Ströder, 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. https://www.stroeder.com/temp/0001-ITS-8692-let-back-sock-generate-incremen… --------------------------------------------------------------------------------------- >From 6c37844c5c52b95aff5e4e547cda8a7258e92a35 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Michael=20Str=C3=B6der?= <michael(a)stroeder.com> Date: Wed, 12 Jul 2017 20:18:22 +0200 Subject: [PATCH] ITS#8692 let back-sock generate increment: line in case of LDAP_MOD_INCREMENT (see RFC 4525, section 3) --- servers/slapd/back-sock/modify.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/servers/slapd/back-sock/modify.c b/servers/slapd/back-sock/modify.c index c35d31bc6..9342d2702 100644 --- a/servers/slapd/back-sock/modify.c +++ b/servers/slapd/back-sock/modify.c @@ -85,6 +85,10 @@ sock_back_modify( case LDAP_MOD_REPLACE: fprintf( fp, "replace: %s\n", mod->sm_desc->ad_cname.bv_val ); break; + + case LDAP_MOD_INCREMENT: + fprintf( fp, "increment: %s\n", mod->sm_desc->ad_cname.bv_val ); + break; } if( mod->sm_values != NULL ) { -- 2.13.2

1 0

Re: (ITS#8692) back-sock does not create LDAP_MOD_INCREMENT message
by michael＠stroeder.com 12 Jul '17

12 Jul '17

This is a cryptographically signed message in MIME format. --------------ms070903000906000403080407 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable This seems really trivial to fix - even for me. ;-) I've successfully tested it with Python module slapdsock (and ldif module= in python-ldap 2.4.41+). I, Michael Str=C3=B6der, hereby place the following modifications to Open= LDAP Software (and only these modifications) into the public domain. Hence, these modificati= ons may be freely used and/or redistributed for any purpose with or without attribut= ion and/or other notice. https://www.stroeder.com/temp/0001-ITS-8692-let-back-sock-generate-increm= ent-line.patch -------------------------------------------------------------------------= -------------- =46rom 6c37844c5c52b95aff5e4e547cda8a7258e92a35 Mon Sep 17 00:00:00 2001 From: =3D?UTF-8?q?Michael=3D20Str=3DC3=3DB6der?=3D <michael(a)stroeder.com>= Date: Wed, 12 Jul 2017 20:18:22 +0200 Subject: [PATCH] ITS#8692 let back-sock generate increment: line in case = of LDAP_MOD_INCREMENT (see RFC 4525, section 3) --- servers/slapd/back-sock/modify.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/servers/slapd/back-sock/modify.c b/servers/slapd/back-sock/m= odify.c index c35d31bc6..9342d2702 100644 --- a/servers/slapd/back-sock/modify.c +++ b/servers/slapd/back-sock/modify.c @@ -85,6 +85,10 @@ sock_back_modify( case LDAP_MOD_REPLACE: fprintf( fp, "replace: %s\n", mod->sm_desc->ad_cname.bv_val ); break; + + case LDAP_MOD_INCREMENT: + fprintf( fp, "increment: %s\n", mod->sm_desc->ad_cname.bv_val ); + break; } if( mod->sm_values !=3D NULL ) { --=20 2.13.2 --------------ms070903000906000403080407 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CucwggT9MIID5aADAgECAhBFRleVrRF8X5GwbV0tcLCgMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwOTE2MDcxNjUxWhcNMTkxMjE2MDcxNjUxWjBEMR0wGwYDVQQDDBRtaWNo YWVsQHN0cm9lZGVyLmNvbTEjMCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20w ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQChMBt5jtuLXsNQ5U7rBbZit8sknIwz hfaousT3d/fssQ6qZwe9l1yklILSXVMqI7/bxbiqcd3zrz+imdSlZPrFBHGfh04DZHCfss2F RwSswGejqP1qE3hPvZi96wFfOMqenpN+pSXqNJ1OPBCJ8a+8ZEioFKoEj3HkCCXjbmezAgms FuA7aFE9BfjJ2eQKw8B9G8X1FjvOTinYSZ2F+qHpKgywl4HTx0dMnYy+Pwu4DDIHkEaVH+uj K1/ed76WUEH51mX9m2Xu0onfQlSM3me6EvAAZiIDsCEbF9WttRuJbpfCFo0m2uW7BBugS7EG Jro1nRSQVnpJyTFgHb5EGMVVAgMBAAGjggG4MIIBtDAOBgNVHQ8BAf8EBAMCBLAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYDVR0OBBYEFFh1801TSuxT Nltnv9rOjrZzUUgNMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUnSG1oMG8GCCsGAQUF BwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDkGCCsGAQUF BzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5jcnQwOAYD VR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEuY3Js MB8GA1UdEQQYMBaBFG1pY2hhZWxAc3Ryb2VkZXIuY29tMCMGA1UdEgQcMBqGGGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tLzBHBgNVHSAEQDA+MDwGCysGAQQBgbU3AQIFMC0wKwYIKwYBBQUH AgEWH2h0dHBzOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kwDQYJKoZIhvcNAQELBQADggEB AKiJ9wpjJeHdEzHDZyqmhn4cHcRj9Ag7ZQK0meq1N3oQ9M1YeVge6vZe20LXojgXsNUQGLSt 1lW2s7fABkL9CF+/RtWznHxlp4YpWX/RgbHBo3uXKNA5JUOjbxQ2+1b1jaTp/FUrSIISAxgd RpeYAODJ0db1x8Q+l66DtIVjj7ktWISdJWE2Opn4QnaRwdj6n35Rul4S2ikUsmxtGrHLpjRR XJqbsGa0RZdJyUKlZ2ZRAoRz4jKHOogQcig937sR5Ut2pGOhrScEhgARY2c8Gs2olRTL3pue mE4vjY0g1Nwr9RzeFwMuasiFh4yD34i6jIRfoNzuLPgydjsJ0grw0akwggXiMIIDyqADAgEC AhBrp4p9CteI1lEK+Vnk57ThMA0GCSqGSIb3DQEBCwUAMH0xCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe Fw0xNTEyMTYwMTAwMDVaFw0zMDEyMTYwMTAwMDVaMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQC9fdr3w6J9g/Zbgv3bW1+uHht1wLUZr5gkrLtXedg17Ake fMyUGwrQdvwObhajcVmnKVxhrUwkZPXRAwZZosRHfEIi5FH7x6SV/8Sp5lZEuiMnvMFG2MzL A84J6Ws5T4NfXZ0qn4TPgnr3X2vPVS51M7Ua9nIJgn8jvTra4eyyQzxvuA/GZwKg7VQfDCmC S+kICslYYWgXOMt2xlsSslxLce0CGWRsT8EpMyt1iDflSjXZIsE7m1uTyHaKZspMLyIyz6my Su8j8BWWHpChNNeTrFuhVfrOAyDPFJVUvKZCLKBhibTLloyy+LatoWELrjdI4a8StZY8+dIR 9t4APXGzAgMBAAGjggFkMIIBYDAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0lBBYwFAYIKwYBBQUH AwIGCCsGAQUFBwMEMBIGA1UdEwEB/wQIMAYBAf8CAQAwMgYDVR0fBCswKTAnoCWgI4YhaHR0 cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMGYGCCsGAQUFBwEBBFowWDAkBggrBgEF BQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDAGCCsGAQUFBzAChiRodHRwOi8vYWlh LnN0YXJ0c3NsLmNvbS9jZXJ0cy9jYS5jcnQwHQYDVR0OBBYEFCSBbDlhvkkPj7cbRivJKLUn SG1oMB8GA1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7yMD8GA1UdIAQ4MDYwNAYEVR0g ADAsMCoGCCsGAQUFBwIBFh5odHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kwDQYJKoZI hvcNAQELBQADggIBAIvj94fsAYuErQ8BAluc4SMnIwS9NPBwAm5SH9uh2NCXTq7im61g7F1L IiNI/+wq37fUuaMbz4g7VarKQTgf8ubs0p7NZWcIe7Bvem2AWaXBsxsaRTYw5kG3DN8pd1hS EUuFoTa7DmNeFe8tiK1BrL3rbA/m48jp4AiFXgvxprJrW7izsyetOrRHPbkW4Y07v29MdhaP v3u1JELyszXqOzjIYo4sWlC8iDQXwgSW/ntvWy2n4LuiaozlCfXl149tKeqvwlvrla2Yklue /quWp9j9ou4T/OY0CXMuY+B8wNK0ohd2D4ShgFlMSjzAFRoHGKF81snTr2d1A7Ew02oF6UQy CkC2aNNsK5cWOojBar5c7HplX9aHYUCZouxIeU28SONJAxnATgR4cJ2jrpmYSz/kliUJ46S6 UpVDo/ebn9c6PaM/XtDYCCaM/7XX6wc3s++sbQ7CtCn1Ax7df6ufQbwyO0V+oFa9H0KAsjHM zcwk3EV2B2NLatidKE/m7G+rB9m+FlVgIiSp0mGlg43QO9Kh1+JqvTCIzv2bJJkmPMLQJNuK KwHNL8F4GGp6jbAV+WL+LDeGfVcq8DHS3LrD+xyYEXQBiqZEdiPVOMxLDSUCXsDO0uCWpaNQ 8j6y6S9p0xE/Ga0peVLadVHhqf9nXqKaxnr358VgfrxzUIrvOaOjMYIDzDCCA8gCAQEwgYkw dTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAx IENsaWVudCBDQQIQRUZXla0RfF+RsG1dLXCwoDANBglghkgBZQMEAgEFAKCCAhMwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwNzEyMTkzOTAzWjAvBgkq hkiG9w0BCQQxIgQgnqI1DvtHUweHIV0AnS/gA0/OrfIjpb0PVNDvi75eNPIwbAYJKoZIhvcN AQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBmgYJKwYB BAGCNxAEMYGMMIGJMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkw JwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3Rh cnRDb20gQ2xhc3MgMSBDbGllbnQgQ0ECEEVGV5WtEXxfkbBtXS1wsKAwgZwGCyqGSIb3DQEJ EAILMYGMoIGJMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYD VQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRD b20gQ2xhc3MgMSBDbGllbnQgQ0ECEEVGV5WtEXxfkbBtXS1wsKAwDQYJKoZIhvcNAQEBBQAE ggEAhXv2pTJgL9mLTUlPradGexdRjNYJdGGamEarwi2KXfmhcc4KDuZJvmWE8hF81lkjvgdU +3UOC9jWqG90NHexCexcswnHkQ0igrc8KYUFQhgAFsWOMsCkAmnzu02zQcgcIIJDarbOOCKG 0tZZ+1FzXeqB3ii1Uj9NJv6Sv/BgmJGU0XivlL9QAMtMylbJJnlBDeoqKC3Ti7PgJDkn0VuP gvR20a732AM4eZyzreKhg0qx6Tiaaw6vSYcFxsaffsKL5s3GuRx5uPUnDINGnbCFA1OVi+BA dq1819pvcrAmpYDvgMXgI+Mo/alvPLRzDn2pDdt8G7IBG7/UkFtvI7UDFwAAAAAAAA== --------------ms070903000906000403080407--

1 0

(ITS#8692) back-sock does not create LDAP_MOD_INCREMENT message
by michael＠stroeder.com 12 Jul '17

12 Jul '17

Full_Name: Version: OS: URL: Submission from: (NULL) (85.115.23.42) back-sock does not generate a MODIFY message with "increment:" line when LDAP clients sends modify operation with LDAP_MOD_INCREMENT. Example of incomplete message (incrementing attribute gidNumber): ----------------------------- snip ----------------------------- MODIFY msgid: 119 binddn: uid=msin,cn=ae,ou=ae-dir peername: PATH=/usr/local/openldap/var/run/ldapi ssf: 256 connid: 1025 suffix: ou=ae-dir dn: ou=ae-dir gidNumber: 1 - ----------------------------- snip -----------------------------

1 0

Re: (ITS#8690) syncprov memory leak
by quanah＠symas.com 11 Jul '17

11 Jul '17

--On Tuesday, July 11, 2017 1:25 AM +0000 quanah(a)openldap.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.45 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (47.208.148.239) Better trace: ==1504== 20,123 bytes in 67 blocks are definitely lost in loss record 40 of 41 ==1504== at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==1504== by 0x50A8BA5: ber_memalloc_x (/home/build/git/sold-2445/openldap/libraries/liblber/memory.c:228) ==1504== by 0x464A88: ch_malloc (/home/build/git/sold-2445/openldap/servers/slapd/ch_malloc.c:54) ==1504== by 0x962B849: syncprov_qresp (/home/build/git/sold-2445/openldap/servers/slapd/overlays/syncprov.c:1062) ==1504== by 0x962F22C: syncprov_op_response (/home/build/git/sold-2445/openldap/servers/slapd/overlays/syncprov.c:1982) ==1504== by 0x454227: slap_response_play (/home/build/git/sold-2445/openldap/servers/slapd/result.c:521) ==1504== by 0x45449A: send_ldap_response (/home/build/git/sold-2445/openldap/servers/slapd/result.c:596) ==1504== by 0x455509: slap_send_ldap_result (/home/build/git/sold-2445/openldap/servers/slapd/result.c:891) ==1504== by 0x984BBEF: bdb_delete (/home/build/git/sold-2445/openldap/servers/slapd/back-bdb/delete.c:596) ==1504== by 0x4D9968: overlay_op_walk (/home/build/git/sold-2445/openldap/servers/slapd/backover.c:677) ==1504== by 0x4D9BBA: over_op_func (/home/build/git/sold-2445/openldap/servers/slapd/backover.c:730) ==1504== by 0x4D9D9B: over_op_delete (/home/build/git/sold-2445/openldap/servers/slapd/backover.c:787) ==1504== by 0x4623FF: fe_op_delete (/home/build/git/sold-2445/openldap/servers/slapd/delete.c:174) ==1504== by 0x462037: do_delete (/home/build/git/sold-2445/openldap/servers/slapd/delete.c:95) ==1504== by 0x43D4E4: connection_operation (/home/build/git/sold-2445/openldap/servers/slapd/connection.c:1158) ==1504== by 0x4E4C6C8: ldap_int_thread_pool_wrapper (/home/build/git/sold-2445/openldap/libraries/libldap_r/tpool.c:963) ==1504== by 0x52B76B9: start_thread (/build/glibc-bfm8X4/glibc-2.23/nptl/pthread_create.c:333) ==1504== ==1504== 220,540 bytes in 734 blocks are definitely lost in loss record 41 of 41 ==1504== at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==1504== by 0x50A8BA5: ber_memalloc_x (/home/build/git/sold-2445/openldap/libraries/liblber/memory.c:228) ==1504== by 0x464A88: ch_malloc (/home/build/git/sold-2445/openldap/servers/slapd/ch_malloc.c:54) ==1504== by 0x962B849: syncprov_qresp (/home/build/git/sold-2445/openldap/servers/slapd/overlays/syncprov.c:1062) ==1504== by 0x962F22C: syncprov_op_response (/home/build/git/sold-2445/openldap/servers/slapd/overlays/syncprov.c:1982) ==1504== by 0x454227: slap_response_play (/home/build/git/sold-2445/openldap/servers/slapd/result.c:521) ==1504== by 0x45449A: send_ldap_response (/home/build/git/sold-2445/openldap/servers/slapd/result.c:596) ==1504== by 0x455509: slap_send_ldap_result (/home/build/git/sold-2445/openldap/servers/slapd/result.c:891) ==1504== by 0x984BBEF: bdb_delete (/home/build/git/sold-2445/openldap/servers/slapd/back-bdb/delete.c:596) ==1504== by 0x4D9968: overlay_op_walk (/home/build/git/sold-2445/openldap/servers/slapd/backover.c:677) ==1504== by 0x4D9BBA: over_op_func (/home/build/git/sold-2445/openldap/servers/slapd/backover.c:730) ==1504== by 0x4D9D9B: over_op_delete (/home/build/git/sold-2445/openldap/servers/slapd/backover.c:787) ==1504== by 0x4623FF: fe_op_delete (/home/build/git/sold-2445/openldap/servers/slapd/delete.c:174) ==1504== by 0x462037: do_delete (/home/build/git/sold-2445/openldap/servers/slapd/delete.c:95) ==1504== by 0x43D4E4: connection_operation (/home/build/git/sold-2445/openldap/servers/slapd/connection.c:1158) ==1504== by 0x43DB8A: connection_read_thread (/home/build/git/sold-2445/openldap/servers/slapd/connection.c:1294) ==1504== by 0x4E4C6C8: ldap_int_thread_pool_wrapper (/home/build/git/sold-2445/openldap/libraries/libldap_r/tpool.c:963) ==1504== by 0x52B76B9: start_thread (/build/glibc-bfm8X4/glibc-2.23/nptl/pthread_create.c:333) ==1504== --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#8691) slapd crashes during shutdown
by derrick.mckee＠gmail.com 11 Jul '17

11 Jul '17

Full_Name: Derrick McKee Version: OPENLDAP_REL_ENG_2_4_45 OS: Windows URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2404:f801:8028:1::17f) Compiling OpenLDAP using clang on Windows with MinGW results in a binary that crashes during shutdown. The issue is with mdb_txn_abort in libraries/liblmdb/mdb.c. The initial txn does have a non-null child, however, the address is a garbage address (i.e. containing a mix of 1 and 0 bits set in the upper 16 bits in a 64-bit pointer). This seems to indicate that somewhere the code is expecting a 0 initialized memory area, when it isn't. How to recreate: CC=clang CFLAGS="-m64" ./configure --without-threads --without-tls make depend && make (using CMD.exe) ./servers/slapd/slapd <user hits Ctrl-c>

1 0

(ITS#8690) syncprov memory leak
by quanah＠openldap.org 10 Jul '17

10 Jul '17

Full_Name: Quanah Gibson-Mount Version: 2.4.45 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.148.239) Setting up a 2-node MMR pair, using standard syncrepl in refreshAndPersist mode, shows there is a steady leak in syncprov on the master receiving write traffic. Output from mleak: Memory leaks (498370 total): Leak, blocks, size: 0x7f2910103d80,933,280319 ber_memalloc_x (memory.c:228) stack: libgcc_s.so.1 : ?? (<unknown_file>:0) libgcc_s.so.1 : ?? (<unknown_file>:0) slapd : slap_response_play (result.c:521) slapd : send_ldap_response (result.c:596) slapd : slap_send_ldap_result (result.c:891) libgcc_s.so.1 : ?? (<unknown_file>:0) slapd : overlay_op_walk (backover.c:677) slapd : over_op_func (backover.c:730) slapd : over_op_delete (backover.c:788) slapd : fe_op_delete (delete.c:176) slapd : do_delete (delete.c:95) slapd : connection_operation (connection.c:1158) slapd : connection_read_thread (connection.c:1294) libldap_r-2.4.so.2 : ldap_int_thread_pool_wrapper (tpool.c:965) libpthread.so.0 : start_thread (??:0) libc.so.6 : ?? (<unknown_file>:0) Leak, blocks, size: 0x7f29101015b0,671,201605 ber_memalloc_x (memory.c:228) stack: libgcc_s.so.1 : ?? (<unknown_file>:0) libgcc_s.so.1 : ?? (<unknown_file>:0) slapd : slap_response_play (result.c:521) slapd : send_ldap_response (result.c:596) slapd : slap_send_ldap_result (result.c:891) libgcc_s.so.1 : ?? (<unknown_file>:0) slapd : overlay_op_walk (backover.c:677) slapd : over_op_func (backover.c:730) slapd : over_op_delete (backover.c:788) slapd : fe_op_delete (delete.c:176) slapd : do_delete (delete.c:95) slapd : connection_operation (connection.c:1158) libldap_r-2.4.so.2 : ldap_int_thread_pool_wrapper (tpool.c:965) libpthread.so.0 : start_thread (??:0) libc.so.6 : ?? (<unknown_file>:0) Leak, blocks, size: 0xd648a0,1,1560 realloc (mleak.c:293) stack: libc.so.6 : ?? (<unknown_file>:0) slapd : slap_get_listener_addresses (daemon.c:1179) slapd : slap_open_listener (daemon.c:1362) slapd : slapd_daemon_init (daemon.c:1682) slapd : main (main.c:740) libc.so.6 : ?? (<unknown_file>:0) slapd : _start (??:0) Output from valgrind: ==3926== 79,998 bytes in 266 blocks are definitely lost in loss record 20 of 21 ==3926== at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==3926== by 0x50A8BA5: ber_memalloc_x (/home/build/git/sold-2445/openldap/libraries/liblber/memory.c:228) ==3926== by 0x464AC8: ch_malloc (/home/build/git/sold-2445/openldap/servers/slapd/ch_malloc.c:54) ==3926== by 0x962B7D1: ??? ==3926== by 0x962F1B4: ??? ==3926== by 0x454267: slap_response_play (/home/build/git/sold-2445/openldap/servers/slapd/result.c:521) ==3926== by 0x4544DA: send_ldap_response (/home/build/git/sold-2445/openldap/servers/slapd/result.c:596) ==3926== by 0x455549: slap_send_ldap_result (/home/build/git/sold-2445/openldap/servers/slapd/result.c:891) ==3926== by 0x984BBEF: ??? ==3926== by 0x4D9A4B: overlay_op_walk (/home/build/git/sold-2445/openldap/servers/slapd/backover.c:677) ==3926== by 0x4D9C9D: over_op_func (/home/build/git/sold-2445/openldap/servers/slapd/backover.c:730) ==3926== by 0x4D9E7E: over_op_delete (/home/build/git/sold-2445/openldap/servers/slapd/backover.c:787) ==3926== by 0x46243F: fe_op_delete (/home/build/git/sold-2445/openldap/servers/slapd/delete.c:174) ==3926== by 0x462077: do_delete (/home/build/git/sold-2445/openldap/servers/slapd/delete.c:95) ==3926== by 0x43D524: connection_operation (/home/build/git/sold-2445/openldap/servers/slapd/connection.c:1158) ==3926== by 0x4E4C6C8: ldap_int_thread_pool_wrapper (/home/build/git/sold-2445/openldap/libraries/libldap_r/tpool.c:963) ==3926== by 0x52B76B9: start_thread (/build/glibc-bfm8X4/glibc-2.23/nptl/pthread_create.c:333) ==3926== ==3926== 401,025 bytes in 1,335 blocks are definitely lost in loss record 21 of 21 ==3926== at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==3926== by 0x50A8BA5: ber_memalloc_x (/home/build/git/sold-2445/openldap/libraries/liblber/memory.c:228) ==3926== by 0x464AC8: ch_malloc (/home/build/git/sold-2445/openldap/servers/slapd/ch_malloc.c:54) ==3926== by 0x962B7D1: ??? ==3926== by 0x962F1B4: ??? ==3926== by 0x454267: slap_response_play (/home/build/git/sold-2445/openldap/servers/slapd/result.c:521) ==3926== by 0x4544DA: send_ldap_response (/home/build/git/sold-2445/openldap/servers/slapd/result.c:596) ==3926== by 0x455549: slap_send_ldap_result (/home/build/git/sold-2445/openldap/servers/slapd/result.c:891) ==3926== by 0x984BBEF: ??? ==3926== by 0x4D9A4B: overlay_op_walk (/home/build/git/sold-2445/openldap/servers/slapd/backover.c:677) ==3926== by 0x4D9C9D: over_op_func (/home/build/git/sold-2445/openldap/servers/slapd/backover.c:730) ==3926== by 0x4D9E7E: over_op_delete (/home/build/git/sold-2445/openldap/servers/slapd/backover.c:787) ==3926== by 0x46243F: fe_op_delete (/home/build/git/sold-2445/openldap/servers/slapd/delete.c:174) ==3926== by 0x462077: do_delete (/home/build/git/sold-2445/openldap/servers/slapd/delete.c:95) ==3926== by 0x43D524: connection_operation (/home/build/git/sold-2445/openldap/servers/slapd/connection.c:1158) ==3926== by 0x43DBCA: connection_read_thread (/home/build/git/sold-2445/openldap/servers/slapd/connection.c:1294) ==3926== by 0x4E4C6C8: ldap_int_thread_pool_wrapper (/home/build/git/sold-2445/openldap/libraries/libldap_r/tpool.c:963) ==3926== by 0x52B76B9: start_thread (/build/glibc-bfm8X4/glibc-2.23/nptl/pthread_create.c:333) ==3926==

1 0

(ITS#8689) invalid rwm configuration causes slapd to SEGV
by quanah＠openldap.org 10 Jul '17

10 Jul '17

Full_Name: Quanah Gibson-Mount Version: 2.4.45 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.148.239) If you incorrectly configure slapo-rwm so that it has an invalid mapping, slapd will crash after a search is performed against the mapped base. For example: rwm-rewriteRule "(.+,)?dc=example2,[ ]?dc=com$" "$1dc-example, dc=com" rwm-rewriteRule "(.+,)?dc=example2,dc=com$" "$1dc-example,dc=com" (note that it has dc-example,dc=com instead of dc=example,dc=com) It might be helpful? to parse the rewrite rules for validity, but that may be difficult to do. Thread 4 "slapd" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fcd66999700 (LWP 844)] slap_sl_free (ptr=0x7fcd5c001178, ctx=0x7fcd5c000a80) at /home/build/sold-2.4.45.1/openldap/servers/slapd/sl_malloc.c:515 515 /home/build/sold-2.4.45.1/openldap/servers/slapd/sl_malloc.c: No such file or directory. (gdb) bt #0 slap_sl_free (ptr=0x7fcd5c001178, ctx=0x7fcd5c000a80) at /home/build/sold-2.4.45.1/openldap/servers/slapd/sl_malloc.c:515 #1 0x0000000000431c03 in do_search (op=0x7fcd580028d0, rs=0x7fcd66998b10) at /home/build/sold-2.4.45.1/openldap/servers/slapd/search.c:257 #2 0x000000000042ff77 in connection_operation (ctx=0x7fcd66998c00, arg_v=0x7fcd580028d0) at /home/build/sold-2.4.45.1/openldap/servers/slapd/connection.c:1158 #3 0x00007fcdac4fc3bb in ldap_int_thread_pool_wrapper (xpool=0x26e6fc0) at /home/build/sold-2.4.45.1/openldap/libraries/libldap_r/tpool.c:963 #4 0x00007fcdac0c56ba in start_thread (arg=0x7fcd66999700) at pthread_create.c:333 #5 0x00007fcdab1283dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 Thread 4 (Thread 0x7fcd66999700 (LWP 844)): #0 slap_sl_free (ptr=0x7fcd5c001178, ctx=0x7fcd5c000a80) at /home/build/sold-2.4.45.1/openldap/servers/slapd/sl_malloc.c:515 nextp = 0x6520e534bd7384d0 size = 7286935691776455520 p = 0x7fcd5c001170 tmpp = <optimized out> ctx = 0x7fcd5c000a80 ptr = 0x7fcd5c001178 sh = 0x7fcd5c000a80 p = 0x7fcd5c001178 #1 0x0000000000431c03 in do_search (op=0x7fcd580028d0, rs=0x7fcd66998b10) at /home/build/sold-2.4.45.1/openldap/servers/slapd/search.c:257 base = {bv_len = 18, bv_val = 0x7fcd58000a87 "dc=example2,dc=com"} siz = 0 off = <optimized out> i = <optimized out> #2 0x000000000042ff77 in connection_operation (ctx=0x7fcd66998c00, arg_v=0x7fcd580028d0) at /home/build/sold-2.4.45.1/openldap/servers/slapd/connection.c:1158 rc = 80 cancel = <optimized out> op = 0x7fcd580028d0 rs = {sr_type = REP_RESULT, sr_tag = 101, sr_msgid = 2, sr_err = -1, sr_matched = 0x0, sr_text = 0x7fcda7ba945d "searchDN massage error", sr_ref = 0x0, sr_ctrls = 0x0, sr_un = { sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}, sru_sasl = {r_sasldata = 0x0}, sru_extended = { r_rspoid = 0x0, r_rspdata = 0x0}}, sr_flags = 0} tag = 99 opidx = SLAP_OP_SEARCH conn = 0x7fcdac7e5b90 memctx = 0x7fcd5c000a80 memctx_null = 0x0 memsiz = 1048576 __PRETTY_FUNCTION__ = "connection_operation" #3 0x00007fcdac4fc3bb in ldap_int_thread_pool_wrapper (xpool=0x26e6fc0) at /home/build/sold-2.4.45.1/openldap/libraries/libldap_r/tpool.c:963 pq = 0x26e6fc0 pool = 0x26e6ee0 task = 0x7fcd600008c0 work_list = <optimized out> ctx = {ltu_pq = 0x26e6fc0, ltu_id = 140520166364928, ltu_key = {{ltk_key = 0x42e3a0 <conn_counter_init>, ltk_data = 0x7fcd5c000970, ltk_free = 0x42e480 <conn_counter_destroy>}, { ltk_key = 0x484c30 <slap_sl_mem_init>, ltk_data = 0x7fcd5c000a80, ltk_free = 0x484b00 <slap_sl_mem_destroy>}, {ltk_key = 0x4436d0 <slap_op_free>, ltk_data = 0x7fcd5c000b70, ltk_free = 0x4436a0 <slap_op_q_destroy>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0x0} <repeats 29 times>}} kctx = <optimized out> keyslot = <optimized out> hash = <optimized out> pool_lock = 0 freeme = 0 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #4 0x00007fcdac0c56ba in start_thread (arg=0x7fcd66999700) at pthread_create.c:333 __res = <optimized out> pd = 0x7fcd66999700 now = <optimized out> unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140520166364928, 1493515270220219122, 0, 140520183139599, 140520166365632, 4391152, -1503985625800834318, -1503832697886014734}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = <optimized out> pagesize_m1 = <optimized out> sp = <optimized out> freesize = <optimized out> __PRETTY_FUNCTION__ = "start_thread" #5 0x00007fcdab1283dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 No locals. Thread 3 (Thread 0x7fcd6719a700 (LWP 843)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 No locals. #1 0x00007fcdac4fcc65 in ldap_pvt_thread_cond_wait (cond=<optimized out>, mutex=<optimized out>) at /home/build/sold-2.4.45.1/openldap/libraries/libldap_r/thr_posix.c:277 No locals. #2 0x00007fcdac4fc45f in ldap_int_thread_pool_wrapper (xpool=0x26e6fc0) at /home/build/sold-2.4.45.1/openldap/libraries/libldap_r/tpool.c:945 pq = 0x26e6fc0 pool = 0x26e6ee0 task = 0x0 work_list = <optimized out> ctx = {ltu_pq = 0x26e6fc0, ltu_id = 140520174757632, ltu_key = {{ltk_key = 0x42e3a0 <conn_counter_init>, ltk_data = 0x7fcd580026a0, ltk_free = 0x42e480 <conn_counter_destroy>}, { ltk_key = 0x484c30 <slap_sl_mem_init>, ltk_data = 0x7fcd580027b0, ltk_free = 0x484b00 <slap_sl_mem_destroy>}, {ltk_key = 0x4436d0 <slap_op_free>, ltk_data = 0x7fcd58002d10, ltk_free = 0x4436a0 <slap_op_q_destroy>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0x0} <repeats 29 times>}} kctx = <optimized out> keyslot = <optimized out> hash = <optimized out> pool_lock = 0 freeme = 0 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #3 0x00007fcdac0c56ba in start_thread (arg=0x7fcd6719a700) at pthread_create.c:333 __res = <optimized out> pd = 0x7fcd6719a700 now = <optimized out> unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140520174757632, 1493515270220219122, 0, 140520183139647, 140520174758336, 4370320, -1503984526826077454, -1503832697886014734}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = <optimized out> pagesize_m1 = <optimized out> sp = <optimized out> freesize = <optimized out> __PRETTY_FUNCTION__ = "start_thread" #4 0x00007fcdab1283dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 No locals. Thread 2 (Thread 0x7fcd6799b700 (LWP 804)): #0 0x00007fcdab1289d3 in epoll_wait () at ../sysdeps/unix/syscall-template.S:84 No locals. #1 0x000000000042b7c0 in slapd_daemon_task (ptr=<optimized out>) at /home/build/sold-2.4.45.1/openldap/servers/slapd/daemon.c:2539 ns = <optimized out> at = <optimized out> nfds = <optimized out> revents = 0x26c0ff0 tvp = 0x0 cat = {tv_sec = 0, tv_usec = 0} i = <optimized out> nwriters = <optimized out> now = <optimized out> tv = {tv_sec = 0, tv_usec = 0} tdelta = 1 rtask = <optimized out> l = <optimized out> last_idle_check = 1499703215 ebadf = 0 tid = 0 #2 0x00007fcdac0c56ba in start_thread (arg=0x7fcd6799b700) at pthread_create.c:333 __res = <optimized out> pd = 0x7fcd6799b700 now = <optimized out> unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140520183150336, 1493515270220219122, 0, 140735119107759, 140520183151040, 0, -1503983425703836942, -1503832697886014734}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = <optimized out> pagesize_m1 = <optimized out> sp = <optimized out> freesize = <optimized out> __PRETTY_FUNCTION__ = "start_thread" #3 0x00007fcdab1283dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 No locals. Thread 1 (Thread 0x7fcdac957700 (LWP 803)): #0 0x00007fcdac0c698d in pthread_join (threadid=140520183150336, thread_return=thread_return@entry=0x0) at pthread_join.c:90 __tid = 804 _buffer = {__routine = 0x7fcdac0c68b0 <cleanup>, __arg = 0x7fcd6799bd28, __canceltype = 0, __prev = 0x0} oldtype = 0 pd = 0x7fcd6799b700 self = 0x7fcdac957700 result = 0 #1 0x00007fcdac4fcbf5 in ldap_pvt_thread_join (thread=<optimized out>, thread_return=thread_return@entry=0x0) at /home/build/sold-2.4.45.1/openldap/libraries/libldap_r/thr_posix.c:197 No locals. #2 0x000000000042d529 in slapd_daemon () at /home/build/sold-2.4.45.1/openldap/servers/slapd/daemon.c:2932 i = 0 rc = 0 #3 0x0000000000415261 in main (argc=7, argv=<optimized out>) at /home/build/sold-2.4.45.1/openldap/servers/slapd/main.c:1016 i = <optimized out> no_detach = 0 urls = 0x26ae0d0 "ldap:///" username = 0x26ae090 "EXTERNAL" groupname = 0x26ae0b0 "\006\362\032\253\315\177" sandbox = 0x0 syslogUser = 160 pid = <optimized out> waitfds = {9, 10} g_argc = 7 g_argv = <optimized out> configfile = 0x0 configdir = 0x0 serverName = 0x7fff72c838fe "slapd" scp = <optimized out> scp_entry = <optimized out> debug_unknowns = 0x0 syslog_unknowns = 0x0 serverNamePrefix = <synthetic pointer> l = <optimized out> slapd_pid_file_unlink = 1 slapd_args_file_unlink = 1 firstopt = <optimized out> __PRETTY_FUNCTION__ = "main"

1 0

(ITS#8686)
by yoshiho.yoshida＠synacor.com 10 Jul '17

10 Jul '17

I reported the caluculation of the size of original and normalized rdn is as follows. > len_rdn is the size of original rdn. > len_norm_rdn is the size of normalized rdn. > > ((3 + len_norm_rdn) * 3) less than equal to ((3 + len_norm_rdn) + 1 + len_rdn + 1 + 8) But after the test about verious sizes of rdn, the above calculation does not cover the all cases and the next simple calculation should match more verious sizes. len_rdn + 3 > len_norm_rdn x 2 -- Yoshiho Yoshida This message and any attachment may contain information that is confidential and/or proprietary. Any use, disclosure, copying, storing, or distribution of this e-mail or any attached file by anyone other than the intended recipient is strictly prohibited. If you have received this message in error, please notify the sender by reply email and delete the message and any attachments. Thank you.

1 0

Re: (ITS#8685) Invalid memory access
by ryan＠nardis.ca 08 Jul '17

08 Jul '17

On Fri, Jul 07, 2017 at 06:20:55AM +0000, ryan(a)nardis.ca wrote: >Unpacking the computation, it looks like the multiplication is the part >that sometimes returns the wrong result. Not the multiplication, but rather the cast of nvalues to double. I'm going to take further followups to the Debian tracker, as it seems fairly clear to me that this is not an OpenLDAP bug.

1 0

Re: (ITS#8688) Is it possible to control on the failover of backend LDAP?
by quanah＠symas.com 07 Jul '17

07 Jul '17

--On Friday, July 07, 2017 4:56 PM +0000 meheni.ziani(a)gmail.com wrote: > Is there a way to close open connections in LDAP1 when the proxy switches > to the LDAP2? Hello, The ITS system is for bug reports only. Usage questions are to be directed to the openldap-technical(a)openldap.org mailing list. As this is not a bug report, this ITS will be closed. Please send your question(s) to the openldap-technical list. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs July 2017