openldap-bugs

openldap-bugs@openldap.org

1 participants
20965 discussions

(ITS#8428) slapd segfaults under load when back-relay is used
by andrew.howard＠anu.edu.au 17 May '16

17 May '16

Full_Name: Andrew Howard Version: 2.4.40 OS: Centos 7 3.10.0-327.18.2.el7.x86_6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (150.203.248.180) When using back-relay slapd segfaults after a few minutes. To reproduce: I run 5 instances of getent passwd;getent group on a system using nslcd pointing to the openldap server and then a loop of ldapsearch -x -LLL -h acmeldap1.acme.org.au -b "dc=newacme,dc=edu,dc=au" causes slapd to segfault in a few minutes. [root@acmeldap1 ~]# gdb /usr/sbin/slapd GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-80.el7 Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /usr/sbin/slapd...Reading symbols from /usr/lib/debug/usr/sbin/slapd.debug...done. done. (gdb) run -u ldap -h "ldap:/// ldapi:///" -d 0 The program being debugged has been started already. Start it from the beginning? (y or n) y Starting program: /usr/sbin/slapd -u ldap -h "ldap:/// ldapi:///" -d 0 [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". May 18 15:02:21 acmeldap1 slapd[12262]: @(#) $OpenLDAP: slapd 2.4.40 (Mar 31 2016 15:24:52) $#012#011mockbuild@worker1.bsys.centos.org:/builddir/build/BUILD/openldap-2.4.40/openldap-2.4.%2/servers/slapd [New Thread 0x7fff37ea2700 (LWP 12263)] [New Thread 0x7fff376a1700 (LWP 12264)] [New Thread 0x7fff36ea0700 (LWP 12265)] [New Thread 0x7fff36499700 (LWP 12266)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fff36499700 (LWP 12266)] 0x00007fff36498960 in ?? () (gdb) thread apply all bt Thread 5 (Thread 0x7fff36499700 (LWP 12266)): #0 0x00007fff36498960 in ?? () #1 0x00005555555a8541 in slap_writewait_play (op=0x7fff200026f0) at result.c:294 #2 send_ldap_ber (op=op@entry=0x7fff200026f0, ber=ber@entry=0x7fff36306eb0) at result.c:367 #3 0x00005555555ac11c in slap_send_search_entry (op=0x7fff200026f0, rs=<optimized out>) at result.c:1430 #4 0x0000555555645398 in mdb_search (op=<optimized out>, rs=<optimized out>) at search.c:1072 #5 0x0000555555606926 in overlay_op_walk (op=op@entry=0x7fff200026f0, rs=0x7fff36498960, which=op_search, oi=0x555555acaf90, on=0x0) at backover.c:671 #6 0x0000555555606a94 in over_op_func (op=0x7fff200026f0, rs=<optimized out>, which=<optimized out>) at backover.c:723 #7 0x00007ffff3ec1d16 in relay_back_op (op=0x7fff200026f0, rs=0x7fff36498960, which=<optimized out>) at op.c:210 #8 0x0000555555606926 in overlay_op_walk (op=op@entry=0x7fff200026f0, rs=0x7fff36496960, which=op_search, oi=0x555555aaf250, on=0x0) at backover.c:671 #9 0x0000555555606a94 in over_op_func (op=0x7fff200026f0, rs=<optimized out>, which=<optimized out>) at backover.c:723 #10 0x000055555559ad31 in fe_op_search (op=0x7fff200026f0, rs=0x7fff36498960) at search.c:402 #11 0x000055555559a5e6 in do_search (op=<optimized out>, rs=<optimized out>) at search.c:247 #12 0x0000555555597cbc in connection_operation (ctx=ctx@entry=0x7fff36498bd0, arg_v=arg_v@entry=0x7fff200026f0) at connection.c:1155 #13 0x000055555559802b in connection_read_thread (ctx=0x7fff36498bd0, argv=0x12) at connection.c:1291 #14 0x00007ffff7b92eda in ldap_int_thread_pool_wrapper (xpool=0x5555559ef2f0) at tpool.c:688 #15 0x00007ffff6e5adc5 in start_thread (arg=0x7fff36499700) at pthread_create.c:308 #16 0x00007ffff631bced in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 Thread 4 (Thread 0x7fff36ea0700 (LWP 12265)): #0 0x00007ffff6e6150d in connect () at ../sysdeps/unix/syscall-template.S:81 #1 0x00007ffff7baa9bc in ldap_pvt_connect (async=0, addrlen=16, sin=0x7fff2c100cf0, s=17, ld=0x7fff2c100910) at os-ip.c:443 #2 ldap_connect_to_host (ld=ld@entry=0x7fff2c100910, sb=0x7fff2c108d30, proto=proto@entry=1, srv=srv@entry=0x7fff2c108e00, async=async@entry=0) at os-ip.c:657 #3 0x00007ffff7b9430e in ldap_int_open_connection (ld=ld@entry=0x7fff2c100910, conn=conn@entry=0x7fff2c108d60, srv=0x7fff2c108e00, async=async@entry=0) at open.c:379 #4 0x00007ffff7ba7bbd in ldap_new_connection (ld=ld@entry=0x7fff2c100910, srvlist=srvlist@entry=0x7fff2c1009d8, use_ldsb=use_ldsb@entry=1, connect=connect@entry=1, bind=bind@entry=0x0, m_req=m_req@entry=0, m_res=m_res@entry=0) at request.c:484 #5 0x00007ffff7b938bf in ldap_open_defconn (ld=ld@entry=0x7fff2c100910) at open.c:41 #6 0x00007ffff7ba90e8 in ldap_send_initial_request (ld=ld@entry=0x7fff2c100910, msgtype=msgtype@entry=96, dn=dn@entry=0x555555ad4b70 "cn=replicator,ou=admins,dc=acme,dc=org,dc=au", ber=ber@entry=0x7fff2c100c60, msgid=msgid@entry=1) at request.c:130 #7 0x00007ffff7b9dbd6 in ldap_sasl_bind (ld=ld@entry=0x7fff2c100910, dn=dn@entry=0x555555ad4b70 "cn=replicator,ou=admins,dc=acme,dc=org,dc=au", mechanism=mechanism@entry=0x0, cred=cred@entry=0x555555ad48b8, sctrls=sctrls@entry=0x0, cctrls=<optimized out>, msgidp=msgidp@entry=0x7fff36e9f3f4) at sasl.c:148 #8 0x00007ffff7b9e159 in ldap_sasl_bind_s (ld=0x7fff2c100910, dn=0x555555ad4b70 "cn=replicator,ou=admins,dc=acme,dc=org,dc=au", mechanism=mechanism@entry=0x0, cred=cred@entry=0x5555adad48b8, sctrls=sctrls@entry=0x0, cctrls=cctrls@entry=0x0, servercredp=servercredp@entry=0x0) at sasl.c:182 #9 0x000055555558f0ba in slap_client_connect (ldp=ldp@entry=0x555555ad4aa8, sb=sb@entry=0x555555ad4880) at config.c:2104 #10 0x00005555555ffe2d in do_syncrep1 (si=0x555555ad4850, op=0x7fff36e9f7b0) at syncrepl.c:613 #11 do_syncrepl (ctx=<optimized out>, arg=0x555555ace0a0) at syncrepl.c:1527 #12 0x00007ffff7b92eda in ldap_int_thread_pool_wrapper (xpool=0x5555559ef2f0) at tpool.c:688 #13 0x00007ffff6e5adc5 in start_thread (arg=0x7fff36ea0700) at pthread_create.c:308 #14 0x00007ffff631bced in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 Thread 3 (Thread 0x7fff376a1700 (LWP 12264)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/ux/2Fsysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x00007ffff7b92f2b in ldap_int_thread_pool_wrapper (xpool=0x5555559ef2f0) at tpool.c:675 #2 0x00007ffff6e5adc5 in start_thread (arg=0x7fff376a1700) at pthread_create.c:808 #3 0x00007ffff631bced in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 Thread 2 (Thread 0x7fff37ea2700 (LWP 12263)): #0 0x00007ffff631c2c3 in epoll_wait () at ../sysdeps/unix/syscall-template.S:81 #1 0x0000555555592e98 in slapd_daemon_task (ptr=<optimized out>) at daemon.c:2536 #2 0x00007ffff6e5adc5 in start_thread (arg=0x7fff37ea2700) at pthread_create.c:308 #3 0x00007ffff631bced in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 Thread 1 (Thread 0x7ffff7fe7740 (LWP 12262)): ---Type <return> to continue, or q <return> to quit--- #0 0x00007ffff6e5bef7 in pthread_join (threadid=140734131480320, thread_return=thread_return@entry=0x0) at pthread_join.c:92 #1 0x00007ffff7b935f5 in ldap_pvt_thread_join (thread=<optimized out>, thread_return=thread_return@entry=0x0) at thr_posix.c:197 #2 0x0000555555594d91 in slapd_daemon () at daemon.c:2929 #3 0x000055555557bb12 in main (argc=<optimized out>, argv=0x7fffffffe548) at main.c:1016 (gdb) (gdb) bt full #0 0x00007fff36498960 in ?? () No symbol table info available. #1 0x00005555555a8541 in slap_writewait_play (op=0x7fff200026f0) at result.c:294 sc = 0x7fff364975b0 #2 send_ldap_ber (op=op@entry=0x7fff200026f0, ber=ber@entry=0x7fff36306eb0) at result.c:367 err = <optimized out> conn = 0x555555aeaa80 bytes = 181 ret = 0 #3 0x00005555555ac11c in slap_send_search_entry (op=0x7fff200026f0, rs=<optimized out>) at result.c:1430 berbuf = { buffer = "\002\0%0\001\000\000\000\000\000\377\377\377\377\377\377\377\377", '\000' <repeats 16 times>, "\310J\000 \377\177\000\000}K\000 \377\177\000\000]P\000 \377\177\000\000\000\000\000\000\000\000\000\000\036K\000 \377\177\000\000`,\000 \377\177\000\000D\234\221UUU\0%0\000/\214[UUU\000\000\000\000\000\000\000\000\000\000\330E\000 \377\177\000\000\270\001\000\000\000\000\000\000\v\000\000\000\000\000\000\000(\000\000\000\000\000\000\000\020P\342\367\377\177\000\000\320\027\021 \377\177\000\000\314\322gUUU\000\000\320q06\377\177\000\000pg\213\071\377\177\000\000\360&\000 \377\177\000\000R\346gUUU\000\000\320\027\021 \377\177\000\000"..., ialign = 65538, lalign = 65538, falign = 9.18382988e-41, dalign = 3.2380074297143616e-319, palign = 0x10002 <Address 0x10002 out of bounds>} ber = 0x7fff36306eb0 a = <optimized out> i = <optimized out> j = <optimized out> rc = <optimized out> bytes = <optimized out> userattrs = 1 acl_state = {as_desc = 0x555555ad5590, as_access = ACL_READ, as_vd_acl = 0x0, as_vd_acl_present = 0, as_vd_acl_count = 0, as_vd_mask = 1, as_result = 1, as_fe_done = 0} attrsonly = 0 ad_entry = <optimized out> e_flags = 0x0 #4 0x0000555555645398 in mdb_search (op=<optimized out>, rs=<optimized out>) at search.c:1072 scopeok = 1 edata = {mv_size = 568, mv_data = 0x7fff398b6770} mdb = <optimized out> id = 8597 cursor = 8597 nsubs = 10732 ncand = <optimized out> c cscope = <optimized out> lastid = 18446744073709551615 candidates = {18446744073709551615, 1, 18446744073709551615, 0 <repeats 129310 times>, 140733730259056, 18446603339605394369, 140737323345855, 140734104157247, 140733730259056, 18446603339605394337, 140737323345855, 140734104157279, 1060864, 140733730258944, 4096, 1085440, 1081344, 0, 140733730259064, 18446603339605394193, 2, 18446603339605394177, 2, 0, 0, 390842023984, 140734104157440, 0, 0, 511101108334, 0, 140734104157439, 140733730259056, 18446603339605394145, 140734104157472, 140734104157471, 140734104157520, 0, 0, 511101108334, 0, 140734104157519, 140733730258976, 24, 140733731370544, 140734104170384, 140733730258976, 140733730258976, 2304, 2048, 2064, 93824997886480, 140737323347669, 18446603339605393921, 129, 32, 4, 408021893200, 140734104157696, 0, 0, 511101108334, 0, 140734104157695, 429496729600, 140733731370552, 140733193388032, 140733193388156, 8589934592, 64, 140734104170352, 6, 2, 140734104162064, 140733730258976, 140734104170496, 2304, 2048, 140733731370752, 93824997886480, 3, 140734104170496, 140734104157936, 3, 93824997886480, 93824997886480, 140737322968600, 140733731322016, 140733731370096, 140733731319648, 140733731322016, 140733731370320, 140733731319648, 140733731322016, 140733731370544, 140733731319648, 3, 140734104170496, 140737322967413, 8589934594, 140733731321904, 8589934594, 140733731351664, 4294967297, 140733731356192, 4294967297, 140733731356224, 0 <repeats 504 times>, 17592186044416, 0, 0, 0, 0, 2097152, 0, 0, 18446726481523507198, 18446744073707454463, 18446744073709551615, 18446744073709551615, 18446726481523507198, 18446744073709535229, 18446744073709551615, 18446744073709551615, 0 <repeats 690 times>, 16, 140734104167776, 140734104167712, 0, 16, 140734104167808, 140734104167744, 0, 0, 0, 2050, 140737347298278, 0, 140733730261184, 140734104173392, 140737347299401, 0 <repeats 33 times>, 93824993543904, 140734104168208, 93824993543904, 140734104168224, 140734104171472, 140733730271418, 93824992798118, 140734104171496, 93824992789205, 0, 0, 0, 0, 0, 140737351926868, 0, 93824997521440, 2, 93824997012688, 11, 140733730271418, 0...} iscopes = {0 <repeats 65536 times>} scopes = <optimized out> stack = <optimized out> e = 0x7fff200045d8 ---Type <return> to continue, or q <return> to quit--- base = 0x7fff200040e0 matched = 0x0 attrs = <optimized out> mask = 4159 stoptime = 1463547740 manageDSAit = <optimized out> isc = {mt = 0x7fff201117d0, mc = 0x7fff201132e0, id = 8597, scopes = 0x7fff35998010, sctmp = 0x7fff34997010, numrdns = 2, nscope = 1, oscope = 2, rdns = {{bv_len = 6, bv_val = 0x7fff3867f9e7 "cn=h75"}, {bv_len = 8, bv_val = 0x7fff39b6dfef "ou=Group"}, {bv_len = 0, bv_val = 0x0} <repeats 2046 times>}, nrdns = {{bv_len = 6, bv_val = 0x7fff3867f9e0 "cn=h75"}, {bv_len = 8, bv_val = 0x7fff39b6dfe6 "ou=group"}, {bv_len = 0, bv_val = 0x0} <repeats 2046 times>}} mci = 0x7fff20113150 mcd = 0x7fff201132e0 wwctx = {txn = 0x7fff201117d0, mcd = 0x0, key = 2999, data = {mv_size = 29, mv_data = 0x29ec}, flag = 1} cb = {sc_next = 0x7fff36497390, sc_response = 0x0, sc_cleanup = 0x0, sc_writewait = 0x555555642cd0 <mdb_writewait>, sc_private = 0x7fff36307280} opinfo = {moi_oe = {oe_next = {sle_next = 0x7fff36497590}, oe_key = 0x7ffff7e25010}, moi_txn = 0x7fff201117d0, moi_ref = 1, moi_flag = 1 '\001'} moi = 0x7fff36307230 ltid = 0x7fff201117d0 #5 0x0000555555606926 in overlay_op_walk (op=op@entry=0x7fff200026f0, rs=0x7fff36498960, which=op_search, oi=0x555555acaf90, on=0x0) at backover.c:671 func = <optimized out> rc = 32768 #6 0x0000555555606a94 in over_op_func (op=0x7fff200026f0, rs=<optimized out>, which=<optimized out>) at backover.c:723 oi = <optimized out> on = <optimized out> be = 0x555555ad0370 db = {bd_info = 0x555555919800 <slap_binfo+2240>, bd_self = 0x555555ad0370, be_ctrls = "\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001\000\000\001", '\000' <repeats 14 times>, "\001", be_flags = 55560, 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 = 0}, be_suffix = 0x555555aca430, be_nsuffix = 0x555555aca4a0, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = {bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 31, bv_val = 0x555555aca560 "cn=Manager,dc=acme,dc=org,dc=au"}, be_rootn % = {bv_len = 31, bv_val = 0x555555ad4150 "cn=manager,dc=acme,dc=org,dc=au"}, be_rootpw = {bv_len = 12, bv_val = 0x555555acaaa0 "its.a.secret"}, be_max_deref_depth = 15, be_def_limit = {lms_t_soft = -1, 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 = 0x555555ad2d10, be_acl = 0x555555aca5f0, be_dfltaccess = ACL_READ, be_extra_anlist = 0x0, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_uatate_refs = 0x0, be_pending_csn_list = 0x555555a4e300, be_pcl_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, be_syncinfo = 0x555555ad42f0, be_pb = 0x0, be_cf_ocs = 0x55555591e8c0 <mdbocs>, be_private = 0x7ffff7e25010, be_next = {stqe_next = 0x555555ad1bc0}} cb = {sc_next = 0x7fff364975b0, sc_response = 0x555555605c60 <over_back_response>, sc_cleanup = 0x0, sc_writewait = 0x0, sc_private = 0x555555acaf90} sc = <optimized out> rc = 32768 __PRETTY_FUNCTION__ = "over_op_func" #7 0x00007ffff3ec1d16 in relay_back_op (op=0x7fff200026f0, rs=0x7fff36498960, which=<optimized out>) at op.c:210 wrap_oex = {oe = {oe_next = {sle_next = 0x0}, oe_key = 0x555555aaf152}, oe_db = 0x7fff364976a0} wrap_bd = 0x7fff364976a0 rcb = {rcb_sc = {sc_next = 0x7fff20002fb0, sc_response = 0x7ffff3ec1a70 <relay_back_response_cb>, sc_cleanup = 0x7ffff3ec1a50 <relay_back_cleanup_cb>, sc_writewait = 0x7fff36498960, sc_private = 0x7fff364976a0}, rcb_bd = 0x7fff364973c0} bd = <optimized out> func = <optimized out> fail_mode = <optimized out> rc = <optimized out> #8 0x0000555555606926 in overlay_op_walk (op=op@entry=0x7fff200026f0, rs=0x7fff36498960, which=op_search, oi=0x555555aaf250, on=0x0) at backover.c:671 func = <optimized out> rc = 32768 #9 0x0000555555606a94 in over_op_func (op=0x7fff200026f0, rs=<optimized out>, which=<optimized out>) at backover.c:723 oi = <optimized out> on = <optimized out> be = 0x555555aba870 db = {bd_info = 0x7ffff40c3120 <bi>, bd_self = 0x555555aba870, be_ctrls = '\000' <repeats 32 times>, be_flags = 256, be_restrictops = 0, be_requires = 0, be_ssf_set = { ---Type <return> to continue, or q <return> to quit--- sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl % 0 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x555555aaf1a0, be_nsuffix = 0x555555abaa40, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = {bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 0, bv_val = 0x0}, be_rootndn = {bv_len = 0, bv_val = 0x0}, be_rootpw = {bv_len = 0, bv_val = 0x0}, be_max_deref_depth = 15, be_def_limit = {lms_t_soft = -1, 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 = 0x0, be_acl = 0x555555abab50, 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 = 0x555555a3f530, be_pcl_mutex = { __data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0x7ffff40c3000 <relayocs>, be_private = 0x555555aaf150, be_next = {stqe_next = 0x555555ad0370}} cb = {sc_next = 0x0, sc_response = 0x555555605c60 <over_back_response>, sc_cleanup = 0x0, sc_writewait = 0x0, sc_private = 0x555555aaf250} sc = <optimized out> rc = 32768 __PRETTY_FUNCTION__ = "over_op_func" #10 0x000055555559ad31 in fe_op_search (op=0x7fff200026f0, rs=0x7fff36498960) at search.c:402 bd = 0x555555920960 <slap_frontendDB> #11 0x000055555559a5e6 in do_search (op=<optimized out>, rs=<optimized out>) at search.c:247 base = {bv_len = 23, bv_val = 0x7fff20102cb7 "dc=newacme,dc=edu,dc=au"} siz = 0 off = 0 i = <optimized out> #12 0x0000555555597cbc in connection_operation (ctx=ctx@entry=0x7fff36498bd0, arg_v=arg_v@entry=0x7fff200026f0) at connection.c:1155 rc = 80 cancel = <optimized out> op = 0x7fff200026f0 rs = {sr_type = REP_SEARCH, sr_tag = 0, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = {sru_search = {r_entry = 0x0, r_attr_flags = 33, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 8596, r_v2ref = 0x0}, sru_sasl = {r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x21}}, sr_flags = 0} tag = 99 opidx = SLAP_OP_SEARCH conn = 0x555555aeaa80 memctx = 0x7fff20002c60 memctx_null = 0x0 memsiz = 1048576 __PRETTY_FUNCTION__ = "connection_operation" #13 0x000055555559802b in connection_read_thread (ctx=0x7fff36498bd0, argv=0x12) at connection.c:1291 rc = <optimized out> cri = {op = 0x7fff200026f0, func = 0x0,rarg = 0x0, ctx = <optimized out>, nullop = <optimized out>} s = <optimized out> #14 0x00007ffff7b92eda in ldap_int_thread_pool_wrapper (xpool=0x5555559ef2f0) at tpool.c:688 pool = 0x5555559ef2f0 task = 0x7fff30000d80 work_list = <optimized out> ctx = {ltu_id = 140734104180480, ltu_key = {{ltk_key = 0x555555595dc0 <conn_counter_init>, ltk_data = 0x7fff20002b50, ltk_free = 0x555555595ea0 <conn_counter_destroy>}, { ltk_key = 0x5555555f04c0 <slap_sl_mem_init>, ltk_data = 0x7fff20002c60, ltk_free = 0x5555555f0380 <slap_sl_mem_destroy>}, {ltk_key = 0x5555555ac590 <slap_op_free>, ltk_data = 0x0, ltk_free = 0x5555555ac4f0 <slap_op_q_destroy>}, {ltk_key = 0x555555a4d620, ltk_data = 0x7fff201117d0, ltk_free = 0x55555567d310 <mdb_reader_free>}, { ltk_key = 0x5555556428f0 <search_stack>, ltk_data = 0x7fff34997010, ltk_free = 0x555555642a00 <search_stack_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0x0} <repeats 27 times>}} kctx = <optimized out> keyslot = <optimized out> hash = <optimized out> __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #15 0x00007ffff6e5adc5 in start_thread (arg=0x7fff36499700) at pthread_create.c:308 __res = <oimimized out> pd = 0x7fff36499700 now = <optimized out> unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140734104180480, 1625288578173050950, 1, 140734104181184, 140734104180480, 93824996187204, -1625724926964981690, ---Type <return> to continue, or q <return> to quit--- -1625304055555612602}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = <optimized out> pagesize_m1 = %3ptimimized out> sp = <optimized out> freesize = <optimized out> #16 0x00007ffff631bced in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 No locals. (gdb) slapd.conf # # include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/local/rfc2307bis.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/openldap.schema include /etc/openldap/schema/duaconf.schema include /etc/openldap/schema/ppolicy.schema include /etc/openldap/schema/local/eduperson.schema include /etc/openldap/schema/local/aueduperson.schema include /etc/openldap/schema/local/schac.schema include /etc/openldap/schema/local/adapns.schema include /etc/openldap/schema/local/kerberos.schema # Define global ACLs to disable default read access. # Do not enable referrals until AFTER you have a working directory # service AND an understanding of referrals. #referral ldap://root.openlp.ororg pidfile /run/openldap/slapd.pid argsfile /run/openldap/slapd.args # Global section serverID 1 ldap://acmeldap1.acme.org.au serverID 2 ldap://acmeldap2.acme.org.au serverID 3 ldap://acmeldap3.acme.org.au # Load dynamic backend modules: modulepath /usr/lib64/openldap moduleload back_mdb.la moduleload syncprov.la # moduleload back_ldap.la moduleload back_relay.la moduleload memberof.la moduleload auditlog.la moduleload rwm.la # Sample security restrictions # Require integrity protection (prevent hijacking) # Require 112-bit (3DES or better) encryption for updates # Require 63-bit encryption for simple bind # security ssf=1 update_ssf=112 simple_bind=64 #TLSCertificateFile /etc/openldap/certs/acme.crt #TLSCertificateKeyFile /etc/openldap/certs/acme.key #TLSCipherSuite HIGH:MEDIUM:+SSLv2 #TLSCACertificateFile /etc/openldap/certs/acmeca.crt sizelimit unlimited timelimit unlimited # Sample access control policy: # Root DSE: allow anyone to read it # Subschema (sub)entry DSE: allow anyone to read it # Other DSEs: # Allow self write access # Allow authenticated users read access # Allow anonymous users to authenticate # Directives needed to implement policy: access to dn.base="" by * read access to dn.base="cn=Subschema" by * read #access to * # by self write # by users read # by anonymous auth access to * by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage by * none # # if no access controls are present, the default policy # allows anyone and everyone to read anything but restricts # updates to rootdn. (e.g., "access to * by * read") # # rootdn can always read and write EVERYTHING! ###########################################################3#23########## # MDB database definitions ####################################################################### database relay suffix "dc=newacme,dc=edu,dc=au" relay "dc=acme,dc=org,dc=au" access to attrs=userPassword,userPKCS12 by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage by dn.exact="cn=Manager,dc=acme,dc=org,dc=au" read by self write by anonymous auth by * none access to attrs=shadowLastChange by self write by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage by * none access to dn.subtree="dc=newacme,dc=edu,dc=au" by * read access to * by dn.base="gidNumber=0+uidNumber=0,cn=peercred,%3=external,cn=auth" write by * none overlay rwm rwm-rewriteEngine on rwm-suffixmassage "dc=newacme,dc=edu,dc=au" "dc=acme,dc=org,dc=au" database mdb #maxsize 1073741824 maxsize 3145728000 suffix "dc=acme,dc=org,dc=au" roon 09 "cn=Manager,dc=acme,dc=org,dc=au" rootpw its.a.secret # Let the replica DN have limitless searches limits dn.exact="cn=replicator,dc=acme,dc=org,dc=au" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited #updatedn "cn=replicator,dc=acme,dc=org,dc=au" # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory /var/lib/ldap # Indices to maintain index objectClass eq,pres index ou,cn,mail,surname,givenname eq,pres,sub index uid eq,sub index entryUUID eq index entryCSN eq index memberuid eq index member eq index memberOf eq index gidNumber eq index uidNumber eq access to attrsDuDuserPasswor2C2CuserPKCS12 by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage by dn.exact="cn=Manager,dc=acme,dc=org,dc=au" read by dn.exact="cn=replicator,ou=admins,dc=acme,dc=org,dc=au" read by self write by anonymous auth by * none access to attrs=shadowLastChange by self write by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage by dn.exact="cn=Manager,dc=acme,dc=org,%c=au" read by * none access to dn.subtree="cn=kerberos,ou=services,dc=acme,dc=org,dc=au" by dn.exact="cn=krbadmin,ou=People,dc=acme,dc=org,dc=au" write by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" read by * none access to dn.subtree="dc=acme,dc=org,dc=au" by dn.exact="cn=Manager,dc=acme,dc=org,dc=au" write by * read #access to dn.subtree="dc=acme,dc=org,dc=au" # by dn.exact="cn=Manager,dc=acme,dc=org,dc=au" write # by * none #access to dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" write # by * none access to * by dn.base="cn=replicator,ou=Admins,dc=acme,dc=org,dc=au" read by * break overlay memberof memberof-group-oc groupOfNames memberof-member-ad member memberof-memberof-ad memberOf memberof-dangling ignore overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 syncrepl rid=004 provider=ldap://acmeldap1.acme.org.au type=refreshAndPersist retry="5 5 300 +"D%D timeout=3 searchbase="dc=acme,dc=org,dc=au" attrs="*,+" bindmethod=simple binddn="cn=replicator,ou=Admins,dc=acme,dc=org,dc=au" credentials=replicatorsecret syncrepl rid=005 provider=ldap://acmeldap2.acme.org.au type=refreshAndPersist% %A retry="5 5 300 +" timeout=3 searchbase="dc=acme,dc=org,dc=au" attrs="*,+" bindmethod=simple binddn="cn=replicator,ou=Admins,dc=acme,dc=org,dc=au" credentials=replicatorsecret syncrepl rid=006 provider=ldap://acmeldap3.acme.org.%0 type=refreshAndPersist retry="5 5 300 +" searchbase="dc=acme,dc=org,dc=au" attrs="*,+" bindmethod=simple binddn="cn=replicator,ou=Admins,dc=acme,dc=org,dc=au" credentials=replicatorsecret database monitor access to dn="cn=monitor" byn.n.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" read by dn.base="cn=Manager,dc=acme,dc=org,dc=au" read by * none database config rootpw its.a.secret

1 0

(ITS#8427) Incorrect value of tls_reqcert in syncrepl
by mkp37215＠gmail.com 16 May '16

16 May '16

Full_Name: Maciej Puzio Version: 2.4.44 and git head OS: Ubuntu 16.04 amd64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (129.112.109.41) Incorrect handling of TLS options causes syncrepl to use different values for first connection attempt and subsequent retries. In some circumstances this may result in syncrepl unable to recover from a temporary network outage. Note: This bug has very similar symptoms and occurs in similar circumstances as ITS# 8385 (that has already been fixed). However, my investigation indicates that this is a separate issue. Steps to reproduce the problem: 1. Configure two LDAP servers in dual master replication setup using slapd.conf config file as described below. 2. Provide the servers with TLS certificates that are correct but do not include an address used in syncrepl provider setting. (Note: SECURE256 requires 4096-bit RSA key) 3. Set tls_reqcert to allow in both slapd.conf and ldap.conf. 4. Start slapd on both servers. 5. Stop and restart slapd on server A. 6. Server B will write errors to syslog: slapd: do_syncrep2: rid=001 (-1) Can't contact LDAP server slapd: do_syncrepl: rid=001 rc -1 retrying (9 reieies left) Expected result: After predefined time server B will retry replication, and we will see messages: slapd: do_syncrep1: rid=001 starting refresh slapd: do_syncrep1: rid=001 finished refresh Observed result: Server B produces theollolowing messages in a loop: slapd: do_syncrepl: rid=001 rc -1 retrying (8 retries left) slapd: slap_client_connect: URI=ldaps://10.0.0.1 DN="cn=root,dc=test" ldap_sasl_bind_s failed (-1) The relevant parts of slapd.conf: (for server A at 10.0.0.1) loglevel 1 serverID 001 moduleload syncprov TLSCipherSuite SECURE256:-VERS-SSL3.0 TLSCACertificateFile /etc/ldap/ssl/ca.pem TLSCertificateFile /etc/ldap/ssl/srvA.pemATATLSCertificateKeyFile /etc/ldap/ssl/srvA.key syncrepl rid=001 provider=ldaps://10.0.0.2 type=refreshAndPersist retry="30 10 300 +" searchbase="dc=test" attrs="*,+" bindmethod=simple binddn="cn=root,dc=test" credentials="plaintext-password" tls_reqcert=allow keepalive="240:5:10" mirrormode TRUE overlay syncprov syncprov-checkpoint 10 1440 OpenLDAP was build with this configuration: ./configure --prefix=/opt/openldap --enable-debug --enable-dynamic --enable-syslog --enable-local --enable-slapd --enable-crypt --enable-modules --enable-backends --enable-ndb=no --enable-shell=no --enable-perl=no --enable-sql=no --enable-wt=no --enable-overlays --with-tls=gnutls CPPFLAGS="-Wno-format-extra-args" Note that GnuTLS was used, following Debian and Ubuntu practice. I did not test this issue with other TLS libraries, and I do not know if this issue is GnuTLS-related or not. Debug findings: The above symptoms are caused by the following lines located at the end of ldap_int_tls_start in file libraries/libldap/tls2.c: if (ld->ld_options.ldo_tls_require_cert != LDAP_OPT_X_TLS_NEVER && ld->ld_options.ldo_tls_require_cert != LDAP_OPT_X_TLS_ALLOW) { ld->ld_errno = ldap_pvt_tls_check_hostname( ld, ssl, host ); if (ld->ld_errno != LDAP_SUCCESS) { return ld->ld_errno; } } The value of ld->ld_options.ldo_tls_require_cert is correct during first syncrepl connection attempt, but incorrect during retries. During my tests I noticed that it tended to equal 2 (demand), even when tls_reqcert was set to allow or never. On other occasions I noticed this variable to assume the value of TLS_REQCERT from ldap.conf, giving a peculiar result of first syncrepl connection using setting from slapd.conf, and subsequent ones from ldap.conf. It is possible that the value is uninitialized. Further debugging showed that this situation results from slap_client_connect (servers/slapd/config.c) not calling bindconf_tls_set on retries. The relevant code is: if ( sb->sb_tls_do_init ) { rc = bindconf_tls_set( sb, ld ); } else if ( sb->sb_tls_ctx ) { rc = ldap_set_option% l ld, LDAP_OPT_X_TLS_CTX, sb->sb_tls_ctx ); } Due to my limited familiarity with OpenLDAP design, I did not debug the issue further and did not find the root cause of this problem. Discusonon about relationship of this bug to ITS# 8385: On surface these bugs appear similar to each other like twins, both causing failures of syncrepl retries due to incorrect value of tls_reqcert. In fact, I found this bug while testing Ubuntu slapd and libldap packages with patch for #8385 backported. There are however some subtle differences: 1. A TLS certificate incorrect in a different way is needed to reproduce #8385: in my tests it listed a correct host, but had a key too weak for specified cipher strength. 2. Bug #8385 has much lower reproducibility (as expected for unallocated memory issue). 3. Symptoms of #8385 are a result of code in tls_g.c (tlsg_session_accept does wrong tests), while this bug results from host tests in tls2.c (ldap_int_tls_start). Both are triggered by an incorrect value of tls_reqcert. 4. I suspect a different cause leading to wrong tls_reqcert value in both bugs. Please let me know if you need further information. Thank you very much. Maciej Puzio

1 0

(ITS#8426) unable to get group names of user
by pradeepagrawal8184＠gmail.com 16 May '16

16 May '16

Full_Name: Pradeep Agrawal Version: 2.4.40-7 OS: centos URL: Submission from: (NULL) (114.143.121.177) is there any way to get groups of users by providing username. i am using java code to fetch list of groups of given users but it seems its not possible as user don't have 'memberof' attribute.

1 0

(ITS#8425) sssvlv active process
by pencilkhan07＠gmail.com 16 May '16

16 May '16

Full_Name: nilom khan Version: 2.4.40 OS: Centors 6.5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (202.53.173.178) Dear sir , I know this is common problem but i can't able to solve it . Although previously some one suggest to add some code into /etc/ldap/sldap.conf . but my version doesn't contain /etc/openldap/sldap.conf . I google it and found that centors 6.5 version dos not contain this file. Below my version information . [root@mail ~]# slapd -V @(#) $OpenLDAP: slapd 2.4.40 (Nov 10 2015 09:41:16) $ mockbuild@c6b8.bsys.dev.centos.org:/builddir/build/BUILD/openldap-2.4.40 /openldap-2.4.40/build-servers/servers/slapd Could u please suggest me how to enable SSSVLV so that i can browse open ldap address book in outlook . Their have any process for search with group attribute ? its very kind full if you suggest me . Thanks in advance Nilom KHan

1 0

Re: (ITS#8423) Slapd hang when modifying the configuration and an accesslog purge is going on
by hyc＠symas.com 14 May '16

14 May '16

elecharny(a)apache.org wrote: > Full_Name: Emmanuel Lecharny > Version: 2.4.43 > OS: RH7 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (92.169.142.218) > > > When the accessLog is being purged, a change in cn=config will wait until the > purge is done, which may take a while. > > The access_log purge should honor cn=config pause requests. > Fixed now in git master. -- -- 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#8424) mdb_env_cwalk() is broken, leading to crash if MDB_CP_COMPACT is set
by hyc＠symas.com 14 May '16

14 May '16

ddmitrie(a)gmail.com wrote: > Full_Name: Dmitry Dmitrienko > Version: trunk, 0.9.18 > OS: Linux, Windows > URL: > Submission from: (NULL) (100.36.101.84) > Thanks, fixed now in git mdb.master > In short: > Reproduce: create a large database (1GB would be enough), run md_copy with -c > argument. Expected result - compacted new database, Actual result - empty new > database and crash in md_copy. > > In details: > mdb_env_cwalk() defines cursor and does not initialize most of its fields, > including mc_flags field. Then it calls mdb_page_get() procedure, which checks > if (C_ORIG_RDONLY|C_WRITEMAP) flags are set in mc_flags. Since this field is not > initialized, it may have arbitrary value. If these flags are not set, it starts > checking txn's mt_u.dirty_list, as if it was a writing transaction, while in > fact this is a walker, it is a reader, so it initialized mt_u.reader fields. > This field is in the same memory location with dirty_list just because it's > union. So mdb_page_get() actually reads lock file memory (it's where mt_u.reader > points to). If the database is large enough, it leads to access to far beyond > lock file memory mapped region and crashes md_copy. > > Proposed fix: > mdb_env_cwalk(mdb_copy *my, pgno_t *pg, int flags) > ... > + memset(&mc, 0, sizeof(mc)); > mc.mc_snum = 1; > mc.mc_top = 0; > mc.mc_txn = my->mc_txn; > + mc.mc.mc_flags = my->mc_txn->mt_flags & (C_ORIG_RDONLY|C_WRITEMAP); > > > > -- -- 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#8424) mdb_env_cwalk() is broken, leading to crash if MDB_CP_COMPACT is set
by ddmitrie＠gmail.com 14 May '16

14 May '16

Full_Name: Dmitry Dmitrienko Version: trunk, 0.9.18 OS: Linux, Windows URL: Submission from: (NULL) (100.36.101.84) In short: Reproduce: create a large database (1GB would be enough), run md_copy with -c argument. Expected result - compacted new database, Actual result - empty new database and crash in md_copy. In details: mdb_env_cwalk() defines cursor and does not initialize most of its fields, including mc_flags field. Then it calls mdb_page_get() procedure, which checks if (C_ORIG_RDONLY|C_WRITEMAP) flags are set in mc_flags. Since this field is not initialized, it may have arbitrary value. If these flags are not set, it starts checking txn's mt_u.dirty_list, as if it was a writing transaction, while in fact this is a walker, it is a reader, so it initialized mt_u.reader fields. This field is in the same memory location with dirty_list just because it's union. So mdb_page_get() actually reads lock file memory (it's where mt_u.reader points to). If the database is large enough, it leads to access to far beyond lock file memory mapped region and crashes md_copy. Proposed fix: mdb_env_cwalk(mdb_copy *my, pgno_t *pg, int flags) ... + memset(&mc, 0, sizeof(mc)); mc.mc_snum = 1; mc.mc_top = 0; mc.mc_txn = my->mc_txn; + mc.mc.mc_flags = my->mc_txn->mt_flags & (C_ORIG_RDONLY|C_WRITEMAP);

1 0

(ITS#8423) Slapd hang when modifying the configuration and an accesslog purge is going on
by elecharny＠apache.org 13 May '16

13 May '16

Full_Name: Emmanuel Lecharny Version: 2.4.43 OS: RH7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (92.169.142.218) When the accessLog is being purged, a change in cn=config will wait until the purge is done, which may take a while. A typical trace : ... Thread 7 (Thread 0x7f431bfff700 (LWP 57043)):D0D #0 0000007f4863858fdd in fdatasync () at ../sysdeps/unix/syscall-template.S:81 #1 0x00007f48619db98d in mdb_env_sync (env=0xc63d20, force=0) at /home/build/sol_R_2.4.43.1/openldap/servers/slapd/back-mdb/../../../libraries/liblmdb/mdb.c:2474 #2 0x00007f48619de46e in mdb_txn_commit (txn=0xc36ed0) at /home/build/sol_R_2.4.43.1/openldap/servers/slapd/back-mdb/../../../libraries/liblmdb/mdb.c:3572 #3 0x00007f48619c06c6 in mdb_delete (op=0x7f431bffe4c0, rs=0x7f431bffe450) at /home/build/sol_R_2.4.43.1/openldap/servs%s/slapd/back-mdb/delete.c:415 #4 0x00000000004d2b87 in overlay_op_walk (op=0x7f431bffe4c0, rs=0x7f431bffe450, which=op_delete, oi=0xc96a80, on=0x0) at /home/build/sol_R_2.4.43.1/openldap/servers/slapd/backover.c:677 #5 0x00000000004d2db4 in over_op_func (op=0x7f431bffe4c0, rs=0x7f431bffe450, which=op_delete) at /home/build/sol_R_2.4.43.1/openldap/servers/slapd/backover.c:730 #6 0x00000000004d2f6e in over_op_delete (op=0x7f431bffe4c0, rs=0x7f431bffe450) at /home/build/sol_R_2.4.43.1/openldap/servers/slapd/backover.c:787 #7 0x00007f486136dfb2 in accesslog_purge (ctx=0x7f431bffebb0, arg=0xc8ee00) at /home/build/sol_R_2.4.43.1/openldap/servers/slapd/overlays/accesslog.c:700 #8 0x00007f48656ff7f3 in ldap_int_thread_pool_wrapper (xpool=0xbd5d80) at /home/build/sol_R_2.4.43.1/openldap/libraries/libldap_r/tpool.c:956 #9 0x00007f4864e89182 in start_thread (arg=0x7f431bfff700) at pthread_create.c:312 #10 0x00007f486386147d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 ... Thread 4 (Thread 0x7f1a7f7fc700 (LWP 57046)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x00007f4865700ed3 in ldap_pvt_thread_cond_wait (cond=0xbd5ce0, mutex=0xbd5c88) at /home/build/sol_R_2.4.43.1/openldap/libraries/libldap_r/thr_posix.c:277 #2 0x00007f48656ffcb6 in handle_pause (tpool=0x76b500 <connection_pool>, pause_type=96) at /home/build/sol_R_2.4.43.1/openldap/libraries/libldap_r/tpool.c:1106 #3 0x00007f48656ffdb6 in ldap_pvt_thread_pool_pause (tpool=0x76b500 <connection_pool>) at /home/build/sol_R_2.4.43.1/openldap/libraries/libldap_r/tpool.c:1152 #4 0x0000000000428c3b in config_back_modify (op=0x7f43040008e0, rs=0x7f431a7fba80) at /home/build/sol_R_2.4.43.1/openldap/servers/slapd/bconfig.c:5943 #5 0x0000000005e5e87e in fe_op_modify (op=0x7f43040008e0, rs=0x7f431a7fba80) at /home/build/sol_R_2.4.43.1/openldap/servers/slapd/modify.c:303 #6 0x000000000045e150 in do_modify (op=0x7f43040008e0, rs=0x7f431a7fba80) at /home/build/sol_R_2.4.43.1/openldap/servers/slapd/modify.c:177 #7 0x000000000043dcff in connection_operation (ctx=0x7f431a7fbbb0, arg_v=0x7f43040008e0) at /home/build/sol_R_2.4.43.1/openldap/servers/slapd/connection.c:1158 #8 0x000000000043e2a0 in connection_read_thread (ctx=0x7f431a7fbbb0, argv=0x63) at /home/build/sol_R_2.4.43.1/openldap/servers/slapd/connection.c:1294 #9 0x00007f48656ff7f3 in ldap_int_thread_pool_wrapper (xpool=0xbd5d80) at /home/build/sol_R_2.4.43.1/openldap/libraries/libldap_r/tpool.c:956 #10 0x00007864e4e89182 in start_thread (arg=0x7f431a7fc700) at pthread_create.c:312 #11 0x00007f486386147d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 The access_log purge should honor cn=config pause requests.

1 0

Re: (ITS#8422) --enable-ldap library linking failure
by hyc＠symas.com 13 May '16

13 May '16

jtrupp(a)symas.com wrote: > Full_Name: Jason Trupp > Version: 2.4.44 > OS: Ubuntu 12 and 14 > URL: > Submission from: (NULL) (173.173.23.148) > > > The --enable-ldap option, according to the Admin Guide section 12.3.1 is > required to make chaining work. However, enabling this feature as part of the > configuration does not automatically perform the library linking task,r%r > return an error if the linking were to fail for some reason. > > Per Howard Chu, "It worked at some time in the past. It's apparently broken > now..." > > Relevant Minutia: This bug report is inaccurate/incomplete. There is no linking problem when using configure --enable-ldap. Please provide accurate information on the issue you are reporting. -- -- 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#8422) --enable-ldap library linking failure
by jtrupp＠symas.com 11 May '16

11 May '16

Full_Name: Jason Trupp Version: 2.4.44 OS: Ubuntu 12 and 14 URL: Submission from: (NULL) (173.173.23.148) The --enable-ldap option, according to the Admin Guide section 12.3.1 is required to make chaining work. However, enabling this feature as part of the configuration does not automatically perform the library linking task,r%r return an error if the linking were to fail for some reason. Per Howard Chu, "It worked at some time in the past. It's apparently broken now..." Relevant Minutia: But when chaining via TLS, we get this error: 572be686 conn=1000 fd=14 ACCEPT from IP=127.0.0.1:41427 (IP=0.0.0.0:389) 572be686 conn=1000 op=0 EXT oid=1.3.6.1.4.1.1466.20037 572be686 conn=1000 op=0 STARTTLS 572be686 conn=1000 op=0 RESULT oid= err=0 text= 572be687 conn=1000 fd=14 TLS established tls_ssf=256 ssf=256 572be687 conn=1000 op=1 BIND dn="" method=163 572be687 conn=1000 op=1 BIND authcid="email=jtrupp(a)symas.com,cn=alcoa12,ou=alcoa,o=alcoa inc,l=riverdale,st=iowa,c=us" authzid="email=jtrupp(a)symas.com,cn=alcoa12,ou=alcoa,o=alcoa inc,l=riverdale,st=iowa,c=us" 572be687 conn=1000 op=1 BIND dn="email=jtrupp(a)symas.com,cn=alcoa12,ou=alcoa,o=alcoa inc,l=riverdale,st=iowa,c=us" mech=EXTERNAL sasl_ssf=0 ssf=256 572be687 conn=1000 op=1 RESULT tag=97 err=0 text= 572be687 conn=1000 op=2 MOD dn="cn=La Valko,ou=Peons,dc=example,dc=com" 572be687 conn=1000 op=2 MOD attr=description /usr/local/libexec/slapd: symbol lookup error: /usr/local/libexec/openldap/back_ldap-2.4.so.2: undefined symbol: ldap_modify_ext A checked against the libraries in use returns the following: root@alcoa12:/usr/local/etc/openldap# ldd /usr/local/libexec/openldap/back_ldap-2.4.so.2 linux-vdso.so.1 => (0x00007fff14b39000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fc92c915000) /lib64/ld-linux-x86-64.so.2 (0x00007fc92cf17000) root@alcoa12:/usr/local/etc/openldap# ldd /usr/local/libexec/slapd linux-vdso.so.1 => (0x00007fffab493000) libltdl.so.7 => /usr/lib/x86_64-linux-gnu/libltdl.so.7 (0x00007f18edf63000) libdb-5.3.so => /usr/lib/x86_64-linux-gnu/libdb-5.3.so (0x00007f18edbc1000) libsasl2.so.2 => /usr/lib/x86_64-linux-gnu/libsasl2.so.2 (0x00007f18ed9a5000) libssl.so.1.0.0 => /lib/x86_64-linux-gnu/libssl.so.1.0.0 (0x00007f18ed748000) libcrypto.so.1.0.0 => /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 (0x00007f18ed36d000) libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 (0x00007f18ed133000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f18ecf16000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f18ecb56000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f18ec951000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f18ec73a000) /lib64/ld-linux-x86-64.so.2 (0x00007f18ee187000)

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs