openldap-technical December 2013

openldap-technical@openldap.org

61 participants
73 discussions

Memory leak question
by Markus Moeller 03 Dec '13

03 Dec '13

Hi I am using openldap 2.2.4.33 with cyrus-sasl 2.1.25 to do a sasl bind and get the following valgrind leak message. Looking through the source it seems to be a variable only used inside the openldap library and not related to what I provide to ldap_sasl_interactive_bind_s. ==14039== 34 (32 direct, 2 indirect) bytes in 2 blocks are definitely lost in loss record 561 of 666 ==14039== at 0x4C2C27B: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==14039== by 0x558E764: ber_memalloc_x (memory.c:228) ==14039== by 0x558A8B7: ber_get_stringal (decode.c:582) ==14039== by 0x558AFF5: ber_scanf (decode.c:806) ==14039== by 0x535535D: ldap_parse_sasl_bind_result (sasl.c:327) ==14039== by 0x5351FE1: ldap_int_sasl_bind (cyrus.c:551) ==14039== by 0x5355810: ldap_sasl_interactive_bind (sasl.c:474) ==14039== by 0x5355A0C: ldap_sasl_interactive_bind_s (sasl.c:511) ==14039== by 0x44DDC9: tool_sasl_bind (ldap.c:2338) Is that a real memory leak or is it something I did wrong ? Thank you Markus

3 4

Ldap simple bind problems on slaves during network outage
by Christian Kratzer 03 Dec '13

03 Dec '13

Hi, we are currently chasing a strange issue at a customers site where the ldap slaves become unresponsive when network connectivity to master ldaps and dns servers is lost. They have a setup of two masters and two slaves at separate sites. There is a load balancer sitting in front of the slaves that performs regular health checks consisting of binds followed by a search of their binddn. During regular operations the load balancers health checks look as follows [1] Dec 2 14:38:05 ldap slapd[57585]: conn=3924716 fd=36 ACCEPT from IP=192.0.2.189:33852 (IP=192.0.2.129:389) Dec 2 14:38:05 ldap slapd[57585]: conn=3924716 op=0 BIND dn="cn=keepalive-check-lb,ou=system,dc=example,dc=org" method=128 Dec 2 14:38:05 ldap slapd[57585]: conn=3924716 op=0 BIND dn="cn=keepalive-check-lb,ou=system,dc=example,dc=org" mech=SIMPLE ssf=0 Dec 2 14:38:05 ldap slapd[57585]: conn=3924716 op=0 RESULT tag=97 err=0 text= Dec 2 14:38:05 ldap slapd[57585]: conn=3924716 op=1 SRCH base="ou=system,dc=example,dc=org" scope=1 deref=0 filter="(cn=keepalive-check-lb)" Dec 2 14:38:05 ldap slapd[57585]: conn=3924716 op=1 ENTRY dn="cn=keepalive-check-lb,ou=system,dc=example,dc=org" Dec 2 14:38:05 ldap slapd[57585]: conn=3924716 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= Dec 2 14:38:05 ldap slapd[57585]: conn=3924716 op=2 UNBIND Dec 2 14:38:05 ldap slapd[57585]: connection_closing: readying conn=3924716 sd=36 for close Dec 2 14:38:05 ldap slapd[57585]: connection_resched: attempting closing conn=3924716 sd=36 Dec 2 14:38:05 ldap slapd[57585]: conn=3924716 fd=36 closed When they experience a network outage separating the slaves from the masters and the dns servers the load balancers are not able to bind the slaves: Dec 2 14:38:50 ldap slapd[57585]: conn=3924725 fd=44 ACCEPT from IP=192.0.2.188:35761 (IP=192.0.2.129:389) Dec 2 14:38:50 ldap slapd[57585]: connection_closing: readying conn=3924725 sd=44 for close Dec 2 14:38:50 ldap slapd[57585]: connection_close: deferring conn=3924725 sd=44 Dec 2 14:38:50 ldap slapd[57585]: conn=3924725 op=0 BIND dn="cn=keepalive-check-lb,ou=system,dc=example,dc=org" method=128 Dec 2 14:38:50 ldap slapd[57585]: conn=3924725 op=0 BIND dn="cn=keepalive-check-lb,ou=system,dc=example,dc=org" mech=SIMPLE ssf=0 Dec 2 14:38:50 ldap slapd[57585]: connection_resched: attempting closing conn=3924725 sd=44 Dec 2 14:38:50 ldap slapd[57585]: conn=3924725 fd=44 closed (connection lost) We have not been able to reproduce this problem in a lab setup which is supposed to be identical to the production setup. It does not seem to be related to the servers not being able to perform reverse mapping on the client ips. We run a mixture of 2.4.35 and 2.4.38 on CentOS 6.4. In the lab the slaves are able to perform queries just fine without connectivity to the masters or to their dns servers. The servers are currently running with following loglevel: dn: cn=config olcLogLevel: Conns olcLogLevel: Stats olcLogLevel: Stats2 olcLogLevel: Sync It seems we only get to the point where the bind credentials are parsed after which the connection is closed. This could of course be a problem with the load balancer prematurely closing the connection. I am trying to eliminate any causes in the ldap servers. Any ideas on how to debug this or where we could look. Greetings Christian [1] dns and ips obfuscated to protect the customer -- 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

2 2

Getting internal error, index points to a 00 page!?
by Alain 02 Dec '13

02 Dec '13

Hi, I converted an application from BDB to LMDB (using Java/JNI) and now I'm getting this error when doing an mdb_cursor_get with SET. In debugging, at that point mp is empty: mp = 0x0000000015ddb000 {mp_p={p_pgno=0 p_next=0x0000000000000000 } mp_pad=0 mp_flags=0 ...} The code where this happens is called many times before without issue, so I'm at a lost to explain what is going on. I'm including the debug output from the session. If anybody can point me in the right direction, I will do whatever tests or debugging is needed. BTW, lines numbers might be a bit off as I needed to make minor changes to run under MS VS at line 329, added code for lack of support for __func__: #ifdef _MSC_VER //MS C++ doesn't support __func__ # define DPRINTF0(fmt, ...) \ fprintf(stderr, "%s:%d " fmt "\n", __FUNCTION__, __LINE__, __VA_ARGS__) #else # define DPRINTF0(fmt, ...) \ fprintf(stderr, "%s:%d " fmt "\n", __func__, __LINE__, __VA_ARGS__) #endif Thanks Alain

2 2

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical December 2013