Re: (ITS#8692) back-sock does not create LDAP_MOD_INCREMENT message (unsigned)
by michael＠stroeder.com
(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-increm...
---------------------------------------------------------------------------------------
>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
4 years, 4 months
Re: (ITS#8692) back-sock does not create LDAP_MOD_INCREMENT message
by michael＠stroeder.com
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--
4 years, 4 months
(ITS#8692) back-sock does not create LDAP_MOD_INCREMENT message
by michael＠stroeder.com
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 -----------------------------
4 years, 4 months
Re: (ITS#8690) syncprov memory leak
by quanah＠symas.com
--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>
4 years, 4 months
(ITS#8691) slapd crashes during shutdown
by derrick.mckee＠gmail.com
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>
4 years, 4 months
(ITS#8690) syncprov memory leak
by quanah＠openldap.org
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==
4 years, 4 months
(ITS#8689) invalid rwm configuration causes slapd to SEGV
by quanah＠openldap.org
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"
4 years, 4 months
(ITS#8686)
by yoshiho.yoshida＠synacor.com
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.
4 years, 4 months
Re: (ITS#8685) Invalid memory access
by ryan＠nardis.ca
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.
4 years, 4 months
Re: (ITS#8688) Is it possible to control on the failover of backend LDAP?
by quanah＠symas.com
--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>
4 years, 4 months
