- openldap-bugs - openldap.org

Re: (ITS#8654) Option for LDAP client to bind to a local address.
by hyc＠symas.com 15 May '17

15 May '17

Daniel.Le(a)Exfo.com wrote: > Full_Name: Daniel Le > Version: 2.4.44 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (107.0.5.66) > > > Enhancement request to modify the ldap_set_option function to add support for a > multihomed client to bind to a specific local network address, similarly to > "telnet -b <client-local-address>" option or Microsoft LDAP client API function > ldap_set_option(LDAP_OPT_SOCKET_BIND_ADDRESSES). It might be helpful if you would link to the documentation for this option, so someone can write something compatible. -- -- 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#8654) Option for LDAP client to bind to a local address.
by Daniel.Le＠Exfo.com 15 May '17

15 May '17

Full_Name: Daniel Le Version: 2.4.44 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (107.0.5.66) Enhancement request to modify the ldap_set_option function to add support for a multihomed client to bind to a specific local network address, similarly to "telnet -b <client-local-address>" option or Microsoft LDAP client API function ldap_set_option(LDAP_OPT_SOCKET_BIND_ADDRESSES). Thank you.

1 0

(ITS#8653) ber_flus2 assertion fail leads to a crash of slapd
by mail＠artemil.de 15 May '17

15 May '17

Full_Name: Version: 2.4.44 OS: centos 7, sles 12.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (91.224.226.197) Hello, we are trying to run openldap in a proxy mode to our AD as a virtual machine on a VMWARE ESXi 5.5. Unfortunately slapd crashes by receiving a SIGABRT very often, but not on every request. But the issue can be reproduced easily by just typing several times the "id corporateID" command. I reduced the configuration file to a minimum, - the issue remains. I'm running in to the same issue on SLES 12.2 with openldap 2.4.41 and also on a CentOS 7 with openldap 2.4.44 from the "tlb project". The crash happens, as far as i can determine, always in the ber_flush2 function after a failed assert. Here is the minimal config where the issue persists: include /usr/local/openldap/etc/openldap/schema/core.schema include /usr/local/openldap/etc/openldap/schema/cosine.schema include /usr/local/openldap/etc/openldap/schema/inetorgperson.schema include /usr/local/openldap/etc/openldap/schema/nis.schema include /usr/local/openldap/etc/openldap/schema/misc.schema pidfile /usr/local/openldap/var/run/slapd.pid argsfile /usr/local/openldap/var/run/slapd.args database ldap readonly yes protocol-version 3 rebind-as-user yes uri ldap://ldap.corp.de:389 suffix "DC=corp,DC=de" rootdn "DC=corp,DC=de?sub?&(memberof=CN=DMS-SSH-User,OU=administrative Gruppen\\, Admin- und Dienstkonten,OU=Berechtigungen,DC=corp,DC=de)" loglevel 256 Here comes the backtrace: (gdb) bt #0 0x00007ffff64281d7 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #1 0x00007ffff64298c8 in __GI_abort () at abort.c:90 #2 0x00007ffff6421146 in __assert_fail_base (fmt=0x7ffff65723a8 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x649ab8 "( (sb)->sb_opts.lbo_valid == 0x3 )", file=file@entry=0x649a21 "io.c", line=line@entry=224, function=function@entry=0x649be6 <__PRETTY_FUNCTION__.6214> "ber_flush2") at assert.c:92 #3 0x00007ffff64211f2 in __GI___assert_fail (assertion=assertion@entry=0x649ab8 "( (sb)->sb_opts.lbo_valid == 0x3 )", file=file@entry=0x649a21 "io.c", line=line@entry=224, function=function@entry=0x649be6 <__PRETTY_FUNCTION__.6214> "ber_flush2") at assert.c:101 #4 0x00000000005b95d8 in ber_flush2 (sb=0x7fffe40000d8, ber=0x7fffe4119d40, freeit=freeit@entry=0) at io.c:224 #5 0x00000000005a3491 in ldap_int_flush_request (ld=ld@entry=0x7fffe8102800, lr=lr@entry=0x7fffe410d570) at request.c:186 #6 0x00000000005a38fa in ldap_send_server_request (ld=ld@entry=0x7fffe8102800, ber=ber@entry=0x7fffe4119d40, msgid=msgid@entry=134, parentreq=parentreq@entry=0x0, srvlist=srvlist@entry=0x0, lc=0x7fffe4116f70, lc@entry=0x0, bind=bind@entry=0x0, m_noconn=m_noconn@entry=0, m_res=m_res@entry=0) at request.c:408 #7 0x00000000005a3aa8 in ldap_send_initial_request (ld=ld@entry=0x7fffe8102800, msgtype=msgtype@entry=99, dn=dn@entry=0x7fffe4002e48 "dc=corp,dc=de", ber=0x7fffe4119d40, msgid=134) at request.c:169 #8 0x00000000005946e4 in ldap_pvt_search (ld=0x7fffe8102800, base=0x7fffe4002e48 "dc=corp,dc=de", scope=2, filter=filter@entry=0x7fffe40031a8 "(&(objectClass=group)(gidNumber=20000)(&(OBJECTCATEGORY=group)(gidNumber=*)))", attrs=attrs@entry=0x7fffe4003170, attrsonly=0, sctrls=0x0, cctrls=cctrls@entry=0x0, timeout=0x7ffff35d07f0, sizelimit=1, deref=0, msgidp=msgidp@entry=0x7ffff35d07cc) at search.c:128 #9 0x00000000004c902d in ldap_back_search (op=0x7fffe40028e0, rs=<optimized out>) at search.c:233 #10 0x0000000000442f41 in fe_op_search (op=0x7fffe40028e0, rs=0x7ffff35d19a0) at search.c:402 #11 0x0000000000442926 in do_search (op=0x7fffe40028e0, rs=0x7ffff35d19a0) at search.c:247 #12 0x00000000004407de in connection_operation (ctx=ctx@entry=0x7ffff35d1ad0, arg_v=arg_v@entry=0x7fffe40028e0) at connection.c:1158 #13 0x0000000000440aba in connection_read_thread (ctx=0x7ffff35d1ad0, argv=0xd) at connection.c:1294 #14 0x00000000005901c9 in ldap_int_thread_pool_wrapper (xpool=0x969360) at tpool.c:696 #15 0x00007ffff7896dc5 in start_thread (arg=0x7ffff35d2700) at pthread_create.c:308 #16 0x00007ffff64ea73d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 Here is a full backtrace: https://pastebin.com/Ya3F3WAW Thank you!

1 0

Re: (ITS#6798) Mutex starvation on two-level referral for SASL connection
by jhrozek＠redhat.com 11 May '17

11 May '17

On Wed, May 10, 2017 at 01:19:50PM -0400, Stephen Gallagher wrote: > > > On 05/10/2017 01:13 PM, Quanah Gibson-Mount wrote: > > --On Wednesday, May 10, 2017 2:09 PM -0400 Stephen Gallagher > > <sgallagh(a)redhat.com> wrote: > > > >> Sorry, I'm not sure why you're directing this at me? I've not been > >> involved with this bug at all. > > > > Hi Stephen, > > > > I'm not sure what you mean by "not involved". You are the one who > > filed the bug report with us. Here is a direct link for a refresher: > > > > <http://www.openldap.org/its/index.cgi/?findid=6798> > > > In your previous email, you sent me the ITS number 8648. I missed that > this was in reference to 6798 which I filed in 2011. > > I'm not sure if we still have a reproducer; I think we gave up years ago > on using the built-in referral tracking of libldap. I'm CCing Jakub > Hrozek who is the current tech lead on SSSD to see if he can still > reproduce the issue. I'm sorry, but I couldn't reproduce the issue any longer either. I remember from some of RH customers that they were occasionally hitting this (or similar?) issue and working around it by disabling the LDAP referral chasing in SSSD but I couldn't reproduce now on demand, sorry.

1 0

Re: (ITS#6798) Mutex starvation on two-level referral for SASL connection
by sgallagh＠redhat.com 10 May '17

10 May '17

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --HHc3bK7tdjOA64tcVjmTOngCrPgq87MTg Content-Type: multipart/mixed; boundary="VicgVXOp2ABP8hIiqjm4ijIANjXR7KCdV"; protected-headers="v1" From: Stephen Gallagher <sgallagh(a)redhat.com> To: Quanah Gibson-Mount <quanah(a)symas.com>, openldap-its(a)openldap.org, Jakub Hrozek <jhrozek(a)redhat.com> Message-ID: <4b76c423-a4c3-9fc7-64e2-883388b3e65f(a)redhat.com> Subject: Re: (ITS#6798) Mutex starvation on two-level referral for SASL connection References: <D6162EF94C4315CF6F656712(a)[192.168.1.19]> <777f871f-f77e-7041-dc6a-895e1edb56a6(a)redhat.com> <WM!63a01a37caa0c6690c38e83fd6e7322d72410d224d2fdeade3b0aba909282919d8d93ff608eaaa443968f6d4f6936856!(a)mailstronghold-1.zmailcloud.com> <838E0287ACCF76C2266EC803(a)[192.168.1.19]> In-Reply-To: <838E0287ACCF76C2266EC803(a)[192.168.1.19]> --VicgVXOp2ABP8hIiqjm4ijIANjXR7KCdV Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US On 05/10/2017 01:13 PM, Quanah Gibson-Mount wrote: > --On Wednesday, May 10, 2017 2:09 PM -0400 Stephen Gallagher > <sgallagh(a)redhat.com> wrote: > >> Sorry, I'm not sure why you're directing this at me? I've not been >> involved with this bug at all. > > Hi Stephen, > > I'm not sure what you mean by "not involved". You are the one who > filed the bug report with us. Here is a direct link for a refresher: > > <http://www.openldap.org/its/index.cgi/?findid=3D6798> In your previous email, you sent me the ITS number 8648. I missed that this was in reference to 6798 which I filed in 2011. I'm not sure if we still have a reproducer; I think we gave up years ago on using the built-in referral tracking of libldap. I'm CCing Jakub Hrozek who is the current tech lead on SSSD to see if he can still reproduce the issue. --VicgVXOp2ABP8hIiqjm4ijIANjXR7KCdV-- --HHc3bK7tdjOA64tcVjmTOngCrPgq87MTg Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iFwEARECAB0WIQQ0v96iCbHqLp/cLlN6JVViNrqjowUCWRNLtgAKCRB6JVViNrqj o8toAJiFVe4hmZE+5WazEAf1UrguCR0fAKCUxCVSXwgdL5eWpMtFPPgkqqaY0g== =vdhI -----END PGP SIGNATURE----- --HHc3bK7tdjOA64tcVjmTOngCrPgq87MTg--

1 0

Re: (ITS#6798) Mutex starvation on two-level referral for SASL connection
by quanah＠symas.com 10 May '17

10 May '17

--On Wednesday, May 10, 2017 2:09 PM -0400 Stephen Gallagher <sgallagh(a)redhat.com> wrote: > Sorry, I'm not sure why you're directing this at me? I've not been > involved with this bug at all. Hi Stephen, I'm not sure what you mean by "not involved". You are the one who filed the bug report with us. Here is a direct link for a refresher: <http://www.openldap.org/its/index.cgi/?findid=6798> Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#6798) Mutex starvation on two-level referral for SASL connection
by sgallagh＠redhat.com 10 May '17

10 May '17

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ijumfDLdJ6N1xL1tHwFiTBhCBA9VnmThW Content-Type: multipart/mixed; boundary="rw1j2W5jTxST7ATlUt2I8c5Ena44RM7Vs"; protected-headers="v1" From: Stephen Gallagher <sgallagh(a)redhat.com> To: Quanah Gibson-Mount <quanah(a)symas.com>, openldap-its(a)openldap.org Message-ID: <777f871f-f77e-7041-dc6a-895e1edb56a6(a)redhat.com> Subject: Re: (ITS#6798) Mutex starvation on two-level referral for SASL connection References: <D6162EF94C4315CF6F656712(a)[192.168.1.19]> In-Reply-To: <D6162EF94C4315CF6F656712(a)[192.168.1.19]> --rw1j2W5jTxST7ATlUt2I8c5Ena44RM7Vs Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Sorry, I'm not sure why you're directing this at me? I've not been involved with this bug at all. On 05/10/2017 12:56 PM, Quanah Gibson-Mount wrote: > Hi Stephen, > > Would you be able to check and confirm if the fix for ITS#8648 that > has been checked into RE24 resolves this issue? > > Thanks, > Quanah > > --=20 > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > --rw1j2W5jTxST7ATlUt2I8c5Ena44RM7Vs-- --ijumfDLdJ6N1xL1tHwFiTBhCBA9VnmThW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQ0v96iCbHqLp/cLlN6JVViNrqjowUCWRNJVwAKCRB6JVViNrqj o3iuAJ40OLMe/nQHhjOAO7Uhuaxj8OWnxgCeJqR819BAH7lwMmVsOqyhRGCdJXA= =oyIK -----END PGP SIGNATURE----- --ijumfDLdJ6N1xL1tHwFiTBhCBA9VnmThW--

1 0

Re: (ITS#6798) Mutex starvation on two-level referral for SASL connection
by quanah＠symas.com 10 May '17

10 May '17

Hi Stephen, Would you be able to check and confirm if the fix for ITS#8648 that has been checked into RE24 resolves this issue? Thanks, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8648) sasl_client_init called concurrently causes issues
by ryan＠nardis.ca 09 May '17

09 May '17

An Ubuntu user confirmed that this change solved their issue with slapd and multiple syncrepl clients using GSSAPI. https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1688575/comments/6

1 0

Re: (ITS#8650) EAGAIN from gnutls_handshake not respected
by ryan＠nardis.ca 07 May '17

07 May '17

Committed the fix, and pinged the submitter to test it.

1 0

(ITS#8650) EAGAIN from gnutls_handshake not respected
by ryan＠openldap.org 07 May '17

07 May '17

Full_Name: Ryan Tandy Version: RE24 OS: Debian URL: Submission from: (NULL) (24.68.41.160) Submitted by: ryan https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=861838 That bug's submitter seems to have unintentionally configured their slapd with the entire list of system CAs. They're fixing it, but we have a bug here too. When the ServerHello is larger than 16kb, gnutls_handshake can return GNUTLS_E_AGAIN. In theory this was always possible, but I'm only seeing it happen with gnutls 3.x and haven't the exact change responsible. We need to loop gnutls_handshake until it completes, like we do already in the re-handshake case.

1 0

Re: (ITS#8648) sasl_client_init called concurrently causes issues
by hyc＠symas.com 02 May '17

02 May '17

ryan(a)nardis.ca wrote: > On Fri, Apr 28, 2017 at 02:52:44PM +0000, ryan(a)nardis.ca wrote: >> I tried cyrus-sasl-2.1.25 and the issue doesn't seem to happen. I'll see >> if I can isolate the related change. > > SASL version was a red herring. I accidentally linked with Debian's > libldap (2.4.31) when I tested that. Mea culpa. > > The culprit does indeed seem to be the ITS#6798 change, as Quanah > suggested. Reverting b483ee1a ("Drop ldap_int_sasl_mutex") on RE24 and > linking with libldap_r makes my test program work. > > Since the proof-of-concept patch I posted above also makes my test > program work, I'm back to thinking that calling sasl_client_init > concurrently is the real bug here. > >> On Fri, Apr 28, 2017 at 04:43:33AM +0000, ryan(a)openldap.org wrote: >>> If I'm right about this bug, I suppose the right fix is to wrap sasl_client_init >>> in a new mutex. >> >> ... of course that idea's half-baked, because libldap doesn't *have* >> mutexes. hmm. > > I'm still not happy with the idea of calling sasl_client_init from > ldap_int_initialize, as it does a bunch of work (loading plugins and > such) that non-SASL users don't care about. However, I haven't as yet > thought of another fix that works for libldap as well as libldap_r. > > Would love to hear others' thoughts on this. Maybe fixing for libldap_r > only (and documenting that) is a good enough compromise? Yes, if the problem only exists in concurrent use then it's only relevant to libldap_r. -- -- 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#8581) slapd-meta backend SSL negociation timeout
by louis.chanouha＠test.univ-toulouse.fr 02 May '17

02 May '17

I looked deeper into the source, and i found the problem. Non-blocking socket seems to be implemented in starttls connection only, not in direct-SSL (ldaps://) which use a blocking socket. The problem isn't openssl or gnutls related. Another solution could be to set the socket timeout to a more reasonable value. I would like to help more, but this kind of modification is too complicated for my actual knowledge of sockets. Regards.

1 0

Re: (ITS#8648) sasl_client_init called concurrently causes issues
by ryan＠nardis.ca 02 May '17

02 May '17

On Fri, Apr 28, 2017 at 02:52:44PM +0000, ryan(a)nardis.ca wrote: >I tried cyrus-sasl-2.1.25 and the issue doesn't seem to happen. I'll see >if I can isolate the related change. SASL version was a red herring. I accidentally linked with Debian's libldap (2.4.31) when I tested that. Mea culpa. The culprit does indeed seem to be the ITS#6798 change, as Quanah suggested. Reverting b483ee1a ("Drop ldap_int_sasl_mutex") on RE24 and linking with libldap_r makes my test program work. Since the proof-of-concept patch I posted above also makes my test program work, I'm back to thinking that calling sasl_client_init concurrently is the real bug here. >On Fri, Apr 28, 2017 at 04:43:33AM +0000, ryan(a)openldap.org wrote: >>If I'm right about this bug, I suppose the right fix is to wrap sasl_client_init >>in a new mutex. > >... of course that idea's half-baked, because libldap doesn't *have* >mutexes. hmm. I'm still not happy with the idea of calling sasl_client_init from ldap_int_initialize, as it does a bunch of work (loading plugins and such) that non-SASL users don't care about. However, I haven't as yet thought of another fix that works for libldap as well as libldap_r. Would love to hear others' thoughts on this. Maybe fixing for libldap_r only (and documenting that) is a good enough compromise?

1 0

Re: (ITS#8649) Issue when fetching the backend that will receive the contextCSN when we have glued databases
by hyc＠symas.com 29 Apr '17

29 Apr '17

elecharny(a)gmail.com wrote: > Using a function to compute the working backend, it could be something > like : Discussions really belong on the -devel list, not in the ITS. > > void setWorkingBackend( syncinfo_t *syncInfo, Backend *backend ) > { > if ( !syncInfo->si_wbe ) > { > if ( SLAP_GLUE_SUBORDINATE( backend ) && !overlay_is_inst( > backend, "syncprov" ) ) > { > // The backend has a parent backend, fetch it. Note that we > want to get the > // top parent, not one of the intermediary subordinate, > unless one of them > // has a syncprov overlay declared. If the top level backend > // does not have a syncprov overlay declared, then we use > the local DB > // as a working backend. > BackendDB *currentBackend = backend; > struct berval bv; > ber_str2bv( currentBackend->be_nsuffix[0].bv_val, 0, 0, &bv ); > dnParent( &bv, &bv ); > > while ( ( currentBackend = select_backend( &bv, 0 ) ) != NULL ) > { > if ( overlay_is_inst( currentBackend, "syncprov" ) ) > { > syncInfo->si_wbe = currentBackend; > break; > } > > dnParent( &bv, &bv ); > } > > if ( syncInfo->si_wbe == NULL ) > { > syncInfo->si_wbe = backend; > } > } > else > { > syncInfo->si_wbe = backend; > } > > if ( SLAP_SYNC_SUBENTRY( syncInfo->si_wbe ) ) > { > build_new_dn( &syncInfo->si_contextdn, > &syncInfo->si_wbe->be_nsuffix[0], (struct berval *) > &slap_ldapsync_cn_bv, NULL ); > } > else > { > syncInfo->si_contextdn = syncInfo->si_wbe->be_nsuffix[0]; > } > } > } > > > We call it with > > setWorkingBackend( si, be ); > > -- -- 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#8649) Issue when fetching the backend that will receive the contextCSN when we have glued databases
by elecharny＠gmail.com 29 Apr '17

29 Apr '17

Using a function to compute the working backend, it could be something like : void setWorkingBackend( syncinfo_t *syncInfo, Backend *backend ) { if ( !syncInfo->si_wbe ) { if ( SLAP_GLUE_SUBORDINATE( backend ) && !overlay_is_inst( backend, "syncprov" ) ) { // The backend has a parent backend, fetch it. Note that we want to get the // top parent, not one of the intermediary subordinate, unless one of them // has a syncprov overlay declared. If the top level backend // does not have a syncprov overlay declared, then we use the local DB // as a working backend. BackendDB *currentBackend = backend; struct berval bv; ber_str2bv( currentBackend->be_nsuffix[0].bv_val, 0, 0, &bv ); dnParent( &bv, &bv ); while ( ( currentBackend = select_backend( &bv, 0 ) ) != NULL ) { if ( overlay_is_inst( currentBackend, "syncprov" ) ) { syncInfo->si_wbe = currentBackend; break; } dnParent( &bv, &bv ); } if ( syncInfo->si_wbe == NULL ) { syncInfo->si_wbe = backend; } } else { syncInfo->si_wbe = backend; } if ( SLAP_SYNC_SUBENTRY( syncInfo->si_wbe ) ) { build_new_dn( &syncInfo->si_contextdn, &syncInfo->si_wbe->be_nsuffix[0], (struct berval *) &slap_ldapsync_cn_bv, NULL ); } else { syncInfo->si_contextdn = syncInfo->si_wbe->be_nsuffix[0]; } } } We call it with setWorkingBackend( si, be ); -- Emmanuel Lecharny Symas.com directory.apache.org

1 0

Re: (ITS#7005) Collision of LDAP calls between Oracle, Curl and OpenLDAP libraries
by quanah＠symas.com 28 Apr '17

28 Apr '17

Hello, The issue reported here is not a problem caused by OpenLDAP. It appears to be due to a static LDAP library from Oracle that was compiled in. You would need to raise this issue with Oracle for a resolution. This ITS will be closed. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#7888) client configuration---openldap n-way multi-master replication
by quanah＠symas.com 28 Apr '17

28 Apr '17

Hello, Usage questions need to be directed to the openldap-technical list, not the ITS system. This ITS will be closed. For help using the list, see: <http://www.openldap.org/lists/mm/listinfo/openldap-technical> Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8649) Issue when fetching the backend that will receive the contextCSN when we have glued databases
by elecharny＠gmail.com 28 Apr '17

28 Apr '17

Using a value of 0 for the subs parameter of the select_backend( &backend->be_nsuffix[0], 1 ) function instead of 1 won't help : it would select the local backend. We really need to recurse up to the top level backend slicing the RDN at each round. -- Emmanuel Lecharny Symas.com directory.apache.org

1 0

(ITS#8649) Issue when fetching the backend that will receive the contextCSN when we have glued databases
by elecharny＠apache.org 28 Apr '17

28 Apr '17

Full_Name: Emmanuel L.charny Version: 2.4.45 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (176.154.3.51) When syncrepl is started, it first searches which backend will host the contextCSN. There are two factors in play : - do we have a syncprov overlay - do we have parent backends. If the local DB is a subordinate, then we have to look in its parents to see if one of them has a syncprov overlay. If so, then this backend will be the one receiving the contextCSN. Otherwise, the local DB will. Now, if we have a hierarchy of backends (ie, 3 or more subordinates in a chain), with the syncprov overlay present in an intermediate backend, then the contextCSN will not be attached to it, but to the local DB. This is because the select_backend( &backend->be_nsuffix[0], 1 ) function tries to fetch the top level backend, regardless the presence of the syncprov overlay in intermediary subordinates. IMO, instead of calling select_backend with the parameter 1 (is, subs), we should call it recursively up to the point we reach the top level or we find a backend with the syncprov overlay.

1 0

Re: (ITS#8648) sasl_client_init called concurrently causes issues
by ryan＠nardis.ca 28 Apr '17

28 Apr '17

On Fri, Apr 28, 2017 at 04:43:33AM +0000, ryan(a)openldap.org wrote: >If I'm right about this bug, I suppose the right fix is to wrap sasl_client_init >in a new mutex. ... of course that idea's half-baked, because libldap doesn't *have* mutexes. hmm. I tried cyrus-sasl-2.1.25 and the issue doesn't seem to happen. I'll see if I can isolate the related change.

1 0

(ITS#8648) sasl_client_init called concurrently causes issues
by ryan＠openldap.org 28 Apr '17

28 Apr '17

Full_Name: Ryan Tandy Version: RE24 (66d107e) OS: Debian URL: Submission from: (NULL) (24.68.41.160) Submitted by: ryan Test program uploaded to the FTP site: ftp://ftp.openldap.org/incoming/20170427_rtandy_sasltest.c I have built cyrus-sasl and openldap myself from clean sources in order to rule out issues introduced by Debian patches. My environment is Debian unstable with OpenSSL 1.0.2k. cyrus-sasl master at 04dd838 ./autogen.sh CFLAGS="-g -O0" --with-devrandom=/dev/urandom make sudo make install sudo ldconfig export SASL_PATH=/usr/local/lib/sasl2 openldap RE24 at 66d107e ./configure CFLAGS="-g -O0" --disable-backends --enable-mdb --disable-overlays --with-cyrus-sasl --with-tls=openssl make sudo make STRIP= install sudo ldconfig cat > slapd.conf << 'eof' include servers/slapd/schema/core.schema include servers/slapd/schema/cosine.schema sasl-secprops none authz-regexp uid=(.*),cn=.*,cn=auth ldap:///dc=example,dc=com??sub?(uid=$1) database mdb directory . suffix dc=example,dc=com rootdn cn=root,dc=example,dc=com index objectClass eq eof /usr/local/sbin/slapadd -f slapd.conf << eof dn: dc=example,dc=com objectClass: domain dc: example dn: uid=admin,dc=example,dc=com objectClass: account objectClass: simpleSecurityObject uid: admin userPassword: admin eof /usr/local/libexec/slapd -h ldap://:9000 -f slapd.conf -s0 -dstats # allow PLAIN export LDAPSASL_SECPROPS=none # verify authz-regexp. should return uid=admin,dc=example,dc=com ldapwhoami -H ldap://:9000 -Y PLAIN -U admin -w admin # edit sasltest.c and change defines as needed. remove -DSASL to use simple bind cc -g -DSASL sasltest.c -pthread -llber -lldap -lsasl2 -o sasltest ./sasltest On my system, most runs of ./sasltest result in errors like: rc = -6 (Unknown authentication method) sasltest: sasltest.c:70: bind_thread: Assertion `rc == LDAP_SUCCESS' failed. Aborted With no concurrency (THREADS defined to 1), I see no errors. I believe this is due to sasl_client_init being called from multiple threads concurrently. I suspect the global mech list is getting mucked with. As a proof of concept, I patched libldap to call sasl_client_init during its global init: ftp://ftp.openldap.org/incoming/20170427_rtandy_call-sasl_client_init-in-gl… With this change, I see no errors. If I'm right about this bug, I suppose the right fix is to wrap sasl_client_init in a new mutex. I'll post a patch for review soon.

1 0

Re: (ITS#8646) openldap aborts with ldap_first_entry (ld=0x5564, chain=0x6) at getentry.c:36
by quanah＠symas.com 27 Apr '17

27 Apr '17

--On Thursday, April 27, 2017 1:01 PM +0000 kavyauk(a)gmail.com wrote: > Full_Name: Kavya U K > Version: 2.4.33 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (72.163.220.19) > > > Our application uses openladp library to LDAP authentication . > > Intermittently application crashes with below back trace . > > backtrace > =================================== ># 0 0x008b1266 in raise () from /lib/libc.so.6 ># 1 0x008b2c31 in abort () from /lib/libc.so.6 ># 2 0x008aa49d in __assert_fail () from /lib/libc.so.6 ># 3 0x00a3e056 in ldap_first_entry (ld=0x5564, chain=0x6) at getentry.c:36 > > Please let us know how to resolve it As noted by Michael, you're using an ancient, unsupported release. There also is not enough detail here to do anything actionable. If you can reproduce this issue with the current release of OpenLDAP, then please ensure that you are able to provide a backtrace that contains full debugging symbols, as discussed in <http://www.openldap.org/faq/data/cache/59.html>. For now, this ITS will be closed. Please reply to the ITS with the full backtrace information if you can reproduce with the current OpenLDAP release and we will reopen for investigation. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8647) support of weak ciphers according to rfc4513
by quanah＠symas.com 27 Apr '17

27 Apr '17

Hello, Thanks for your report. The IETF is the correct organization to report RFC issues to, rather than the OpenLDAP Foundation. I would suggest you redirect this to them. This ITS will be closed. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

ITS#8647 published: SECURITY: support of weak ciphers according to rfc4513
by openldap-its＠OpenLDAP.org 27 Apr '17

27 Apr '17

Private ITS#8647 is now publicly readable URL: http://www.OpenLDAP.org/its/?findid=8647

1 0

Re: (ITS#8646) openldap aborts with ldap_first_entry (ld=0x5564, chain=0x6) at getentry.c:36
by michael＠stroeder.com 27 Apr '17

27 Apr '17

kavyauk(a)gmail.com wrote: > Version: 2.4.33 Note that release 2.4.33 is 4,5 years old. Many fixes have been applied since then. Do you still experience the same problem with recent release 2.4.44? Ciao, Michael.

1 0

(ITS#8646) openldap aborts with ldap_first_entry (ld=0x5564, chain=0x6) at getentry.c:36
by kavyauk＠gmail.com 27 Apr '17

27 Apr '17

Full_Name: Kavya U K Version: 2.4.33 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (72.163.220.19) Our application uses openladp library to LDAP authentication . Intermittently application crashes with below back trace . backtrace =================================== #0 0x008b1266 in raise () from /lib/libc.so.6 #1 0x008b2c31 in abort () from /lib/libc.so.6 #2 0x008aa49d in __assert_fail () from /lib/libc.so.6 #3 0x00a3e056 in ldap_first_entry (ld=0x5564, chain=0x6) at getentry.c:36 Please let us know how to resolve it

1 0

(ITS#8645) syncrepl configuration error handling
by elecharny＠apache.org 27 Apr '17

27 Apr '17

Full_Name: Emmanuel L.charny Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (176.154.3.51) The parse_syncrepl_line function (syncrepl.c) returns either 0, -1 or 1. 0 is for success, -1 is for a error, 1 seems to be for a warning (ie a parameter is wrongly configured, but then it's ignored). That's ok, except that in the loop where the parameters are parsed, if one of the parameters in {'retry', 'manageDSAit', 'sizelimit', 'timelimit'} is incorect, the following parameters aren't parsed at all, the fuction return 1. At this point, in the caller function add_syncrepl, we have : rc = parse_syncrepl_line( c, si ); if ( rc == 0 ) { ... } if ( rc < 0 ) { Debug( LDAP_DEBUG_ANY, "failed to add syncinfo\n", 0, 0, 0 ); syncinfo_free( si, 0 ); return 1; } else { Debug( LDAP_DEBUG_CONFIG, "Config: ** successfully added syncrepl %s \"%s\"\n", si->si_ridtxt, BER_BVISNULL( &si->si_bindconf.sb_uri ) ? "(null)" : si->si_bindconf.sb_uri.bv_val, 0 ); ... So here, we will have a message indicating syncrepl has properly be initialized, when many parameters might have been ignored. It seems the proper handling of those wrongly initialized parameters should be to do a 'continue' instead of returning 1, and add a warning in logs. Like : ... else if ( !strncasecmp( c->argv[ i ], RETRYSTR "=", STRLENOF( RETRYSTR "=" ) ) ) { if ( parse_syncrepl_retry( c, c->argv[ i ], si ) ) { continue; /* was return 1; } } Or maybe we just want to return -1 in all cases ?

1 0

(ITS#8644) test064-constraint should wait for slapd to start
by ryan＠openldap.org 25 Apr '17

25 Apr '17

Full_Name: Ryan Tandy Version: 2.4.44 OS: Debian URL: Submission from: (NULL) (24.68.41.160) Submitted by: ryan test064-constraint can occasionally fail if ldapadd runs while slapd is still starting up. https://bugs.debian.org/770890 has links to examples. >>>>> Starting test064-constraint for hdb... running defines.sh Starting slapd on TCP/IP port 9011... Adding basic structure... ldapadd failed (255)! >>>>> test064-constraint failed for hdb (exit 255) Other scripts have an ldapsearch loop that waits for slapd to start, and the same should suffice here.

1 0

Re: (ITS#8592) Double free in sssvlv.c
by kevinanties＠gmail.com 24 Apr '17

24 Apr '17

--f403043eddf896760a054de0b265 Content-Type: text/plain; charset=UTF-8 Why this bug is still not fixed? This is a critical bug for those who enable this overlay. On Wed, Feb 22, 2017 at 12:09 AM, Quanah Gibson-Mount <quanah(a)symas.com> wrote: > --On Tuesday, February 21, 2017 4:20 AM +0000 kevinanties(a)gmail.com wrote: > > --f403045e3462d25e8f054902b3a3 >> Content-Type: text/plain; charset=UTF-8 >> >> I have submitted to ftp/incoming. The filename is >> kevin-170221-sssvlv.patch. >> > > Please carefully read the contribution web page. Your submission is > clearly missing the IPR notice: > > <http://www.openldap.org/devel/contributing.html#notice> > > > Regards, > Quanah > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > > --f403043eddf896760a054de0b265 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Why this bug is still not fixed? This is a critical bug fo= r those who enable this overlay.<br></div><div class=3D"gmail_extra"><br><d= iv class=3D"gmail_quote">On Wed, Feb 22, 2017 at 12:09 AM, Quanah Gibson-Mo= unt <span dir=3D"ltr"><<a href=3D"mailto:quanah@symas.com" target=3D"_bl= ank">quanah(a)symas.com</a>></span> wrote:<br><blockquote class=3D"gmail_q= uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e= x">--On Tuesday, February 21, 2017 4:20 AM +0000 <a href=3D"mailto:kevinant= ies(a)gmail.com" target=3D"_blank">kevinanties(a)gmail.com</a> wrote:<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> --f403045e3462d25e8f054902b3a3<br> Content-Type: text/plain; charset=3DUTF-8<span class=3D""><br> <br> I have submitted to ftp/incoming. The filename is<br> kevin-170221-sssvlv.patch.<br> </span></blockquote> <br> Please carefully read the contribution web page.=C2=A0 Your submission is c= learly missing the IPR notice:<br> <br> <<a href=3D"http://www.openldap.org/devel/contributing.html#notice" rel= =3D"noreferrer" target=3D"_blank">http://www.openldap.org/devel<wbr>/contri= buting.html#notice</a>><div class=3D"HOEnZb"><div class=3D"h5"><br> <br> Regards,<br> Quanah<br> <br> --<br> <br> Quanah Gibson-Mount<br> Product Architect<br> Symas Corporation<br> Packaged, certified, and supported LDAP solutions powered by OpenLDAP:<br> <<a href=3D"http://www.symas.com" rel=3D"noreferrer" target=3D"_blank">h= ttp://www.symas.com</a>><br> <br> </div></div></blockquote></div><br></div> --f403043eddf896760a054de0b265--

1 0

Re: (ITS#8605) spelling
by quanah＠symas.com 24 Apr '17

24 Apr '17

Hi Josh, Thanks very much! In the future, please remember to CC openldap-its(a)openldap.org, or there will not be a record in the ITS of the submission. ;) --Quanah --On Sunday, April 23, 2017 8:37 PM -0400 Josh Soref <jsoref(a)gmail.com> wrote: > I've uploaded it again: >> ftp ftp.openldap.org > Connected to www.openldap.org. > 220 ProFTPD 1.3.4a Server (gauss) [::ffff:23.92.27.230] > 200 UTF8 set to on > User (www.openldap.org:(none)): ftp > 331 Anonymous login ok, send your complete email address as your password > Password: > 230 Anonymous access granted, restrictions apply > ftp> cd incoming > 250 CWD command successful > ftp> dir > 200 PORT command successful > 150 Opening ASCII mode data connection for file list > 226 Transfer complete > ftp> ascii > 200 Type set to A > ftp> put > Local file 0001-spelling-fixes.patch > Remote file josh-soref-170423.patch > 200 PORT command successful > 150 Opening ASCII mode data connection for josh-soref-170423.patch > 226 Transfer complete > ftp: 133503 bytes sent in 1.13Seconds 117.73Kbytes/sec. > ftp> quit > 221 Goodbye -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8205)
by quanah＠symas.com 23 Apr '17

23 Apr '17

--On Sunday, October 25, 2015 10:28 AM +0000 hyc(a)symas.com wrote: > peter(a)adpm.de wrote: >> Hi, >> >> I extended the patch series with a manual page for pbkdf2 >> * >> https://github.com/marschap/openldap/commit/f63202e8aa68e3391f52d2481f64 >> 9ca22aeb5ae4 contrib/passwd/pbkdf2: add man page, install it too > > Please use format-patch to submit patches, thanks. If you add .patch to the end of the URL, you can trivially get patches already formatted for use with git. A rather useful trick. ;) --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8605) spelling
by quanah＠symas.com 23 Apr '17

23 Apr '17

Hi Josh, Still waiting on a git format patch, as per the contribution guidelines: <http://www.openldap.org/devel/contributing.html#formats> Thanks, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8609) segfault in mods.c - modify_add_values
by quanah＠symas.com 21 Apr '17

21 Apr '17

--On Friday, April 21, 2017 2:26 AM +0100 Howard Chu <hyc(a)symas.com> wrote: >> It's fine for there to be legacy entryCSNs and a contextCSN for serverID >> of 0. However, it is not fine for any master in an MMR setup to have a >> specific serverID of 0. If you're running with serverID's 0-3, I'd >> simply try an ldapmodify on the server with 0 to set its serverID to 4, >> and then do a modification against it, so it generates a new contextCSN >> that gets pushed out to all nodes. > > Performance-wise, it would be better to delete the SID 0 contextCSN value > too. Yeah, definitely not optimal, but less of a worry at the moment. ;) --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8609) segfault in mods.c - modify_add_values
by hyc＠symas.com 21 Apr '17

21 Apr '17

quanah(a)symas.com wrote: > --On Thursday, April 20, 2017 9:02 PM +0000 henson(a)acm.org wrote: > >>> From: Quanah Gibson-Mount >>> Sent: Thursday, April 20, 2017 8:07 AM >>> >>> You stated previously that you are in 4-way MMR. It's not valid to have >>> a serverID of 0 in an MMR environment (See >>> <http://www.openldap.org/its/index.cgi/?findid=8635>). >> >> Well now, that's quite a fresh ITS 8-/. I'm guessing quite a few people >> have serverID's of 0 in their replicated environments, as I don't know >> that I've ever seen that information before. What are the ramifications >> of having a server with an ID of 0 in a replicated environment? What is >> the procedure for remediating the issue? Is it as simple as shutting down >> that server, updating the configuration to have a serverID of 4 and >> restarting it? Or does the database need to be stripped of all CSN's >> which have an ID of 0 via slapcat, grep -v, and then slapadd with the -w >> option on the master and then reloading from ldif on all the replicas? > > It's fine for there to be legacy entryCSNs and a contextCSN for serverID of > 0. However, it is not fine for any master in an MMR setup to have a > specific serverID of 0. If you're running with serverID's 0-3, I'd simply > try an ldapmodify on the server with 0 to set its serverID to 4, and then > do a modification against it, so it generates a new contextCSN that gets > pushed out to all nodes. Performance-wise, it would be better to delete the SID 0 contextCSN value too. -- -- 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#8609) segfault in mods.c - modify_add_values
by quanah＠symas.com 20 Apr '17

20 Apr '17

--On Thursday, April 20, 2017 9:02 PM +0000 henson(a)acm.org wrote: >> From: Quanah Gibson-Mount >> Sent: Thursday, April 20, 2017 8:07 AM >> >> You stated previously that you are in 4-way MMR. It's not valid to have >> a serverID of 0 in an MMR environment (See >> <http://www.openldap.org/its/index.cgi/?findid=8635>). > > Well now, that's quite a fresh ITS 8-/. I'm guessing quite a few people > have serverID's of 0 in their replicated environments, as I don't know > that I've ever seen that information before. What are the ramifications > of having a server with an ID of 0 in a replicated environment? What is > the procedure for remediating the issue? Is it as simple as shutting down > that server, updating the configuration to have a serverID of 4 and > restarting it? Or does the database need to be stripped of all CSN's > which have an ID of 0 via slapcat, grep -v, and then slapadd with the -w > option on the master and then reloading from ldif on all the replicas? It's fine for there to be legacy entryCSNs and a contextCSN for serverID of 0. However, it is not fine for any master in an MMR setup to have a specific serverID of 0. If you're running with serverID's 0-3, I'd simply try an ldapmodify on the server with 0 to set its serverID to 4, and then do a modification against it, so it generates a new contextCSN that gets pushed out to all nodes. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

RE: (ITS#8609) segfault in mods.c - modify_add_values
by henson＠acm.org 20 Apr '17

20 Apr '17

> From: Quanah Gibson-Mount > Sent: Thursday, April 20, 2017 8:07 AM > > You stated previously that you are in 4-way MMR. It's not valid to have a > serverID of 0 in an MMR environment (See > <http://www.openldap.org/its/index.cgi/?findid=8635>). Well now, that's quite a fresh ITS 8-/. I'm guessing quite a few people have serverID's of 0 in their replicated environments, as I don't know that I've ever seen that information before. What are the ramifications of having a server with an ID of 0 in a replicated environment? What is the procedure for remediating the issue? Is it as simple as shutting down that server, updating the configuration to have a serverID of 4 and restarting it? Or does the database need to be stripped of all CSN's which have an ID of 0 via slapcat, grep -v, and then slapadd with the -w option on the master and then reloading from ldif on all the replicas?

1 0

RE: (ITS#8609) segfault in mods.c - modify_add_values
by henson＠acm.org 20 Apr '17

20 Apr '17

> From: Ond=C5=99ej Kuzn=C3=ADk > Sent: Thursday, April 20, 2017 1:34 AM > > those come from master with ServerID 0? Maybe you can find them in > another server's accesslog? Hmm, no, I don't see them in any of the three other accesslogs either. > Would you be able to try the patch I provided earlier on one of your > servers? This one? ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20170327-ITS8609-ignore-inv= alid-accesslog-ops.patch Sure, I can drop this in on the master server that has been crashing and = see what happens. Thanks=E2=80=A6

1 0

Re: (ITS#8609) segfault in mods.c - modify_add_values
by quanah＠symas.com 20 Apr '17

20 Apr '17

--On Thursday, April 20, 2017 9:34 AM +0000 okuznik(a)symas.com wrote: > On Wed, Apr 19, 2017 at 01:03:15PM -0700, Paul B. Henson wrote: >> On Wed, Apr 19, 2017 at 05:37:35PM +0100, Ond=C5=99ej Kuzn=C3=ADk wrote= > : >>> could you post the two accesslog entries (or at least an outline) >>> referenced in the backtrace? >> =20 >> That's weird. I can't find these exact entries. Based on the username, = > I >> found ones that are very close to the timestamp, but ones that match >> these exact timestamps do not exist. Last time Quanah asked me to look >> up the matching accesslog entry from the crash I believe I was able to >> find it. > > Hi Paul, > those come from master with ServerID 0? Maybe you can find them in > another server's accesslog? Hi Paul, You stated previously that you are in 4-way MMR. It's not valid to have a serverID of 0 in an MMR environment (See <http://www.openldap.org/its/index.cgi/?findid=8635>). --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8609) segfault in mods.c - modify_add_values
by okuznik＠symas.com 20 Apr '17

20 Apr '17

On Wed, Apr 19, 2017 at 01:03:15PM -0700, Paul B. Henson wrote: > On Wed, Apr 19, 2017 at 05:37:35PM +0100, Ond=C5=99ej Kuzn=C3=ADk wrote= : >> could you post the two accesslog entries (or at least an outline) >> referenced in the backtrace? >=20 > That's weird. I can't find these exact entries. Based on the username, = I > found ones that are very close to the timestamp, but ones that match > these exact timestamps do not exist. Last time Quanah asked me to look > up the matching accesslog entry from the crash I believe I was able to > find it. Hi Paul, those come from master with ServerID 0? Maybe you can find them in another server's accesslog? >> - reqStart=3D20170415103641.000016Z,cn=3Daccesslog >=20 > dn: reqStart=3D20170415103641.000068Z,cn=3Daccesslog > reqDN: uid=3Dbrandonl,ou=3Duser,dc=3Dcpp,dc=3Dedu > reqMod: entryCSN:=3D 20170415103641.599920Z#000000#000#000000 > entryCSN: 20170415103641.599920Z#000000#000#000000 >=20 >> - reqStart=3D20170416103057.000005Z,cn=3Daccesslog >=20 > dn: reqStart=3D20170416103057.000045Z,cn=3Daccesslog > reqDN: uid=3Daaalmora,ou=3Duser,dc=3Dcpp,dc=3Dedu > reqMod: entryCSN:=3D 20170416103057.530384Z#000000#000#000000 > entryCSN: 20170416103057.530384Z#000000#000#000000 >=20 >> I assume you are still running the same code in production, correct? >=20 > Yes. It actually crashed 4 days in a row :(, the two days I provided > backtraces for and then the following two days. Just for something to d= o > I slapcat'd the db and accesslog and reloaded it after the fourth day i= n > case there was some weird mdb corruption or something. It hasn't crashe= d > since, but it crashes randomly so that could be meaningless <sigh>. I > wouldn't think reloaded the db would have affected finding the matching > accesslog entries but that is something different than last time too. > And of course now this is the non-optimized build. Would you be able to try the patch I provided earlier on one of your servers? Thanks, --=20 Ond=C5=99ej Kuzn=C3=ADk Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

Re: (ITS#8609) segfault in mods.c - modify_add_values
by henson＠acm.org 19 Apr '17

19 Apr '17

On Wed, Apr 19, 2017 at 05:37:35PM +0100, Ondřej Kuzník wrote: > could you post the two accesslog entries (or at least an outline) > referenced in the backtrace? That's weird. I can't find these exact entries. Based on the username, I found ones that are very close to the timestamp, but ones that match these exact timestamps do not exist. Last time Quanah asked me to look up the matching accesslog entry from the crash I believe I was able to find it. > - reqStart=20170415103641.000016Z,cn=accesslog dn: reqStart=20170415103641.000068Z,cn=accesslog objectClass: auditModify structuralObjectClass: auditModify reqStart: 20170415103641.000068Z reqEnd: 20170415103641.000069Z reqType: modify reqSession: 792228 reqAuthzID: cn=idmgmt,ou=user,ou=service,dc=cpp,dc=edu reqDN: uid=brandonl,ou=user,dc=cpp,dc=edu reqResult: 0 reqMod: eduPersonAffiliation:= reqMod: eduPersonPrimaryAffiliation:= reqMod: cppEduPersonAffiliation:= reqMod: entryCSN:= 20170415103641.599920Z#000000#000#000000 reqMod: modifiersName:= cn=idmgmt,ou=user,ou=service,dc=cpp,dc=edu reqMod: modifyTimestamp:= 20170415103641Z reqEntryUUID: 8b33981d-25ee-4f7b-b439-41c273e94b61 entryUUID: b132db96-9ebe-4ee5-9fd2-5257b0c352d2 creatorsName: cn=accesslog createTimestamp: 20170415103641Z entryCSN: 20170415103641.599920Z#000000#000#000000 modifiersName: cn=accesslog modifyTimestamp: 20170415103641Z > - reqStart=20170416103057.000005Z,cn=accesslog dn: reqStart=20170416103057.000045Z,cn=accesslog objectClass: auditModify structuralObjectClass: auditModify reqStart: 20170416103057.000045Z reqEnd: 20170416103057.000046Z reqType: modify reqSession: 54887 reqAuthzID: cn=idmgmt,ou=user,ou=service,dc=cpp,dc=edu reqDN: uid=aaalmora,ou=user,dc=cpp,dc=edu reqResult: 0 reqMod: eduPersonAffiliation:= reqMod: eduPersonPrimaryAffiliation:= reqMod: cppEduPersonAffiliation:= reqMod: entryCSN:= 20170416103057.530384Z#000000#000#000000 reqMod: modifiersName:= cn=idmgmt,ou=user,ou=service,dc=cpp,dc=edu reqMod: modifyTimestamp:= 20170416103057Z reqEntryUUID: 153aa3e7-cc27-48ce-b6f2-e14215348941 entryCSN: 20170416103057.530384Z#000000#000#000000 entryUUID: b0c18fef-134e-4c8e-b073-fcdff58d3d93 creatorsName: cn=accesslog createTimestamp: 20170416103057Z modifiersName: cn=accesslog modifyTimestamp: 20170416103057Z > I assume you are still running the same code in production, correct? Yes. It actually crashed 4 days in a row :(, the two days I provided backtraces for and then the following two days. Just for something to do I slapcat'd the db and accesslog and reloaded it after the fourth day in case there was some weird mdb corruption or something. It hasn't crashed since, but it crashes randomly so that could be meaningless <sigh>. I wouldn't think reloaded the db would have affected finding the matching accesslog entries but that is something different than last time too. And of course now this is the non-optimized build. Thanks...

1 0

Re: (ITS#8609) segfault in mods.c - modify_add_values
by okuznik＠symas.com 19 Apr '17

19 Apr '17

On Sun, Apr 16, 2017 at 06:20:06PM +0000, henson(a)acm.org wrote: > On Mon, Apr 03, 2017 at 02:44:48PM +0100, Howard Chu wrote: >=20 >> You should probably switch to a non-optimized build. The backtrace you >> posted initially had most parameters optimized out, which also makes >> things harder to trace. >=20 > Well, as luck (8-/) would have it, it crashed both yesterday and today > on the non-optimized build. Here are the full backtraces from both > cores, I hope they provide some clue as to what's going on. Let me know > if you want me to do any more post mortem debugging on the cores. Thank= s > much. >=20 >=20 > Core was generated by `/usr/lib64/openldap/slapd -u ldap -g ldap -h lda= ps:// ldap://'. > Program terminated with signal SIGSEGV, Segmentation fault. > (gdb) bt full > #6 0x00000000004c84b4 in syncrepl_message_to_op (si=3D0x16e4630, op=3D= 0x7fac037fd730, msg=3D0x7fabfc4a1560) > at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.44-r1/work/ope= nldap-2.4.44/servers/slapd/syncrepl.c:2394 > #7 0x00000000004c31cd in do_syncrep2 (op=3D0x7fac037fd730, si=3D0x16e4= 630) > at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.44-r1/work/ope= nldap-2.4.44/servers/slapd/syncrepl.c:1013 > bdn =3D {bv_len =3D 44, bv_val =3D 0x7fabfc492bea "reqStart=3D2= 0170415103641.000016Z,cn=3Daccesslog"} >=20 >=20 > Core was generated by `/usr/lib64/openldap/slapd -u ldap -g ldap -h lda= ps:// ldap://'. > Program terminated with signal SIGSEGV, Segmentation fault. > (gdb) bt full > #6 0x00000000004c84b4 in syncrepl_message_to_op (si=3D0x1ea8970, op=3D= 0x7fa0b59f1730, msg=3D0x7fa0a012df60) > at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.44-r1/work/ope= nldap-2.4.44/servers/slapd/syncrepl.c:2394 > #7 0x00000000004c31cd in do_syncrep2 (op=3D0x7fa0b59f1730, si=3D0x1ea8= 970) > at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.44-r1/work/ope= nldap-2.4.44/servers/slapd/syncrepl.c:1013 > bdn =3D {bv_len =3D 44, bv_val =3D 0x7fa0a0422609 "reqStart=3D2= 0170416103057.000005Z,cn=3Daccesslog"} Hi Paul, could you post the two accesslog entries (or at least an outline) referenced in the backtrace? - reqStart=3D20170415103641.000016Z,cn=3Daccesslog - reqStart=3D20170416103057.000005Z,cn=3Daccesslog I assume you are still running the same code in production, correct? Thanks, Ondrej --=20 Ond=C5=99ej Kuzn=C3=ADk Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

Re: (ITS#8643) include/lber.h contains a typo
by quanah＠symas.com 18 Apr '17

18 Apr '17

--On Tuesday, April 18, 2017 3:19 PM +0000 vl(a)samba.org wrote: > Full_Name: Volker Lendecke > Version: master > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (77.22.212.41) > > > Tried to upload the patch to ftp.openldap.org according to > > http://www.openldap.org/devel/contributing.html#patches > > but got permission denied: > ># ftp ftp.openldap.org > Trying 23.92.27.230... > Connected to www.openldap.org. > 220 ProFTPD 1.3.4a Server (gauss) [::ffff:23.92.27.230] > Name (ftp.openldap.org:vlendec): ftp > 331 Anonymous login ok, send your complete email address as your password > Password: > 230 Anonymous access granted, restrictions apply > Remote system type is UNIX. > Using binary mode to transfer files. > ftp> put > (local-file) patch.txt > (remote-file) volker-lendecke-170418.txt > local: patch.txt remote: volker-lendecke-170418.txt > 229 Entering Extended Passive Mode (|||64436|) > 550 volker-lendecke-170418.txt: Permission denied > ftp> quit > > > The patch is simple: include/lber.h:176 contains "operarion" instead of > "operation". That should be fixed. Thanks for the report! As noted in the instructions for using FTP, you need to cd to the incoming directory before you can put the patch: % ftp ftp> open ftp.openldap.org User: ftp 331 Guest login ok, send your email address as password. Password: your-email-address Remote system type is UNIX. Using binary mode to transfer files. ftp> cd incoming 250 CWD command successful. ftp> As this is a very trivial typo fix, IPR bits don't need to apply. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#8643) include/lber.h contains a typo
by vl＠samba.org 18 Apr '17

18 Apr '17

Full_Name: Volker Lendecke Version: master OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (77.22.212.41) Tried to upload the patch to ftp.openldap.org according to http://www.openldap.org/devel/contributing.html#patches but got permission denied: # ftp ftp.openldap.org Trying 23.92.27.230... Connected to www.openldap.org. 220 ProFTPD 1.3.4a Server (gauss) [::ffff:23.92.27.230] Name (ftp.openldap.org:vlendec): ftp 331 Anonymous login ok, send your complete email address as your password Password: 230 Anonymous access granted, restrictions apply Remote system type is UNIX. Using binary mode to transfer files. ftp> put (local-file) patch.txt (remote-file) volker-lendecke-170418.txt local: patch.txt remote: volker-lendecke-170418.txt 229 Entering Extended Passive Mode (|||64436|) 550 volker-lendecke-170418.txt: Permission denied ftp> quit The patch is simple: include/lber.h:176 contains "operarion" instead of "operation". That should be fixed.

1 0

(ITS#8642) ./configure --without-thread compile failed on git master
by zhu.qunying＠gmail.com 18 Apr '17

18 Apr '17

Full_Name: Zhu, Qunying Version: git master OS: Linux (Slackware63 14.2) URL: Submission from: (NULL) (208.91.114.4) I will get the compile error of this: thr_stub.c:170:1: error: conflicting types for 'ldap_pvt_thread_pool_retract' ldap_pvt_thread_pool_retract ( ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ In file included from thr_stub.c:21:0: ../../include/ldap_pvt_thread.h:237:1: note: previous declaration of 'ldap_pvt_thread_pool_retract' was here ldap_pvt_thread_pool_retract LDAP_P(( ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ thr_stub.c:254:1: warning: return type defaults to 'int' [-Wimplicit-int] ldap_pvt_thread_pool_pausecheck( ldap_pvt_thread_pool_t *tpool ) It seems the check in e12ca8b6fed6b8a2526 for "Fixes for multiple threadpool queues" change the API but does not update the thr_stub.c definition.

1 0

Re: (ITS#6874) slapd crashes while modifying a database
by quanah＠symas.com 16 Apr '17

16 Apr '17

For historical reference, this was the config (Considered invalid) that caused the crash. # $Id: slapd.conf.tmp-ofd,v 1.2 2010/12/23 13:21:29 dieter Exp dieter $ #### Schemata, Reihenfolge wegen Abh??ngikeiten u.U. wichtig! ############################## # Globale Anweisungen # ############################## include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/rfc2307bis.schema include /etc/openldap/schema/authldap.schema include /etc/openldap/schema/openldap.schema include /etc/openldap/schema/dyngroup.schema include /etc/openldap/schema/dnszone.schema include /etc/openldap/schema/dhcp.schema include /etc/openldap/schema/ofdconf.schema include /etc/openldap/schema/yast.schema include /etc/openldap/schema/ofdaddon.schema pidfile /tmp2/ldap1/run/slapd.pid argsfile /tmp2/ldap1/run/slapd.args loglevel 0 threads 160 password-hash {CLEARTEXT} modulepath /usr/lib/openldap/modules moduleload accesslog.la moduleload dynlist.la moduleload memberof.la moduleload refint.la moduleload unique.la TLSCACertificateFile /etc/openldap/ssl/ldapca.pem TLSCertificateFile /etc/openldap/ssl/ldapcert.pem TLSCertificateKeyFile /etc/openldap/ssl/ldapkey.pem access to dn.base="" by * read access to dn.base="cn=Subschema" by * read include /etc/openldap/ofd.acl sizelimit -1 timelimit 4000 # allow bind_v2 ############################### # Config Database # ############################### database config rootdn cn=config rootpw secret ############################## # Erste Database # ############################## database hdb suffix "ou=humans,ou=steuer,o=landesverwaltung niedersachsen,c=de" subordinate advertise rootdn "cn=gen.man,ou=mgr,ou=steuer,o=landesverwaltung niedersachsen,c=de" directory /tmp2/ldap1/human-data checkpoint 4096 5 index default pres,eq index objectclass eq index mail sub,eq index sn sub,eq index cn sub,eq index entryCSN,entryUUID cachesize 5000 idlcachesize 15000 dbconfig set_cachesize 0 68157440 0 dbconfig set_lg_dir /tmp2/ldap1/log/bdb/human dbconfig set_lg_regionmax 262144 dbconfig set_lg_bsize 2097152 dbconfig set_flags DB_LOG_AUTOREMOVE overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 syncprov-reloadhint TRUE ############################### # Zweite Database # ############################### database hdb suffix "ou=system,ou=steuer,o=landesverwaltung niedersachsen,c=de" subordinate advertise rootdn "cn=gen.man,ou=mgr,ou=steuer,o=landesverwaltung niedersachsen,c=de" directory /tmp2/ldap1/sys-data checkpoint 4096 5 cachesize 5000 idlcachesize 1500 index objectclass eq index sn,cn,mail eq,sub index entryCSN,entryUUID eq dbconfig set_cachesize 0 68157440 0 dbconfig set_lg_dir /tmp2/ldap1/log/bdb/sys dbconfig set_lg_regionmax 262144 dbconfig set_lg_bsize 2097152 dbconfig set_flags DB_LOG_AUTOREMOVE overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 syncprov-reloadhint TRUE ########################## # Dritte Database # ########################## database hdb suffix "ou=steuer,o=landesverwaltung niedersachsen,c=de" rootdn "cn=gen.man,ou=mgr,ou=steuer,o=landesverwaltung niedersachsen,c=de" rootpw secret directory /tmp2/ldap1/main-data checkpoint 4096 5 cachesize 5000 idlcachesize 1500 dbconfig set_cachesize 0 68157440 0 dbconfig set_lg_dir /tmp2/ldap1/log/bdb/main dbconfig set_lg_regionmax 262144 dbconfig set_lg_bsize 2097152 dbconfig set_flags DB_LOG_AUTOREMOVE index objectClass eq index default pres,eq index mail,telephoneNumber index cn,sn,uid eq,sub index entryUUID,entryCSN eq overlay glue overlay accesslog logdb "cn=log" logops writes overlay syncprov syncprov-checkpoint 100 10 syncprov-reloadhint TRUE ############################ # Log Database # ############################ database hdb suffix "cn=log" directory /tmp2/ldap1/log-data rootdn cn=log checkpoint 10240 5 dbconfig set_cachesize 0 367001600 0 dbconfig set_lg_dir /tmp2/ldap1/log/bdb/log dbconfig set_lg_regionmax 262144 dbconfig set_lg_bsize 2097152 dbconfig set_flags DB_LOG_AUTOREMOVE index objectClass eq index reqStart,entryCSN,reqEnd,reqResult eq overlay syncprov syncprov-nopresent TRUE syncprov-checkpoint 100 10 ############################# # Monitor Database # ############################# database monitor # EOF -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8376)
by quanah＠symas.com 16 Apr '17

16 Apr '17

There are two problems with this ITS: a) It was not submitted for inclusion with the project by the original author (as generally required). I.e., 3rd party submissions are usually rejected. b) It lacks an IPR notice, which must come from the original author. If someone from SuSE can track down the original author, and have them follow up with the IPR information, then we can likely look to include it in a future release. <http://www.openldap.org/devel/contributing.html> may be a useful reference for the SuSE team for future issues. --Quanah --On Saturday, April 15, 2017 3:27 PM +0000 michael(a)stroeder.com wrote: > FWIW: The patch is still available here in openSUSE's package openldap2: > > https://build.opensuse.org/package/view_file/network:ldap/openldap2/0009- > Fix-ldap-host-lookup-ipv6.patch?expand=1 > > > > -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8609) segfault in mods.c - modify_add_values
by henson＠acm.org 16 Apr '17

16 Apr '17

On Mon, Apr 03, 2017 at 02:44:48PM +0100, Howard Chu wrote: > You should probably switch to a non-optimized build. The backtrace you > posted initially had most parameters optimized out, which also makes > things harder to trace. Well, as luck (8-/) would have it, it crashed both yesterday and today on the non-optimized build. Here are the full backtraces from both cores, I hope they provide some clue as to what's going on. Let me know if you want me to do any more post mortem debugging on the cores. Thanks much. Core was generated by `/usr/lib64/openldap/slapd -u ldap -g ldap -h ldaps:// ldap://'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x00000000004b8dbb in modify_add_values (e=0x7fac037fca30, mod=0x7fabfc000a90, permissive=0, text=0x7fac037fd000, textbuf=0x7fac037fca80 "modify/delete: eduPersonAffiliation: no such attribute", textlen=256) at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.44-r1/work/openldap-2.4.44/servers/slapd/mods.c:61 61 if ( !BER_BVISNULL( &mod->sm_values[mod->sm_numvals] )) { [Current thread is 1 (Thread 0x7fac037fe700 (LWP 1292))] (gdb) bt full #0 0x00000000004b8dbb in modify_add_values (e=0x7fac037fca30, mod=0x7fabfc000a90, permissive=0, text=0x7fac037fd000, textbuf=0x7fac037fca80 "modify/delete: eduPersonAffiliation: no such attribute", textlen=256) at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.44-r1/work/openldap-2.4.44/servers/slapd/mods.c:61 rc = -67095872 op = 0x5866e0 "add" a = 0x7fac037fc8a0 pmod = {sm_desc = 0x16d53c0, sm_values = 0x0, sm_nvalues = 0x0, sm_numvals = 0, sm_op = 0, sm_flags = 0, sm_type = {bv_len = 34, bv_val = 0x7fabfc000a78 "uid=bran\220\n"}} __PRETTY_FUNCTION__ = "modify_add_values" #1 0x00007fadf301c774 in mdb_modify_internal (op=0x7fac037fd730, tid=0x1a993c0, modlist=0x7fabfc000a50, e=0x7fac037fca30, text=0x7fac037fd000, textbuf=0x7fac037fca80 "modify/delete: eduPersonAffiliation: no such attribute", textlen=256) at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.44-r1/work/openldap-2.4.44/servers/slapd/back-mdb/modify.c:137 rc = 32684 err = 0 mod = 0x7fabfc000a90 ml = 0x7fabfc000a90 save_attrs = 0x7fabfc0032c0 ap = 0x7fac00000000 glue_attr_delete = 0 got_delete = 0 __PRETTY_FUNCTION__ = "mdb_modify_internal" #2 0x00007fadf301e5f2 in mdb_modify (op=0x7fac037fd730, rs=0x7fac037fcfe0) at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.44-r1/work/openldap-2.4.44/servers/slapd/back-mdb/modify.c:624 mdb = 0x7fadf7dbb010 e = 0x7fabfc003270 manageDSAit = 2 00\000\340\317\177\003\254\177\000\000\060\327\177\003\254\177\000\000 \313\177\003\254\177\000\000\000\000\000\000\260\000\000\000 \313\177\003\254\177\000\000\324\024\214\367\000\000\000\000(&\000\374\253\177\000\000\060\327\177\003\254\177\000\000p-n\001\000\000\000\000P/n\001\000\000\000\000\320%\000\374\253\177\000\000\370%\000\374\253\177\000\000`\322\177\003\254\177\000\000"... textlen = 256 txn = 0x1a993c0 opinfo = {moi_oe = {oe_next = {sle_next = 0x7fac037fcf90}, oe_key = 0x7fadf7dbb010}, moi_txn = 0x1a993c0, moi_ref = 1, moi_flag = 0 '\000'} moi = 0x7fac037fc9e0 dummy = {e_id = 171976, e_name = {bv_len = 34, bv_val = 0x7fabfc003240 "uid=brandonl,ou=user,dc=cpp,dc=edu"}, e_nname = {bv_len = 34, bv_val = 0x7fabfc003d20 "uid=brandonl,ou=user,dc=cpp,dc=edu"}, e_attrs = 0x7fac2442b588, e_ocflags = 256, e_bv = {bv_len = 0, bv_val = 0x0}, e_private = 0x7fabfc003270} preread_ctrl = 0x0 postread_ctrl = 0x0 ctrls = {0x0, 0x0, 0x7fabfc0009d0, 0x50, 0x0, 0x7fac037fc800} num_ctrls = 0 numads = 57 #3 0x00000000004dbc55 in overlay_op_walk (op=0x7fac037fd730, rs=0x7fac037fcfe0, which=op_modify, oi=0x16e2b90, on=0x0) at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.44-r1/work/openldap-2.4.44/servers/slapd/backover.c:677 func = 0x7fadf323ddd8 <bi+88> rc = 32768 #4 0x00000000004dbea0 in over_op_func (op=0x7fac037fd730, rs=0x7fac037fcfe0, which=op_modify) at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.44-r1/work/openldap-2.4.44/servers/slapd/backover.c:730 oi = 0x16e2b90 on = 0x16e3d20 be = 0x16d4b60 db = {bd_info = 0x7fadf323dd80 <bi>, bd_self = 0x16d4b60, ts 14 times>, "\001", be_flags = 563464, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 64}, be_suffix = 0x16d3bf0, be_nsuffix = 0x16d4270, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = {bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 25, bv_val = 0x16d4490 "cn=ldaproot,dc=cpp,dc=edu"}, be_rootndn = {bv_len = 25, bv_val = 0x16d44e0 "cn=ldaproot,dc=cpp,dc=edu"}, be_rootpw = { bv_len = 14, bv_val = 0x16a7a30 "XXXXXXXXXXX"}, be_max_deref_depth = 15, be_def_limit = { lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = -1, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x16d3b20, be_acl = 0x16d5eb0, be_dfltaccess = ACL_READ, be_extra_anlist = 0x0, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0x19966a0, be_pcl_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __elision = 0, __list = { __prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, be_syncinfo = 0x16e3970, be_pb = 0x0, be_cf_ocs = 0x7fadf323dac0 <mdbocs>, be_private = 0x7fadf7dbb010, be_next = {stqe_next = 0x0}} cb = {sc_next = 0x7fac037fcfb0, sc_response = 0x4daa2c <over_back_response>, sc_cleanup = 0x0, sc_writewait = 0x0, sc_private = 0x16e2b90} sc = 0x0 rc = 32768 __PRETTY_FUNCTION__ = "over_op_func" #5 0x00000000004dc003 in over_op_modify (op=0x7fac037fd730, rs=0x7fac037fcfe0) at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.44-r1/work/openldap-2.4.44/servers/slapd/backover.c:769 No locals. #6 0x00000000004c84b4 in syncrepl_message_to_op (si=0x16e4630, op=0x7fac037fd730, msg=0x7fabfc4a1560) at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.44-r1/work/openldap-2.4.44/servers/slapd/syncrepl.c:2394 oes = {oe = {oe_next = {sle_next = 0x0}, oe_key = 0x4c7516 <syncrepl_message_to_op>}, oe_si = 0x16e4630} ber = 0x7fabfc4a76a0 modlist = 0x7fabfc498e20 ls = 0x7dfc40 <accesslog_sc> rs = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x7fac037fca80 "modify/delete: eduPersonAffiliation: no such attribute", 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} cb = {sc_next = 0x7fabfc0025a0, sc_response = 0x4cfda6 <null_callback>, sc_cleanup = 0x0, sc_writewait = 0x0, sc_private = 0x0} text = 0xa <error: Cannot access memory at address 0xa> txtbuf = "\220\320\177\003\254\177\000\000\000\321\177\003\254\177\000\000\300\320\177\003\254\177\000\000\030\000\000\000\060\000\000\000p\321\177\003\254\177\000\000\260\320\177\003\254\177\000\000\000\000\000\000\003\000\000\000 \000\000\374\253\177\000\000\377\377\377\377\377\377\377\377\000\000\000\017\000\000\000\000\257\350\377+\254\177\000\000\000\000\000\000\000\000\000\000`\321\177\003\254\177\000\000\000\000\000\000\000\000\000\000\257\350\377+\254\177", '\000' <repeats 11 times>, "\347\177\003\254\177\000\000P\347M", '\000' <repeats 13 times>, "`\322\177\003\254\177\000\000OOq\374\253\177\000\000@Oq\374\253\177\000\000`\325e\001\000\000\000\000OOq\374\253\177\000\000HOq\374\253\177\000\000\000\000\000\000\000\000\000\000"... textlen = 256 bdn = {bv_len = 34, bv_val = 0x7fabfc492c3c "uid=brandonl,ou=user,dc=cpp,dc=edu"} dn = {bv_len = 34, bv_val = 0x7fabfc000d30 "\220\022"} ndn = {bv_len = 34, bv_val = 0x7fabfc000db0 "p\023"} bv = {bv_len = 0, bv_val = 0x0} bv2 = {bv_len = 0, bv_val = 0x0} bvals = 0x7fabfc41f360 rdn = {bv_len = 0, bv_val = 0x0} sup = {bv_len = 0, bv_val = 0x0} prdn = {bv_len = 0, bv_val = 0x0} nrdn = {bv_len = 0, bv_val = 0x0} psup = {bv_len = 0, bv_val = 0x0} nsup = {bv_len = 0, bv_val = 0x0} rc = 0 deleteOldRdn = 0 freeReqDn = 1 do_graduate = 1 #7 0x00000000004c31cd in do_syncrep2 (op=0x7fac037fd730, si=0x16e4630) at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.44-r1/work/openldap-2.4.44/servers/slapd/syncrepl.c:1013 match = 0 syncUUID = {{bv_len = 16, bv_val = 0x7fabfc4c8cd7 "7\245|\231:\352AM\246\305\066\037i&\201\232"}, { bv_len = 0, bv_val = 0x3000000020 <error: Cannot access memory at address 0x3000000020>}} cookie = {bv_len = 15, bv_val = 0x7fabfc4c8ce9 "rid=003,sid=003"} rctrls = 0x7fabfc49f8f0 rctrlp = 0x7fabfc492de0 bdn = {bv_len = 44, bv_val = 0x7fabfc492bea "reqStart=20170415103641.000016Z,cn=accesslog"} si_tag = 140376648999836 entry = 0x7fabfc49f8f8 punlock = -1 syncstate = 1 retdata = 0x570e74 retoid = 0x7fadf6ac95c0 "" syncUUIDs = 0x0 len = 15 berbuf = { buffer = "\002\000\001", '\000' <repeats 29 times>, "ЌL\374\253\177\000\000\370\214L\374\253\177\000\000\370\214L\374\253\177", '\000' <repeats 26 times>, "\020\000\000\000\254\177\000\000\060\327\177\003\254\177\000\000\200\323\177\003\254\177\000\000\260Э\367\255\177\000\000\030\n\000\374\001\000\000\000\000\061~\000\000\000\000\000\200\323\177\003\254\177\000\000\260Э\367\255\177\000\000H\327\177\003\254\177\000\000 \v\020\024\254\177\000\000\000\324\177\003\254\177\000\000\377J\260\367\255\177\000\000\300\323\177\003\001\000\000\000,\324\177\003\254\177\000\000\060\327\177\003\001\000\000\000\020\t\020"..., ialign = 65538, lalign = 65538, falign = 9.18382988e-41, dalign = 3.2380074297143616e-319, palign = 0x10002 <error: Cannot access memory at address 0x10002>} ber = 0x7fac037fd2e0 msg = 0x7fabfc4a1560 syncCookie = {ctxcsn = 0x0, sids = 0x0, numcsns = 0, rid = 3, octet_str = {bv_len = 15, bv_val = 0x7fabfc714f40 "rid=003,sid=003"}, sid = 3, sc_next = {stqe_next = 0x0}} syncCookie_req = {ctxcsn = 0x7fabfc40cfe0, sids = 0x7fabfc4b99f0, numcsns = 4, rid = 3, octet_str = { bv_len = 183, bv_val = 0x7fabfc41b880 "rid=003,sid=000,csn=20170415103641.410645Z#000000#000#000000;20151030223206.483980Z#000000#001#000000;20160115030222.053144Z#000000#002#000000;20170406033805.626505Z#000000#003#000000"}, sid = 0, sc_next = {stqe_next = 0x0}} rc = 0 err = 0 modlist = 0x0 m = 1426881987 tout_p = 0x7fac037fd210 tout = {tv_sec = 0, tv_usec = 0} refreshDeletes = 0 empty = "empty" __PRETTY_FUNCTION__ = "do_syncrep2" #8 0x00000000004c54c8 in do_syncrepl (ctx=0x7fac037fdbc0, arg=0x16e4b10) at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.44-r1/work/openldap-2.4.44/servers/slapd/syncrepl.c:1564 rtask = 0x16e4b10 si = 0x16e4630 conn = {c_struct_state = SLAP_C_UNINITIALIZED, c_conn_state = SLAP_C_INVALID, c_conn_idx = -1, c_sd = 0, c_close_reason = 0x0, c_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __elision = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, c_sb = 0x0, c_starttime = 0, c_activitytime = 0, c_connid = 18446744073709551615, c_peer_domain = {bv_len = 0, bv_val = 0x568650 ""}, c_peer_name = {bv_len = 0, bv_val = 0x568650 ""}, c_listener = 0x570900 <dummy_list>, c_sasl_bind_mech = {bv_len = 0, bv_val = 0x0}, c_sasl_dn = { bv_len = 0, bv_val = 0x0}, c_sasl_authz_dn = {bv_len = 0, bv_val = 0x0}, c_authz_backend = 0x0, c_authz_cookie = 0x0, c_authz = {sai_method = 0, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = { bv_len = 0, bv_val = 0x0}, sai_ndn = {bv_len = 0, bv_val = 0x0}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, c_protocol = 0, c_ops = { stqh_first = 0x0, stqh_last = 0x0}, c_pending_ops = {stqh_first = 0x0, stqh_last = 0x0}, c_write1_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __elision = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, c_write1_cv = {__data = {__lock = 0, __futex = 0, __total_seq = 0, __wakeup_seq = 0, __woken_seq = 0, __mutex = 0x0, __nwaiters = 0, __broadcast_seq = 0}, __size = '\000' <repeats 47 times>, __align = 0}, c_write2_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __elision = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, c_write2_cv = {__data = {__lock = 0, __futex = 0, __total_seq = 0, __wakeup_seq = 0, __woken_seq = 0, __mutex = 0x0, __nwaiters = 0, __broadcast_seq = 0}, __size = '\000' <repeats 47 times>, __align = 0}, c_currentber = 0x0, c_writers = 0, c_writing = 0 '\000', c_sasl_bind_in_progress = 0 '\000', c_writewaiter = 0 '\000', c_is_udp = 0 '\000', c_is_tls = 0 '\000', c_needs_tls_accept = 0 '\000', c_sasl_layers = 0 '\000', c_sasl_done = 0 '\000', c_sasl_authctx = 0x0, c_sasl_sockctx = 0x0, c_sasl_extra = 0x0, c_sasl_bindop = 0x0, c_pagedresults_state = {ps_be = 0x0, ps_size = 0, ps_count = 0, ps_cookie = 0, ps_cookieval = {bv_len = 0, bv_val = 0x0}}, c_n_ops_received = 0, c_n_ops_executing = 0, c_n_ops_pending = 0, c_n_ops_completed = 0, c_n_get = 0, c_n_read = 0, c_n_write = 0, c_extensions = 0x0, c_clientfunc = 0x0, c_clientarg = 0x0, c_send_ldap_result = 0x45801c <slap_send_ldap_result>, c_send_search_entry = 0x458cf0 <slap_send_search_entry>, c_send_search_reference = 0x45b0d8 <slap_send_search_reference>, c_send_ldap_extended = 0x45886d <slap_send_ldap_extended>, c_send_ldap_intermediate = 0x458ade <slap_send_ldap_intermediate>} opbuf = {ob_op = {o_hdr = 0x7fac037fd8a0, o_tag = 102, o_time = 1492252601, o_tincr = 74, o_bd = 0x7fac037fcc90, o_req_dn = {bv_len = 34, bv_val = 0x7fabfc492e70 "uid=brandonl,ou=user,dc=cpp,dc=edu"}, o_req_ndn = {bv_len = 34, bv_val = 0x7fabfc492ea0 "uid=brandonl,ou=user,dc=cpp,dc=edu"}, o_request = {oq_add = { rs_modlist = 0x7fabfc000a50, rs_e = 0x1}, oq_bind = {rb_method = -67106224, rb_cred = { bv_len = 1, bv_val = 0x0}, rb_edn = {bv_len = 0, bv_val = 0x0}, rb_ssf = 0, rb_mech = { bv_len = 0, bv_val = 0x0}}, oq_compare = {rs_ava = 0x7fabfc000a50}, oq_modify = { rs_mods = {rs_modlist = 0x7fabfc000a50, rs_no_opattrs = 1 '\001'}, rs_increment = 0}, oq_modrdn = {rs_mods = {rs_modlist = 0x7fabfc000a50, rs_no_opattrs = 1 '\001'}, rs_deleteoldrdn = 0, rs_newrdn = {bv_len = 0, bv_val = 0x0}, rs_nnewrdn = {bv_len = 0, bv_val = 0x0}, rs_newSup = 0x0, rs_nnewSup = 0x0}, oq_search = {rs_scope = -67106224, rs_deref = 32683, rs_slimit = 1, rs_tlimit = 0, rs_limit = 0x0, rs_attrsonly = 0, rs_attrs = 0x0, rs_filter = 0x0, rs_filterstr = {bv_len = 0, bv_val = 0x0}}, oq_abandon = { rs_msgid = -67106224}, oq_cancel = {rs_msgid = -67106224}, oq_extended = {rs_reqoid = { bv_len = 140376643996240, bv_val = 0x1 <error: Cannot access memory at address 0x1>}, rs_flags = 0, rs_reqdata = 0x0}, oq_pwdexop = {rs_extended = {rs_reqoid = { bv_len = 140376643996240, bv_val = 0x1 <error: Cannot access memory at address 0x1>}, rs_flags = 0, rs_reqdata = 0x0}, rs_old = {bv_len = 0, bv_val = 0x0}, rs_new = { bv_len = 0, bv_val = 0x0}, rs_mods = 0x0, rs_modtail = 0x0}}, o_abandon = 0, o_cancel = 0, o_groups = 0x0, o_do_not_cache = 0 '\000', o_is_auth_check = 0 '\000', o_dont_replicate = 0 '\000', o_acl_priv = ACL_NONE, o_nocaching = 0 '\000', o_delete_glue_parent = 0 '\000', o_no_schema_check = 1 '\001', o_no_subordinate_glue = 0 '\000', o_ctrlflag = '\000' <repeats 14 times>, "\002", '\000' <repeats 16 times>, o_controls = 0x7fac037fd9f0, o_authz = {sai_method = 0, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 25, bv_val = 0x16d4490 "cn=ldaproot,dc=cpp,dc=edu"}, sai_ndn = { bv_len = 25, bv_val = 0x16d44e0 "cn=ldaproot,dc=cpp,dc=edu"}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, o_ber = 0x0, o_res_ber = 0x0, o_callback = 0x7fabfc0025d0, o_ctrls = 0x0, o_csn = {bv_len = 40, bv_val = 0x7fabfc492ed0 "20170415103641.599920Z#000000#000#000000"}, o_private = 0x0, o_extra = {slh_first = 0x7fac037fc9e0}, o_next = {stqe_next = 0x0}}, ob_hdr = {oh_opid = 0, oh_connid = 3, oh_conn = 0x7fac037fd470, oh_msgid = 0, oh_protocol = 0, oh_tid = 140376769816320, oh_threadctx = 0x7fac037fdbc0, oh_tmpmemctx = 0x7fabfc0009d0, oh_tmpmfuncs = 0x7dfb80 <slap_sl_mfuncs>, oh_counters = 0x8156c0 <slap_counters>, oh_log_prefix = "conn=-1 op=0", '\000' <repeats 243 times>, oh_extensions = 0x0}, ob_controls = { 0x0 <repeats 17 times>, 0x7fac037fd260, 0x0 <repeats 14 times>}} op = 0x7fac037fd730 rc = 0 dostop = 0 s = 13 i = -141804259 defer = 1 fail = 0 freeinfo = 0 be = 0x16d4b60 #9 0x0000000000440411 in connection_read_thread (ctx=0x7fac037fdbc0, argv=0xd) at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.44-r1/work/openldap-2.4.44/servers/slapd/connection.c:1296 rc = 0 cri = {op = 0x0, func = 0x4c4ec6 <do_syncrepl>, arg = 0x16e4b10, ctx = 0x7fac037fdbc0, nullop = 0} s = 13 #10 0x00007fadf7adba4b in ldap_int_thread_pool_wrapper (xpool=0x1667330) at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.44-r1/work/openldap-2.4.44/libraries/libldap_r/tpool.c:696 pool = 0x1667330 task = 0x7fac0c339570 work_list = 0x16673c8 ctx = {ltu_id = 140376769816320, ltu_key = {{ltk_key = 0x43f808 <conn_counter_init>, ltk_data = 0x7fabfc0008c0, ltk_free = 0x43f65a <conn_counter_destroy>}, { ltk_key = 0x4ba0e3 <slap_sl_mem_init>, ltk_data = 0x7fabfc0009d0, ltk_free = 0x4b9f08 <slap_sl_mem_destroy>}, {ltk_key = 0x1996710, ltk_data = 0x7fabfc100a20, ltk_free = 0x7fadf303113d <mdb_reader_free>}, {ltk_key = 0x7fadf3025bce <search_stack>, ltk_data = 0x7fac00ffc010, ltk_free = 0x7fadf3025bab <search_stack_free>}, { ltk_key = 0x7fadf30224aa <scope_chunk_get>, ltk_data = 0x7fabfc1028b0, ltk_free = 0x7fadf3022462 <scope_chunk_free>}, {ltk_key = 0x45c638 <slap_op_free>, ltk_data = 0x7fabf456a930, ltk_free = 0x45c58b <slap_op_q_destroy>}, {ltk_key = 0x178fe70, ltk_data = 0x7fabfc49f9a0, ltk_free = 0x7fadf303113d <mdb_reader_free>}, {ltk_key = 0x0, ltk_data = 0x7fabf44f5db0, ltk_free = 0x0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0x0} <repeats 24 times>}} kctx = 0x0 i = 32 keyslot = 948 hash = 3735031732 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #11 0x00007fadf7124494 in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #12 0x00007fadf6817edd in clone () from /lib64/libc.so.6 No symbol table info available. Core was generated by `/usr/lib64/openldap/slapd -u ldap -g ldap -h ldaps:// ldap://'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x00000000004b8dbb in modify_add_values (e=0x7fa0b59f0a30, mod=0x7fa0a0000980, permissive=0, text=0x7fa0b59f1000, textbuf=0x7fa0b59f0a80 "modify/delete: eduPersonAffiliation: no such attribute", textlen=256) at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.44-r1/work/openldap-2.4.44/servers/slapd/mods.c:61 61 if ( !BER_BVISNULL( &mod->sm_values[mod->sm_numvals] )) { [Current thread is 1 (Thread 0x7fa0b59f2700 (LWP 10464))] (gdb) bt full #0 0x00000000004b8dbb in modify_add_values (e=0x7fa0b59f0a30, mod=0x7fa0a0000980, permissive=0, text=0x7fa0b59f1000, textbuf=0x7fa0b59f0a80 "modify/delete: eduPersonAffiliation: no such attribute", textlen=256) at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.44-r1/work/openldap-2.4.44/servers/slapd/mods.c:61 rc = -1610599912 op = 0x5866e0 "add" a = 0x7fa0b59f08a0 pmod = {sm_desc = 0x1e9a3c0, sm_values = 0x0, sm_nvalues = 0x0, sm_numvals = 0, sm_op = 0, sm_flags = 0, sm_type = {bv_len = 34, bv_val = 0x7fa0a0000968 "uid=aaal\200\t"}} __PRETTY_FUNCTION__ = "modify_add_values" #1 0x00007fa277718774 in mdb_modify_internal (op=0x7fa0b59f1730, tid=0x225e3c0, modlist=0x7fa0a0000940, e=0x7fa0b59f0a30, text=0x7fa0b59f1000, textbuf=0x7fa0b59f0a80 "modify/delete: eduPersonAffiliation: no such attribute", textlen=256) at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.44-r1/work/openldap-2.4.44/servers/slapd/back-mdb/modify.c:137 rc = 32672 err = 0 mod = 0x7fa0a0000980 ml = 0x7fa0a0000980 save_attrs = 0x7fa0a0003218 ap = 0x7fa000000000 glue_attr_delete = 0 got_delete = 0 __PRETTY_FUNCTION__ = "mdb_modify_internal" #2 0x00007fa27771a5f2 in mdb_modify (op=0x7fa0b59f1730, rs=0x7fa0b59f0fe0) at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.44-r1/work/openldap-2.4.44/servers/slapd/back-mdb/modify.c:624 mdb = 0x7fa27c4b7010 e = 0x7fa0a00031c8 manageDSAit = 2 \000\340\017\237\265\240\177\000\000\060\027\237\265\240\177\000\000 \v\237\265\240\177\000\000\000\000\000\000\260\000\000\000 \v\237\265\240\177\000\000\324\324\373{\000\000\000\000\030%\000\240\240\177\000\000\060\027\237\265\240\177\000\000p}\352\001\000\000\000\000P\177\352\001\000\000\000\000\300$\000\240\240\177\000\000\350$\000\240\240\177\000\000`\022\237\265\240\177\000\000"... textlen = 256 txn = 0x225e3c0 opinfo = {moi_oe = {oe_next = {sle_next = 0x7fa0b59f0f90}, oe_key = 0x7fa27c4b7010}, moi_txn = 0x225e3c0, moi_ref = 1, moi_flag = 0 '\000'} moi = 0x7fa0b59f09e0 dummy = {e_id = 200434, e_name = {bv_len = 34, bv_val = 0x7fa0a0003198 "uid=aaalmora,ou=user,dc=cpp,dc=edu"}, e_nname = {bv_len = 34, bv_val = 0x7fa0a0003ce0 "uid=aaalmora,ou=user,dc=cpp,dc=edu"}, e_attrs = 0x7fa098ba4938, e_ocflags = 256, e_bv = {bv_len = 0, bv_val = 0x0}, e_private = 0x7fa0a00031c8} preread_ctrl = 0x0 postread_ctrl = 0x0 ctrls = {0x0, 0x0, 0x7fa0a00008c0, 0x50, 0x0, 0x7fa0b59f0800} num_ctrls = 0 numads = 57 #3 0x00000000004dbc55 in overlay_op_walk (op=0x7fa0b59f1730, rs=0x7fa0b59f0fe0, which=op_modify, oi=0x1ea7b90, on=0x0) at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.44-r1/work/openldap-2.4.44/servers/slapd/backover.c:677 func = 0x7fa277939dd8 <bi+88> rc = 32768 #4 0x00000000004dbea0 in over_op_func (op=0x7fa0b59f1730, rs=0x7fa0b59f0fe0, which=op_modify) at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.44-r1/work/openldap-2.4.44/servers/slapd/backover.c:730 oi = 0x1ea7b90 on = 0x1ea8d20 be = 0x1e99b60 db = {bd_info = 0x7fa277939d80 <bi>, bd_self = 0x1e99b60, ts 14 times>, "\001", be_flags = 563464, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 64}, be_suffix = 0x1e98bf0, be_nsuffix = 0x1e99270, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = {bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 25, bv_val = 0x1e99490 "cn=ldaproot,dc=cpp,dc=edu"}, be_rootndn = {bv_len = 25, bv_val = 0x1e994e0 "cn=ldaproot,dc=cpp,dc=edu"}, be_rootpw = { bv_len = 14, bv_val = 0x1e6ca30 "XXXXXXXXXXXX"}, be_max_deref_depth = 15, be_def_limit = { lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = -1, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x1e98b20, be_acl = 0x1e9aeb0, be_dfltaccess = ACL_READ, be_extra_anlist = 0x0, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0x215b6a0, be_pcl_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __elision = 0, __list = { __prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, be_syncinfo = 0x1ea8970, be_pb = 0x0, be_cf_ocs = 0x7fa277939ac0 <mdbocs>, be_private = 0x7fa27c4b7010, be_next = {stqe_next = 0x0}} cb = {sc_next = 0x7fa0b59f0fb0, sc_response = 0x4daa2c <over_back_response>, sc_cleanup = 0x0, sc_writewait = 0x0, sc_private = 0x1ea7b90} sc = 0x0 rc = 32768 __PRETTY_FUNCTION__ = "over_op_func" #5 0x00000000004dc003 in over_op_modify (op=0x7fa0b59f1730, rs=0x7fa0b59f0fe0) at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.44-r1/work/openldap-2.4.44/servers/slapd/backover.c:769 No locals. #6 0x00000000004c84b4 in syncrepl_message_to_op (si=0x1ea8970, op=0x7fa0b59f1730, msg=0x7fa0a012df60) at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.44-r1/work/openldap-2.4.44/servers/slapd/syncrepl.c:2394 oes = {oe = {oe_next = {sle_next = 0x0}, oe_key = 0x4c7516 <syncrepl_message_to_op>}, oe_si = 0x1ea8970} ber = 0x7fa0a029eb70 modlist = 0x7fa0a0127460 ls = 0x7dfc40 <accesslog_sc> rs = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x7fa0b59f0a80 "modify/delete: eduPersonAffiliation: no such attribute", 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} cb = {sc_next = 0x7fa0a0002490, sc_response = 0x4cfda6 <null_callback>, sc_cleanup = 0x0, sc_writewait = 0x0, sc_private = 0x0} text = 0xa <error: Cannot access memory at address 0xa> txtbuf = "\220\020\237\265\240\177\000\000\000\021\237\265\240\177\000\000\300\020\237\265\240\177\000\000\030\000\000\000\060\000\000\000p\021\237\265\240\177\000\000\260\020\237\265\240\177\000\000\000\000\000\000\003\000\000\000 \000\000\240\240\177\000\000\377\377\377\377\377\377\377\377\000\000\000\017\000\000\000\000?\034\237\266\240\177\000\000\000\000\000\000\000\000\000\000`\021\237\265\240\177\000\000\000\000\000\000\000\000\000\000?\034\237\266\240\177", '\000' <repeats 11 times>, "'\237\265\240\177\000\000P\347M", '\000' <repeats 13 times>, "`\022\237\265\240\177\000\000\177\233\023\240\240\177\000\000p\233\023\240\240\177\000\000`%\342\001\000\000\000\000\177\233\023\240\240\177\000\000x\233\023\240\240\177\000\000\000\000\000\000\000\000\000\000"... textlen = 256 bdn = {bv_len = 34, bv_val = 0x7fa0a042265b "uid=aaalmora,ou=user,dc=cpp,dc=edu"} dn = {bv_len = 34, bv_val = 0x7fa0a0000c20 "\310\021"} ndn = {bv_len = 34, bv_val = 0x7fa0a0000ca0 "\250\022"} bv = {bv_len = 0, bv_val = 0x0} bv2 = {bv_len = 0, bv_val = 0x0} bvals = 0x7fa0a0106580 rdn = {bv_len = 0, bv_val = 0x0} sup = {bv_len = 0, bv_val = 0x0} prdn = {bv_len = 0, bv_val = 0x0} nrdn = {bv_len = 0, bv_val = 0x0} psup = {bv_len = 0, bv_val = 0x0} nsup = {bv_len = 0, bv_val = 0x0} rc = 0 deleteOldRdn = 0 freeReqDn = 1 do_graduate = 1 #7 0x00000000004c31cd in do_syncrep2 (op=0x7fa0b59f1730, si=0x1ea8970) at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.44-r1/work/openldap-2.4.44/servers/slapd/syncrepl.c:1013 match = 0 syncUUID = {{bv_len = 16, bv_val = 0x7fa0a0144147 "4w\232m2\230F>\273\200\032\350\227o\252i"}, { bv_len = 0, bv_val = 0x3000000020 <error: Cannot access memory at address 0x3000000020>}} cookie = {bv_len = 15, bv_val = 0x7fa0a0144159 "rid=001,sid=001"} rctrls = 0x7fa0a0111800 rctrlp = 0x7fa0a0157460 bdn = {bv_len = 44, bv_val = 0x7fa0a0422609 "reqStart=20170416103057.000005Z,cn=accesslog"} si_tag = 140327924125852 entry = 0x7fa0a0111808 punlock = -1 syncstate = 1 retdata = 0x570e74 retoid = 0x7fa27b1c55c0 "" syncUUIDs = 0x0 len = 15 berbuf = { buffer = "\002\000\001", '\000' <repeats 29 times>, "@A\024\240\240\177\000\000hA\024\240\240\177\000\000hA\024\240\240\177", '\000' <repeats 26 times>, "\017\000\000\000\240\177\000\000\060\027\237\265\240\177\000\000\200\023\237\265\240\177\000\000\260\220\035|\242\177\000\000\b\t\000\240\001\000\000\000\000\061~\000\000\000\000\000\200\023\237\265\240\177\000\000\260\220\035|\242\177\000\000H\027\237\265\240\177\000\000 \v\020\230\240\177\000\000\000\024\237\265\240\177\000\000\377\n |\242\177\000\000\300\023\237\265\001\000\000\000,\024\237\265\240\177\000\000\060\027\237\265\001\000\000\000"..., ialign = 65538, lalign = 65538, falign = 9.18382988e-41, dalign = 3.2380074297143616e-319, palign = 0x10002 <error: Cannot access memory at address 0x10002>} ber = 0x7fa0b59f12e0 msg = 0x7fa0a012df60 syncCookie = {ctxcsn = 0x0, sids = 0x0, numcsns = 0, rid = 1, octet_str = {bv_len = 15, bv_val = 0x7fa0a0139b70 "rid=001,sid=001"}, sid = 1, sc_next = {stqe_next = 0x0}} syncCookie_req = {ctxcsn = 0x7fa0a04230d0, sids = 0x7fa0a012bb00, numcsns = 4, rid = 1, octet_str = { bv_len = 183, bv_val = 0x7fa0a015e3f0 "rid=001,sid=000,csn=20170416081903.399068Z#000000#000#000000;20170416051743.054642Z#000000#001#000000;20160115030222.053144Z#000000#002#000000;20170416043935.843860Z#000000#003#000000"}, sid = 0, sc_next = {stqe_next = 0x0}} rc = 0 err = 0 modlist = 0x0 m = 1426881987 tout_p = 0x7fa0b59f1210 tout = {tv_sec = 0, tv_usec = 0} refreshDeletes = 0 empty = "empty" __PRETTY_FUNCTION__ = "do_syncrep2" #8 0x00000000004c54c8 in do_syncrepl (ctx=0x7fa0b59f1bc0, arg=0x1ea3e70) at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.44-r1/work/openldap-2.4.44/servers/slapd/syncrepl.c:1564 rtask = 0x1ea3e70 si = 0x1ea8970 conn = {c_struct_state = SLAP_C_UNINITIALIZED, c_conn_state = SLAP_C_INVALID, c_conn_idx = -1, c_sd = 0, c_close_reason = 0x0, c_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __elision = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, c_sb = 0x0, c_starttime = 0, c_activitytime = 0, c_connid = 18446744073709551615, c_peer_domain = {bv_len = 0, bv_val = 0x568650 ""}, c_peer_name = {bv_len = 0, bv_val = 0x568650 ""}, c_listener = 0x570900 <dummy_list>, c_sasl_bind_mech = {bv_len = 0, bv_val = 0x0}, c_sasl_dn = { bv_len = 0, bv_val = 0x0}, c_sasl_authz_dn = {bv_len = 0, bv_val = 0x0}, c_authz_backend = 0x0, c_authz_cookie = 0x0, c_authz = {sai_method = 0, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = { bv_len = 0, bv_val = 0x0}, sai_ndn = {bv_len = 0, bv_val = 0x0}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, c_protocol = 0, c_ops = { stqh_first = 0x0, stqh_last = 0x0}, c_pending_ops = {stqh_first = 0x0, stqh_last = 0x0}, c_write1_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __elision = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, c_write1_cv = {__data = {__lock = 0, __futex = 0, __total_seq = 0, __wakeup_seq = 0, __woken_seq = 0, __mutex = 0x0, __nwaiters = 0, __broadcast_seq = 0}, __size = '\000' <repeats 47 times>, __align = 0}, c_write2_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __elision = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, c_write2_cv = {__data = {__lock = 0, __futex = 0, __total_seq = 0, __wakeup_seq = 0, __woken_seq = 0, __mutex = 0x0, __nwaiters = 0, __broadcast_seq = 0}, __size = '\000' <repeats 47 times>, __align = 0}, c_currentber = 0x0, c_writers = 0, c_writing = 0 '\000', c_sasl_bind_in_progress = 0 '\000', c_writewaiter = 0 '\000', c_is_udp = 0 '\000', c_is_tls = 0 '\000', c_needs_tls_accept = 0 '\000', c_sasl_layers = 0 '\000', c_sasl_done = 0 '\000', c_sasl_authctx = 0x0, c_sasl_sockctx = 0x0, c_sasl_extra = 0x0, c_sasl_bindop = 0x0, c_pagedresults_state = {ps_be = 0x0, ps_size = 0, ps_count = 0, ps_cookie = 0, ps_cookieval = {bv_len = 0, bv_val = 0x0}}, c_n_ops_received = 0, c_n_ops_executing = 0, c_n_ops_pending = 0, c_n_ops_completed = 0, c_n_get = 0, c_n_read = 0, c_n_write = 0, c_extensions = 0x0, c_clientfunc = 0x0, c_clientarg = 0x0, c_send_ldap_result = 0x45801c <slap_send_ldap_result>, c_send_search_entry = 0x458cf0 <slap_send_search_entry>, c_send_search_reference = 0x45b0d8 <slap_send_search_reference>, c_send_ldap_extended = 0x45886d <slap_send_ldap_extended>, c_send_ldap_intermediate = 0x458ade <slap_send_ldap_intermediate>} opbuf = {ob_op = {o_hdr = 0x7fa0b59f18a0, o_tag = 102, o_time = 1492338657, o_tincr = 65, o_bd = 0x7fa0b59f0c90, o_req_dn = {bv_len = 34, bv_val = 0x7fa0a0160390 "uid=aaalmora,ou=user,dc=cpp,dc=edu"}, o_req_ndn = {bv_len = 34, bv_val = 0x7fa0a0127430 "uid=aaalmora,ou=user,dc=cpp,dc=edu"}, o_request = {oq_add = { rs_modlist = 0x7fa0a0000940, rs_e = 0x1}, oq_bind = {rb_method = -1610610368, rb_cred = { bv_len = 1, bv_val = 0x0}, rb_edn = {bv_len = 0, bv_val = 0x0}, rb_ssf = 0, rb_mech = { bv_len = 0, bv_val = 0x0}}, oq_compare = {rs_ava = 0x7fa0a0000940}, oq_modify = { rs_mods = {rs_modlist = 0x7fa0a0000940, rs_no_opattrs = 1 '\001'}, rs_increment = 0}, oq_modrdn = {rs_mods = {rs_modlist = 0x7fa0a0000940, rs_no_opattrs = 1 '\001'}, rs_deleteoldrdn = 0, rs_newrdn = {bv_len = 0, bv_val = 0x0}, rs_nnewrdn = {bv_len = 0, bv_val = 0x0}, rs_newSup = 0x0, rs_nnewSup = 0x0}, oq_search = {rs_scope = -1610610368, rs_deref = 32672, rs_slimit = 1, rs_tlimit = 0, rs_limit = 0x0, rs_attrsonly = 0, rs_attrs = 0x0, rs_filter = 0x0, rs_filterstr = {bv_len = 0, bv_val = 0x0}}, oq_abandon = { rs_msgid = -1610610368}, oq_cancel = {rs_msgid = -1610610368}, oq_extended = {rs_reqoid = { bv_len = 140327855851840, bv_val = 0x1 <error: Cannot access memory at address 0x1>}, rs_flags = 0, rs_reqdata = 0x0}, oq_pwdexop = {rs_extended = {rs_reqoid = { bv_len = 140327855851840, bv_val = 0x1 <error: Cannot access memory at address 0x1>}, rs_flags = 0, rs_reqdata = 0x0}, rs_old = {bv_len = 0, bv_val = 0x0}, rs_new = { bv_len = 0, bv_val = 0x0}, rs_mods = 0x0, rs_modtail = 0x0}}, o_abandon = 0, o_cancel = 0, o_groups = 0x0, o_do_not_cache = 0 '\000', o_is_auth_check = 0 '\000', o_dont_replicate = 0 '\000', o_acl_priv = ACL_NONE, o_nocaching = 0 '\000', o_delete_glue_parent = 0 '\000', o_no_schema_check = 1 '\001', o_no_subordinate_glue = 0 '\000', o_ctrlflag = '\000' <repeats 14 times>, "\002", '\000' <repeats 16 times>, o_controls = 0x7fa0b59f19f0, o_authz = {sai_method = 0, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 25, bv_val = 0x1e99490 "cn=ldaproot,dc=cpp,dc=edu"}, sai_ndn = { bv_len = 25, bv_val = 0x1e994e0 "cn=ldaproot,dc=cpp,dc=edu"}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, o_ber = 0x0, o_res_ber = 0x0, o_callback = 0x7fa0a00024c0, o_ctrls = 0x0, o_csn = {bv_len = 40, bv_val = 0x7fa0a0109a60 "20170416103057.530384Z#000000#000#000000"}, o_private = 0x0, o_extra = {slh_first = 0x7fa0b59f09e0}, o_next = {stqe_next = 0x0}}, ob_hdr = {oh_opid = 0, oh_connid = 1, oh_conn = 0x7fa0b59f1470, oh_msgid = 0, oh_protocol = 0, oh_tid = 140328218601216, oh_threadctx = 0x7fa0b59f1bc0, oh_tmpmemctx = 0x7fa0a00008c0, oh_tmpmfuncs = 0x7dfb80 <slap_sl_mfuncs>, oh_counters = 0x8156c0 <slap_counters>, oh_log_prefix = "conn=-1 op=0", '\000' <repeats 243 times>, oh_extensions = 0x0}, ob_controls = { 0x0 <repeats 17 times>, 0x7fa0b59f1260, 0x0 <repeats 14 times>}} op = 0x7fa0b59f1730 rc = 0 dostop = 0 s = 18 i = 2080111901 defer = 1 fail = 0 freeinfo = 0 be = 0x1e99b60 #9 0x0000000000440411 in connection_read_thread (ctx=0x7fa0b59f1bc0, argv=0x12) at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.44-r1/work/openldap-2.4.44/servers/slapd/connection.c:1296 rc = 0 cri = {op = 0x0, func = 0x4c4ec6 <do_syncrepl>, arg = 0x1ea3e70, ctx = 0x7fa0b59f1bc0, nullop = 0} s = 18 #10 0x00007fa27c1d7a4b in ldap_int_thread_pool_wrapper (xpool=0x1e2c330) at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.44-r1/work/openldap-2.4.44/libraries/libldap_r/tpool.c:696 pool = 0x1e2c330 task = 0x7fa0b0000e40 work_list = 0x1e2c3c8 ctx = {ltu_id = 140328218601216, ltu_key = {{ltk_key = 0x4ba0e3 <slap_sl_mem_init>, ltk_data = 0x7fa0a00008c0, ltk_free = 0x4b9f08 <slap_sl_mem_destroy>}, {ltk_key = 0x215b710, ltk_data = 0x7fa0a0ba3eb0, ltk_free = 0x7fa27772d13d <mdb_reader_free>}, { ltk_key = 0x7fa277721bce <search_stack>, ltk_data = 0x7fa096fff010, ltk_free = 0x7fa277721bab <search_stack_free>}, {ltk_key = 0x7fa27771e4aa <scope_chunk_get>, ltk_data = 0x7fa0a0ba5d40, ltk_free = 0x7fa27771e462 <scope_chunk_free>}, { ltk_key = 0x43f808 <conn_counter_init>, ltk_data = 0x7fa0a012d4f0, ltk_free = 0x43f65a <conn_counter_destroy>}, {ltk_key = 0x45c638 <slap_op_free>, ltk_data = 0x7fa0a825ab60, ltk_free = 0x45c58b <slap_op_q_destroy>}, {ltk_key = 0x1f54e70, ltk_data = 0x7fa0a01c3fa0, ltk_free = 0x7fa27772d13d <mdb_reader_free>}, {ltk_key = 0x0, ltk_data = 0x7fa09c04d880, ltk_free = 0x0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0x0} <repeats 24 times>}} kctx = 0x0 i = 32 keyslot = 634 hash = 3535879802 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #11 0x00007fa27b820494 in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #12 0x00007fa27af13edd in clone () from /lib64/libc.so.6 No symbol table info available.

1 0

Re: (ITS#8641) LBER_OPT_MEMORY_FNS not working
by Hallvard B Furuseth 16 Apr '17

16 Apr '17

This works as intended: ber_int_memory_fns is only used when passing ctx!=NULL to ber_memalloc_x() & co. slapd/sl_malloc.c does this. ber_memalloc() & co do not use it: As you say, they pass ctx=NULL. Closing this ITS.

1 0

(ITS#8641) LBER_OPT_MEMORY_FNS not working
by wwindcloud＠gmail.com 16 Apr '17

16 Apr '17

Full_Name: Version: All Version OS: Linux URL: Submission from: (NULL) (2001:ce0:2201:83a:7daa:5345:459e:3cec) LBER_OPT_MEMORY_FNS doesn't work at all. In memory.c, it was checking the presence of both ber_int_memory_fns and ctx the same time. However ctx was default to NULL all the time, so that's making this option not working at all. I suggest removing all ctx == NULL in memory.c, that way LBER_OPT_MEMORY_FNS should work as intended. Right now, it's unusable. Thanks.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs