- openldap-bugs - openldap.org

(ITS#6038) Write slapadd progress meter to stdout
by rein＠OpenLDAP.org 26 Mar '09

26 Mar '09

Full_Name: Rein Tollevik Version: CVS HEAD OS: Irrelevant URL: Submission from: (NULL) (84.215.36.97) Submitted by: rein The slapadd progress meter is written to stderr, and the only way to get rid of it is currently to redirect stderr. I don't want the meter in my small test scripts, as it is not very useful on minimal input and clutters the test output. It should be possible to disable the meter without loosing all error messages, a fix that writes the meter to stdout instead is coming. Options to enable/disable the meter would be nice, but the obvious candidates -q and -v are both occupied... Rein Tollevik Basefarm AS

1 0

(ITS#6037) errno in signal handlers
by h.b.furuseth＠usit.uio.no 26 Mar '09

26 Mar '09

Full_Name: Hallvard B Furuseth Version: HEAD, RE24 OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard Signal handlers slapd/daemon.c:slap_sig_shutdown()/slap_sig_wake() need to save/restore errno, since they call functions that can modify errno. And/or possibly they need sock_errno() - sock_errset() from ac/socket.h, since they use tcp_write()? I don't know if that's safe inside signal handlers, or if Windows itself saves/restores this code around signal handlers. slapd/main.c:wait4child() can loop forever after EINTR, since it checks for errno even when the waitpid returns 0. I don't know if there is a good reason it does that. Some of the commits have my name on them but I think I copied it from elsewhere. Anyway, I'm doing the minimal changes now: save/restore errno, and set errno=0 in each loop iteration instead of before the loop. Anyone with better ideas can take it from there.

1 0

Re: (ITS#6035) slapd requires restart after modifying olcAuthzRegexp
by ando＠sys-net.it 26 Mar '09

26 Mar '09

quanah(a)zimbra.com wrote: > --On Thursday, March 26, 2009 4:14 PM +0000 hyc(a)symas.com wrote: > >> This is a known limitation in authz regexp support. There are no plans >> to change this any time soon. > > Where's this limitation documented? What other parameters in the config > backend have the same flaw? We've certainly fixed this for a number of > other things. Indeed, it has been finally, although rather inelegantly, fixed in slapo-rwm(5), AFAIR. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#6035) slapd requires restart after modifying olcAuthzRegexp
by quanah＠zimbra.com 26 Mar '09

26 Mar '09

--On Thursday, March 26, 2009 4:14 PM +0000 hyc(a)symas.com wrote: > This is a known limitation in authz regexp support. There are no plans > to change this any time soon. Where's this limitation documented? What other parameters in the config backend have the same flaw? We've certainly fixed this for a number of other things. I don't even see authz-regexp/olcAuthzRegexp mentioned in chapters 5 or 6 in the admin guide, and the man pages don't note this limitation. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6035) slapd requires restart after modifying olcAuthzRegexp
by hyc＠symas.com 26 Mar '09

26 Mar '09

This is a known limitation in authz regexp support. There are no plans to change this any time soon. On Thu, Mar 26, 2009 at 03:33:37AM +0000, dgbaley27(a)verizon.net wrote: > Full_Name: Matthew Monaco > Version: 2.4.11 > OS: GNU/Linux 2.6.27-7 (Ubuntu 8.10 Server JeOS) > URL: > Submission from: (NULL) (96.242.209.249) > > > After modifying existing olcAuthzRegexp and/or adding/removing additional > olcAuthzRegexp from cn=config, I needed to restart slapd for the changes to take > effect. > > I'm not sure if it matters but I was using ldapvi to do the modification. > > I can however, confirm that the changes immediately appeared in various other > ldap browsers (such as Apache Directory Studio).

1 0

(ITS#6036) Crash: UUIDNormalize doesn't clear output on error
by test.007＠seznam.cz 26 Mar '09

26 Mar '09

Full_Name: Test Seven Version: 2.4.15 OS: Windows URL: Submission from: (NULL) (195.39.55.20) --- schema_init.orig 2009-01-22 01:01:03.000000000 +0100 +++ schema_init.c 2009-03-26 15:12:15.578125000 +0100 @@ -2814,6 +2814,7 @@ UUIDNormalize( } else { slap_sl_free( normalized->bv_val, ctx ); + BER_BVZERO(normalized); return LDAP_INVALID_SYNTAX; } I encountered a crash in str2entry2() final cleanup. It turned out that it called ordered_value_normalize(), which called UUIDNormalize(), which left the value nonzero but already free-d.

1 0

(ITS#6035) slapd requires restart after modifying olcAuthzRegexp
by dgbaley27＠verizon.net 25 Mar '09

25 Mar '09

Full_Name: Matthew Monaco Version: 2.4.11 OS: GNU/Linux 2.6.27-7 (Ubuntu 8.10 Server JeOS) URL: Submission from: (NULL) (96.242.209.249) After modifying existing olcAuthzRegexp and/or adding/removing additional olcAuthzRegexp from cn=config, I needed to restart slapd for the changes to take effect. I'm not sure if it matters but I was using ldapvi to do the modification. I can however, confirm that the changes immediately appeared in various other ldap browsers (such as Apache Directory Studio).

1 0

Re: (ITS#6034) Assert failure - connection_state_closing / send_ldap_ber / slap_send_search_entry / syncprov_sendresp
by hyc＠symas.com 25 Mar '09

25 Mar '09

oskar(a)deckle.co.za wrote: > Full_Name: Oskar Pearson > Version: 2.4.15 > OS: Ubuntu hardy > URL: ftp://ftp.openldap.org/incoming/slapd-configs-qualica-1.tar.gz > Submission from: (NULL) (94.194.140.71) > > > This is the same machine as ITS #6033. Details included here for easy > reference: > > Openldap 2.4.15 (with no patches) was self-compiled with no patches > (CFLAGS="-ggdb3 -O0" ./configure), linked against standard OS libraries (ubuntu > hardy) for BDB etc. BDB is 4.6.21-6ubuntu1. Kernel is 2.6.24-19-server, libc is > libc6-i686/2.7-10ubuntu3. > > I do not have a debug log of this crash as it occurred on a live server, which > is too busy for that level of logging. I also do not have a replaceable > example. > I have core dumps and can print out whatever is necessary there - I appreciate > your time and help. This bug was fixed in CVS already and the fix will be out in 2.4.16 soon. The fix is already in RE24... > gdb --core=../core.29266 --directory=servers/slapd/ > --directory=servers/slapd/overlays servers/slapd/slapd > (gdb) bt > #0 0xb7ef8410 in __kernel_vsyscall () > #1 0xb7ad5085 in raise () from /lib/tls/i686/cmov/libc.so.6 > #2 0xb7ad6a01 in abort () from /lib/tls/i686/cmov/libc.so.6 > #3 0xb7ace10e in __assert_fail () from /lib/tls/i686/cmov/libc.so.6 > #4 0x0806d6c6 in connection_state_closing (c=0xb79c9644) at connection.c:686 > #5 0x08081bdd in send_ldap_ber (conn=0xb79c9644, ber=0xa143ab8c) at > result.c:147 > #6 0x08085b20 in slap_send_search_entry (op=0xa143ae38, rs=0xa143acdc) at > result.c:1246 > #7 0x0815dbcb in syncprov_sendresp (op=0xa143ae38, opc=0xa143adb8, > so=0x9ab66dc8, e=0xa143ade8, mode=1) at syncprov.c:825 > #8 0x0815df12 in syncprov_qplay (op=0xa143ae38, rtask=0x9b303110) at > syncprov.c:896 > #9 0x0815e1a7 in syncprov_qtask (ctx=0xa143b1f0, arg=0x9b303110) at > syncprov.c:959 > #10 0x0817a99b in ldap_int_thread_pool_wrapper (xpool=0x829baf0) at tpool.c:663 > #11 0xb7db14fb in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 > #12 0xb7b80e5e in clone () from /lib/tls/i686/cmov/libc.so.6 -- -- 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#6033) Segmentation fault - somewhere below syncprov_matchops / test_filter
by oskar＠deckle.co.za 25 Mar '09

25 Mar '09

Hi Further to this - please note that we know the dbconfig values in the config files are tiny - we use a DB_CONFIG file to override those, created before the ldap database is initialised. On master: set_cachesize 0 268435456 1 set_lg_regionmax 262144 set_lg_bsize 2097152 set_lk_max_objects 5000 set_lk_max_locks 5000 set_lk_max_lockers 5000 On clients: set_cachesize 0 16777216 0 set_lk_max_objects 1500 set_lk_max_locks 1500 set_lk_max_lockers 1500 Oskar

1 0

Re: (ITS#6034) Assert failure - connection_state_closing / send_ldap_ber / slap_send_search_entry / syncprov_sendresp
by oskar＠deckle.co.za 25 Mar '09

25 Mar '09

Hi Further to this - please note that we know the dbconfig values in the config files are tiny - we use a DB_CONFIG file to override those, created before the ldap database is initialised. On master: set_cachesize 0 268435456 1 set_lg_regionmax 262144 set_lg_bsize 2097152 set_lk_max_objects 5000 set_lk_max_locks 5000 set_lk_max_lockers 5000 On clients: set_cachesize 0 16777216 0 set_lk_max_objects 1500 set_lk_max_locks 1500 set_lk_max_lockers 1500 Oskar

1 0

(ITS#6034) Assert failure - connection_state_closing / send_ldap_ber / slap_send_search_entry / syncprov_sendresp
by oskar＠deckle.co.za 25 Mar '09

25 Mar '09

Full_Name: Oskar Pearson Version: 2.4.15 OS: Ubuntu hardy URL: ftp://ftp.openldap.org/incoming/slapd-configs-qualica-1.tar.gz Submission from: (NULL) (94.194.140.71) This is the same machine as ITS #6033. Details included here for easy reference: Openldap 2.4.15 (with no patches) was self-compiled with no patches (CFLAGS="-ggdb3 -O0" ./configure), linked against standard OS libraries (ubuntu hardy) for BDB etc. BDB is 4.6.21-6ubuntu1. Kernel is 2.6.24-19-server, libc is libc6-i686/2.7-10ubuntu3. I do not have a debug log of this crash as it occurred on a live server, which is too busy for that level of logging. I also do not have a replaceable example. I have core dumps and can print out whatever is necessary there - I appreciate your time and help. If I've missed some important info, please let me know and I'll rectify asap. System overview: We have a master server which replicates to > 100 machines for Samba purposes across ADSL lines with a VPN. These lines are quite busy, so replication writes may be slow across the network, which may have implications for locks. Config files are included at the url below. gdb --core=../core.29266 --directory=servers/slapd/ --directory=servers/slapd/overlays servers/slapd/slapd (gdb) bt #0 0xb7ef8410 in __kernel_vsyscall () #1 0xb7ad5085 in raise () from /lib/tls/i686/cmov/libc.so.6 #2 0xb7ad6a01 in abort () from /lib/tls/i686/cmov/libc.so.6 #3 0xb7ace10e in __assert_fail () from /lib/tls/i686/cmov/libc.so.6 #4 0x0806d6c6 in connection_state_closing (c=0xb79c9644) at connection.c:686 #5 0x08081bdd in send_ldap_ber (conn=0xb79c9644, ber=0xa143ab8c) at result.c:147 #6 0x08085b20 in slap_send_search_entry (op=0xa143ae38, rs=0xa143acdc) at result.c:1246 #7 0x0815dbcb in syncprov_sendresp (op=0xa143ae38, opc=0xa143adb8, so=0x9ab66dc8, e=0xa143ade8, mode=1) at syncprov.c:825 #8 0x0815df12 in syncprov_qplay (op=0xa143ae38, rtask=0x9b303110) at syncprov.c:896 #9 0x0815e1a7 in syncprov_qtask (ctx=0xa143b1f0, arg=0x9b303110) at syncprov.c:959 #10 0x0817a99b in ldap_int_thread_pool_wrapper (xpool=0x829baf0) at tpool.c:663 #11 0xb7db14fb in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #12 0xb7b80e5e in clone () from /lib/tls/i686/cmov/libc.so.6 (gdb) frame 4 #4 0x0806d6c6 in connection_state_closing (c=0xb79c9644) at connection.c:686 686 assert( c->c_struct_state == SLAP_C_USED ); (gdb) p c->c_struct_state $1 = 1 # maps to SLAP_C_UNUSED (gdb) p *c $4 = {c_struct_state = 1, c_conn_state = 0, c_conn_idx = 107, c_sd = -1, c_close_reason = 0x81b647b "?", c_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __kind = 0, __nusers = 0, {__spins = 0, __list = {__next = 0x0}}}, __size = '\0' <repeats 23 times>, __align = 0}, c_sb = 0x838c1b8, c_starttime = 0, c_activitytime = 0, c_connid = 4294967295, c_peer_domain = {bv_len = 0, bv_val = 0x0}, c_peer_name = {bv_len = 0, bv_val = 0x0}, c_listener = 0x0, 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 = 128, 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 = 0xb79c96e4}, c_pending_ops = {stqh_first = 0x0, stqh_last = 0xb79c96ec}, c_write1_mutex = {__data = {__lock = 1, __count = 0, __owner = 29297, __kind = 0, __nusers = 1, {__spins = 0, __list = {__next = 0x0}}}, __size = "\001\000\000\000\000\000\000\000qr\000\000\000\000\000\000\001\000\000\000\000\000\000", __align = 1}, 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 = '\0' <repeats 47 times>, __align = 0}, c_write2_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __kind = 0, __nusers = 0, { __spins = 0, __list = {__next = 0x0}}}, __size = '\0' <repeats 23 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 = '\0' <repeats 47 times>, __align = 0}, c_currentber = 0x0, c_writers = 0, c_sasl_bind_in_progress = 0 '\0', c_writewaiter = 0 '\0', c_is_tls = 0 '\0', c_needs_tls_accept = 0 '\0', c_sasl_layers = 0 '\0', c_sasl_done = 0 '\0', 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 = 2, c_n_ops_executing = 0, c_n_ops_pending = 0, c_n_ops_completed = 2, c_n_get = 3, c_n_read = 2, c_n_write = 0, c_extensions = 0x0, c_clientfunc = 0, c_clientarg = 0x0, c_send_ldap_result = 0x8082e44 <slap_send_ldap_result>, c_send_search_entry = 0x8083b12 <slap_send_search_entry>, c_send_search_reference = 0x8085e4b <slap_send_search_reference>, c_send_ldap_extended = 0x8083676 <slap_send_ldap_extended>, c_send_ldap_intermediate = 0x80838fe <slap_send_ldap_intermediate>} frame 6 is the first location I have "op" access, so I then went (gdb) frame 6 (gdb) p *op $10 = {o_hdr = 0xa143af10, o_tag = 99, o_time = 1236686741, o_tincr = 0, o_bd = 0xa143b0b8, o_req_dn = {bv_len = 18, bv_val = 0x9dcd15ee "dc=HIDDEN-gw,dc=com"}, o_req_ndn = {bv_len = 18, bv_val = 0x9dcd1601 "dc=HIDDEN-gw,dc=com"}, o_request = {oq_add = { rs_modlist = 0x2, rs_e = 0x0}, oq_bind = {rb_method = 2, rb_cred = {bv_len = 0, bv_val = 0xffffffff <Address 0xffffffff out of bounds>}, rb_edn = { bv_len = 4294967295, bv_val = 0x0}, rb_ssf = 0, rb_mech = {bv_len = 2647463064, bv_val = 0x9dc1bbe8 "\207"}}, oq_compare = {rs_ava = 0x2}, oq_modify = {rs_mods = {rs_modlist = 0x2, rs_no_opattrs = 0 '\0'}, rs_increment = -1}, oq_modrdn = {rs_mods = {rs_modlist = 0x2, rs_no_opattrs = 0 '\0'}, rs_deleteoldrdn = -1, rs_newrdn = {bv_len = 4294967295, bv_val = 0x0}, rs_nnewrdn = {bv_len = 0, bv_val = 0x9dcd1498 "\t"}, rs_newSup = 0x9dc1bbe8, rs_nnewSup = 0xf}, oq_search = {rs_scope = 2, rs_deref = 0, rs_slimit = -1, rs_tlimit = -1, rs_limit = 0x0, rs_attrsonly = 0, rs_attrs = 0x9dcd1498, rs_filter = 0x9dc1bbe8, rs_filterstr = {bv_len = 15, bv_val = 0x9dcd1614 "(objectClass=*)"}}, oq_abandon = {rs_msgid = 2}, oq_cancel = {rs_msgid = 2}, oq_extended = {rs_reqoid = {bv_len = 2, bv_val = 0x0}, rs_flags = -1, rs_reqdata = 0xffffffff}, oq_pwdexop = {rs_extended = {rs_reqoid = {bv_len = 2, bv_val = 0x0}, rs_flags = -1, rs_reqdata = 0xffffffff}, rs_old = {bv_len = 0, bv_val = 0x0}, rs_new = {bv_len = 2647463064, bv_val = 0x9dc1bbe8 "\207"}, rs_mods = 0xf, rs_modtail = 0x9dcd1614}}, o_abandon = 0, o_cancel = 0, o_groups = 0x0, o_do_not_cache = 1 '\001', o_is_auth_check = 0 '\0', o_dont_replicate = 0 '\0', o_acl_priv = ACL_NONE, o_nocaching = 0 '\0', o_delete_glue_parent = 0 '\0', o_no_schema_check = 0 '\0', o_no_subordinate_glue = 0 '\0', o_ctrlflag = '\0' <repeats 31 times>, o_controls = 0xa143b038, o_authz = {sai_method = 128, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 27, bv_val = 0x9dcd15d2 "cn=admin,dc=HIDDEN-gw,dc=com"}, sai_ndn = {bv_len = 27, bv_val = 0x9dcd15d2 "cn=admin,dc=HIDDEN-gw,dc=com"}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, o_ber = 0x0, o_res_ber = 0x0, o_callback = 0x0, o_ctrls = 0x0, o_csn = {bv_len = 0, bv_val = 0x0}, o_private = 0x0, o_extra = {slh_first = 0x0}, o_next = { stqe_next = 0x0}} Full backtrace: Thread 10 (process 29266): #0 0xb7ef8410 in __kernel_vsyscall () #1 0xb7db2775 in pthread_join () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x0817ba95 in ldap_pvt_thread_join (thread=2730757008, thread_return=0x0) at thr_posix.c:197 #3 0x0806ba57 in slapd_daemon () at daemon.c:2665 #4 0x0804e8c7 in main (argc=1, argv=0xbfe1d2e4) at main.c:948 Thread 9 (process 29268): #0 0xb7ef8410 in __kernel_vsyscall () #1 0xb7b81676 in epoll_wait () from /lib/tls/i686/cmov/libc.so.6 #2 0x0806abee in slapd_daemon_task (ptr=0x0) at daemon.c:2291 #3 0xb7db14fb in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #4 0xb7b80e5e in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 8 (process 29269): #0 0xb7ef8410 in __kernel_vsyscall () #1 0xb7db5aa5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x0817bb2a in ldap_pvt_thread_cond_wait (cond=0xb79ccf88, mutex=0xb79ccf70) at thr_posix.c:277 #3 0x08081eac in send_ldap_ber (conn=0xb79cce78, ber=0xa203db8c) at result.c:217 #4 0x08085b20 in slap_send_search_entry (op=0xa203de38, rs=0xa203dcdc) at result.c:1246 #5 0x0815dbcb in syncprov_sendresp (op=0xa203de38, opc=0xa203ddb8, so=0x9dc65f10, e=0xa203dde8, mode=1) at syncprov.c:825 #6 0x0815df12 in syncprov_qplay (op=0xa203de38, rtask=0x9b30c640) at syncprov.c:896 #7 0x0815e1a7 in syncprov_qtask (ctx=0xa203e1f0, arg=0x9b30c640) at syncprov.c:959 #8 0x0817a99b in ldap_int_thread_pool_wrapper (xpool=0x829baf0) at tpool.c:663 #9 0xb7db14fb in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #10 0xb7b80e5e in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 7 (process 29295): #0 0xb7ef8410 in __kernel_vsyscall () #1 0xb7db5aa5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x0817bb2a in ldap_pvt_thread_cond_wait (cond=0xb79ce090, mutex=0xb79ce078) at thr_posix.c:277 #3 0x08081eac in send_ldap_ber (conn=0xb79cdf80, ber=0xa1c3cb8c) at result.c:217 #4 0x08085b20 in slap_send_search_entry (op=0xa1c3ce38, rs=0xa1c3ccdc) at result.c:1246 #5 0x0815dbcb in syncprov_sendresp (op=0xa1c3ce38, opc=0xa1c3cdb8, so=0x9ab8ecd8, e=0xa1c3cde8, mode=1) at syncprov.c:825 #6 0x0815df12 in syncprov_qplay (op=0xa1c3ce38, rtask=0x9af477a8) at syncprov.c:896 #7 0x0815e1a7 in syncprov_qtask (ctx=0xa1c3d1f0, arg=0x9af477a8) at syncprov.c:959 #8 0x0817a99b in ldap_int_thread_pool_wrapper (xpool=0x829baf0) at tpool.c:663 #9 0xb7db14fb in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #10 0xb7b80e5e in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 6 (process 29296): #0 0xb7ef8410 in __kernel_vsyscall () #1 0xb7db5aa5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x0817bb2a in ldap_pvt_thread_cond_wait (cond=0xb79cf500, mutex=0xb79cf4e8) at thr_posix.c:277 #3 0x08081eac in send_ldap_ber (conn=0xb79cf3f0, ber=0xa183bb8c) at result.c:217 #4 0x08085b20 in slap_send_search_entry (op=0xa183be38, rs=0xa183bcdc) at result.c:1246 #5 0x0815dbcb in syncprov_sendresp (op=0xa183be38, opc=0xa183bdb8, so=0xa0ae45c8, e=0xa183bde8, mode=1) at syncprov.c:825 #6 0x0815df12 in syncprov_qplay (op=0xa183be38, rtask=0x9ab5e400) at syncprov.c:896 #7 0x0815e1a7 in syncprov_qtask (ctx=0xa183c1f0, arg=0x9ab5e400) at syncprov.c:959 #8 0x0817a99b in ldap_int_thread_pool_wrapper (xpool=0x829baf0) at tpool.c:663 #9 0xb7db14fb in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #10 0xb7b80e5e in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 5 (process 29298): #0 0xb7ef8410 in __kernel_vsyscall () #1 0xb7db5aa5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x0817bb2a in ldap_pvt_thread_cond_wait (cond=0xb79c8d1c, mutex=0xb79c8d04) at thr_posix.c:277 #3 0x08081eac in send_ldap_ber (conn=0xb79c8c0c, ber=0xa1039b8c) at result.c:217 #4 0x08085b20 in slap_send_search_entry (op=0xa1039e38, rs=0xa1039cdc) at result.c:1246 #5 0x0815dbcb in syncprov_sendresp (op=0xa1039e38, opc=0xa1039db8, so=0x9dc0bed0, e=0xa1039de8, mode=2) at syncprov.c:825 #6 0x0815df12 in syncprov_qplay (op=0xa1039e38, rtask=0x83781c8) at syncprov.c:896 #7 0x0815e1a7 in syncprov_qtask (ctx=0xa103a1f0, arg=0x83781c8) at syncprov.c:959 #8 0x0817a99b in ldap_int_thread_pool_wrapper (xpool=0x829baf0) at tpool.c:663 #9 0xb7db14fb in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #10 0xb7b80e5e in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 4 (process 29300): #0 0xb7ef8410 in __kernel_vsyscall () #1 0xb7db5aa5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x0817bb2a in ldap_pvt_thread_cond_wait (cond=0xb79cefe4, mutex=0xb79cefcc) at thr_posix.c:277 #3 0x08081eac in send_ldap_ber (conn=0xb79ceed4, ber=0x9dbfeb8c) at result.c:217 #4 0x08085b20 in slap_send_search_entry (op=0x9dbfee38, rs=0x9dbfecdc) at result.c:1246 #5 0x0815dbcb in syncprov_sendresp (op=0x9dbfee38, opc=0x9dbfedb8, so=0x9ab63788, e=0x9dbfede8, mode=1) at syncprov.c:825 #6 0x0815df12 in syncprov_qplay (op=0x9dbfee38, rtask=0xa0a03b60) at syncprov.c:896 #7 0x0815e1a7 in syncprov_qtask (ctx=0x9dbff1f0, arg=0xa0a03b60) at syncprov.c:959 #8 0x0817a99b in ldap_int_thread_pool_wrapper (xpool=0x829baf0) at tpool.c:663 #9 0xb7db14fb in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #10 0xb7b80e5e in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 3 (process 29301): #0 0xb7ef8410 in __kernel_vsyscall () #1 0xb7db5aa5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x0817bb2a in ldap_pvt_thread_cond_wait (cond=0xb79bfaa4, mutex=0xb79bfa8c) at thr_posix.c:277 #3 0x08081eac in send_ldap_ber (conn=0xb79bf994, ber=0x9cefbb8c) at result.c:217 #4 0x08085b20 in slap_send_search_entry (op=0x9cefbe38, rs=0x9cefbcdc) at result.c:1246 #5 0x0815dbcb in syncprov_sendresp (op=0x9cefbe38, opc=0x9cefbdb8, so=0x9af1df00, e=0x9cefbde8, mode=1) at syncprov.c:825 #6 0x0815df12 in syncprov_qplay (op=0x9cefbe38, rtask=0xa0a33d90) at syncprov.c:896 #7 0x0815e1a7 in syncprov_qtask (ctx=0x9cefc1f0, arg=0xa0a33d90) at syncprov.c:959 #8 0x0817a99b in ldap_int_thread_pool_wrapper (xpool=0x829baf0) at tpool.c:663 #9 0xb7db14fb in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #10 0xb7b80e5e in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 2 (process 29302): #0 0xb7ef8410 in __kernel_vsyscall () #1 0xb7db5aa5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x0817bb2a in ldap_pvt_thread_cond_wait (cond=0xb79cb0e0, mutex=0xb79cb0c8) at thr_posix.c:277 #3 0x08081eac in send_ldap_ber (conn=0xb79cafd0, ber=0x9cafab8c) at result.c:217 #4 0x08085b20 in slap_send_search_entry (op=0x9cafae38, rs=0x9cafacdc) at result.c:1246 #5 0x0815dbcb in syncprov_sendresp (op=0x9cafae38, opc=0x9cafadb8, so=0x9af21c10, e=0x9cafade8, mode=1) at syncprov.c:825 #6 0x0815df12 in syncprov_qplay (op=0x9cafae38, rtask=0xa0a31988) at syncprov.c:896 #7 0x0815e1a7 in syncprov_qtask (ctx=0x9cafb1f0, arg=0xa0a31988) at syncprov.c:959 #8 0x0817a99b in ldap_int_thread_pool_wrapper (xpool=0x829baf0) at tpool.c:663 #9 0xb7db14fb in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #10 0xb7b80e5e in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 1 (process 29297): #0 0xb7ef8410 in __kernel_vsyscall () #1 0xb7ad5085 in raise () from /lib/tls/i686/cmov/libc.so.6 #2 0xb7ad6a01 in abort () from /lib/tls/i686/cmov/libc.so.6 #3 0xb7ace10e in __assert_fail () from /lib/tls/i686/cmov/libc.so.6 #4 0x0806d6c6 in connection_state_closing (c=0xb79c9644) at connection.c:686 #5 0x08081bdd in send_ldap_ber (conn=0xb79c9644, ber=0xa143ab8c) at result.c:147 #6 0x08085b20 in slap_send_search_entry (op=0xa143ae38, rs=0xa143acdc) at result.c:1246 #7 0x0815dbcb in syncprov_sendresp (op=0xa143ae38, opc=0xa143adb8, so=0x9ab66dc8, e=0xa143ade8, mode=1) at syncprov.c:825 #8 0x0815df12 in syncprov_qplay (op=0xa143ae38, rtask=0x9b303110) at syncprov.c:896 #9 0x0815e1a7 in syncprov_qtask (ctx=0xa143b1f0, arg=0x9b303110) at syncprov.c:959 #10 0x0817a99b in ldap_int_thread_pool_wrapper (xpool=0x829baf0) at tpool.c:663 #11 0xb7db14fb in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #12 0xb7b80e5e in clone () from /lib/tls/i686/cmov/libc.so.6 Thanks for your time! Oskar

1 0

(ITS#6033) Segmentation fault - somewhere below syncprov_matchops / test_filter
by oskar＠deckle.co.za 25 Mar '09

25 Mar '09

Full_Name: Oskar Pearson Version: 2.4.15 OS: Ubuntu hardy URL: ftp://ftp.openldap.org/incoming/slapd-configs-qualica-1.tar.gz Submission from: (NULL) (94.194.140.71) Openldap 2.4.15 (with no patches) was self-compiled with no patches (CFLAGS="-ggdb3 -O0" ./configure), linked against standard OS libraries (ubuntu hardy) for BDB etc. BDB is 4.6.21-6ubuntu1. Kernel is 2.6.24-19-server, libc is libc6-i686/2.7-10ubuntu3. I do not have a debug log of this crash as it occurred on a live server, which is too busy for that level of logging. I also do not have a replaceable example. I have core dumps and can print out whatever is necessary there - I appreciate your time and help. If I've missed some important info, please let me know and I'll rectify asap. System overview: We have a master server which replicates to > 100 machines for Samba purposes across ADSL lines with a VPN. These lines are quite busy, so replication writes may be slow across the network, which may have implications for locks. Config files are included at the url below. The specific crash was in thread 1. Other threads are included in a full backtrace below. gdb --core=../core.24122 --directory=servers/slapd/ --directory=servers/slapd/overlays servers/slapd/slapd #0 0x080c0e82 in is_ad_subtype (sub=0x0, super=0x8294e08) at ad.c:502 502 for ( a = sub->ad_type; a; a=a->sat_sup ) { Thread 1 (process 24208): #0 0x080c0e82 in is_ad_subtype (sub=0x0, super=0x8294e08) at ad.c:502 #1 0x0807a6da in attrs_find (a=0xa2d39fa4, desc=0x8294e08) at attr.c:645 #2 0x080964dd in test_presence_filter (op=0x9e6f1b08, e=0x83277f4, desc=0x8294e08) at filterentry.c:848 #3 0x080951ce in test_filter (op=0x9e6f1b08, e=0x83277f4, f=0x9ae022a8) at filterentry.c:108 #4 0x0815efdf in syncprov_matchops (op=0x83455c8, opc=0x9cfed214, saveit=1) at syncprov.c:1251 #5 0x08160fd9 in syncprov_op_mod (op=0x83455c8, rs=0x9e6f3100) at syncprov.c:1905 #6 0x080f1396 in overlay_op_walk (op=0x83455c8, rs=0x9e6f3100, which=op_modify, oi=0x82d19c8, on=0x82d1ac8) at backover.c:659 #7 0x080f161e in over_op_func (op=0x83455c8, rs=0x9e6f3100, which=op_modify) at backover.c:721 #8 0x080f1706 in over_op_modify (op=0x83455c8, rs=0x9e6f3100) at backover.c:755 #9 0x0808c802 in fe_op_modify (op=0x83455c8, rs=0x9e6f3100) at modify.c:301 #10 0x0808c115 in do_modify (op=0x83455c8, rs=0x9e6f3100) at modify.c:175 #11 0x0806e7c2 in connection_operation (ctx=0x9e6f31f0, arg_v=0x83455c8) at connection.c:1097 #12 0x0806ec9c in connection_read_thread (ctx=0x9e6f31f0, argv=0x39) at connection.c:1223 #13 0x0817a99b in ldap_int_thread_pool_wrapper (xpool=0x829baf0) at tpool.c:663 #14 0xb7da14fb in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #15 0xb7b70e5e in clone () from /lib/tls/i686/cmov/libc.so.6 (gdb) p sub $15 = (AttributeDescription *) 0x0 (gdb) up #1 0x0807a6da in attrs_find (a=0xa2d39fa4, desc=0x8294e08) at attr.c:645 645 if ( is_ad_subtype( a->a_desc, desc ) ) { (gdb) p *a $24 = {a_desc = 0x0, a_vals = 0x0, a_nvals = 0x0, a_numvals = 0, a_flags = 0, a_next = 0xa2d39d1c} (gdb) p *desc $32 = {ad_next = 0x0, ad_type = 0x8294d30, ad_cname = {bv_len = 11, bv_val = 0x8294ca8 "objectClass"}, ad_tags = {bv_len = 0, bv_val = 0x0}, ad_flags = 0} (gdb) p *op $33 = {o_hdr = 0x9e6f18e8, o_tag = 99, o_time = 1236840350, o_tincr = 0, o_bd = 0x82b5af8, o_req_dn = {bv_len = 18, bv_val = 0x9ae0360e "dc=HIDDEN-gw,dc=com"}, o_req_ndn = {bv_len = 18, bv_val = 0x9ae03621 "dc=HIDDEN-gw,dc=com"}, o_request = {oq_add = { rs_modlist = 0x2, rs_e = 0x0}, oq_bind = {rb_method = 2, rb_cred = {bv_len = 0, bv_val = 0xffffffff <Address 0xffffffff out of bounds>}, rb_edn = { bv_len = 4294967295, bv_val = 0x0}, rb_ssf = 0, rb_mech = {bv_len = 2598384824, bv_val = 0x9ae022a8 "\207"}}, oq_compare = {rs_ava = 0x2}, oq_modify = {rs_mods = {rs_modlist = 0x2, rs_no_opattrs = 0 '\0'}, rs_increment = -1}, oq_modrdn = {rs_mods = {rs_modlist = 0x2, rs_no_opattrs = 0 '\0'}, rs_deleteoldrdn = -1, rs_newrdn = {bv_len = 4294967295, bv_val = 0x0}, rs_nnewrdn = {bv_len = 0, bv_val = 0x9ae034b8 "\t"}, rs_newSup = 0x9ae022a8, rs_nnewSup = 0xf}, oq_search = {rs_scope = 2, rs_deref = 0, rs_slimit = -1, rs_tlimit = -1, rs_limit = 0x0, rs_attrsonly = 0, rs_attrs = 0x9ae034b8, rs_filter = 0x9ae022a8, rs_filterstr = {bv_len = 15, bv_val = 0x9ae03634 "(objectClass=*)"}}, oq_abandon = {rs_msgid = 2}, oq_cancel = {rs_msgid = 2}, oq_extended = {rs_reqoid = {bv_len = 2, bv_val = 0x0}, rs_flags = -1, rs_reqdata = 0xffffffff}, oq_pwdexop = {rs_extended = {rs_reqoid = {bv_len = 2, bv_val = 0x0}, rs_flags = -1, rs_reqdata = 0xffffffff}, rs_old = {bv_len = 0, bv_val = 0x0}, rs_new = {bv_len = 2598384824, bv_val = 0x9ae022a8 "\207"}, rs_mods = 0xf, rs_modtail = 0x9ae03634}}, o_abandon = 0, o_cancel = 0, o_groups = 0x0, o_do_not_cache = 1 '\001', o_is_auth_check = 0 '\0', o_dont_replicate = 0 '\0', o_acl_priv = ACL_NONE, o_nocaching = 0 '\0', o_delete_glue_parent = 0 '\0', o_no_schema_check = 0 '\0', o_no_subordinate_glue = 0 '\0', o_ctrlflag = '\0' <repeats 31 times>, o_controls = 0x0, o_authz = {sai_method = 128, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 27, bv_val = 0x9ae035f2 "cn=admin,dc=HIDDEN-gw,dc=com"}, sai_ndn = {bv_len = 27, bv_val = 0x9ae035f2 "cn=admin,dc=HIDDEN-gw,dc=com"}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, o_ber = 0x0, o_res_ber = 0x0, o_callback = 0x0, o_ctrls = 0x0, o_csn = {bv_len = 0, bv_val = 0x0}, o_private = 0x0, o_extra = {slh_first = 0x9cfed24c}, o_next = { stqe_next = 0x0}} (gdb) p *e $34 = {e_id = 0, e_name = {bv_len = 39, bv_val = 0x0}, e_nname = {bv_len = 39, bv_val = 0x0}, e_attrs = 0x0, e_ocflags = 0, e_bv = {bv_len = 0, bv_val = 0x0}, e_private = 0x83277a4} (gdb) p *desc $35 = {ad_next = 0x0, ad_type = 0x8294d30, ad_cname = {bv_len = 11, bv_val = 0x8294ca8 "objectClass"}, ad_tags = {bv_len = 0, bv_val = 0x0}, ad_flags = 0} --- full backtrace follows: thread apply all bt Thread 10 (process 24122): #0 0xb7ee8410 in __kernel_vsyscall () #1 0xb7da2775 in pthread_join () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x0817ba95 in ldap_pvt_thread_join (thread=2730691472, thread_return=0x0) at thr_posix.c:197 #3 0x0806ba57 in slapd_daemon () at daemon.c:2665 #4 0x0804e8c7 in main (argc=1, argv=0xbffcccc4) at main.c:948 Thread 9 (process 24127): #0 0xb7ee8410 in __kernel_vsyscall () #1 0xb7b71676 in epoll_wait () from /lib/tls/i686/cmov/libc.so.6 #2 0x0806abee in slapd_daemon_task (ptr=0x0) at daemon.c:2291 #3 0xb7da14fb in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #4 0xb7b70e5e in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 8 (process 24128): #0 0xb7ee8410 in __kernel_vsyscall () #1 0xb7da5aa5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x0817bb2a in ldap_pvt_thread_cond_wait (cond=0xb79af8f0, mutex=0xb79af8d8) at thr_posix.c:277 #3 0x08081eac in send_ldap_ber (conn=0xb79af7e0, ber=0xa202db8c) at result.c:217 #4 0x08085b20 in slap_send_search_entry (op=0xa202de38, rs=0xa202dcdc) at result.c:1246 #5 0x0815dbcb in syncprov_sendresp (op=0xa202de38, opc=0xa202ddb8, so=0xa1bb3490, e=0xa202dde8, mode=2) at syncprov.c:825 #6 0x0815df12 in syncprov_qplay (op=0xa202de38, rtask=0x9ae030b8) at syncprov.c:896 #7 0x0815e1a7 in syncprov_qtask (ctx=0xa202e1f0, arg=0x9ae030b8) at syncprov.c:959 #8 0x0817a99b in ldap_int_thread_pool_wrapper (xpool=0x829baf0) at tpool.c:663 #9 0xb7da14fb in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #10 0xb7b70e5e in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 7 (process 24169): #0 0xb7ee8410 in __kernel_vsyscall () #1 0xb7da5aa5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x0817bb2a in ldap_pvt_thread_cond_wait (cond=0xb79b6958, mutex=0xb79b6940) at thr_posix.c:277 #3 0x08081eac in send_ldap_ber (conn=0xb79b6848, ber=0xa1afeb8c) at result.c:217 #4 0x08085b20 in slap_send_search_entry (op=0xa1afee38, rs=0xa1afecdc) at result.c:1246 #5 0x0815dbcb in syncprov_sendresp (op=0xa1afee38, opc=0xa1afedb8, so=0x8a0deb0, e=0xa1afede8, mode=2) at syncprov.c:825 #6 0x0815df12 in syncprov_qplay (op=0xa1afee38, rtask=0x8a12e20) at syncprov.c:896 #7 0x0815e1a7 in syncprov_qtask (ctx=0xa1aff1f0, arg=0x8a12e20) at syncprov.c:959 #8 0x0817a99b in ldap_int_thread_pool_wrapper (xpool=0x829baf0) at tpool.c:663 #9 0xb7da14fb in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #10 0xb7b70e5e in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 3 (process 24209): #0 0xb7ee8410 in __kernel_vsyscall () #1 0xb7da5aa5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x0817bb2a in ldap_pvt_thread_cond_wait (cond=0xb79b28a0, mutex=0xb79b2888) at thr_posix.c:277 #3 0x08081eac in send_ldap_ber (conn=0xb79b2790, ber=0x9d9efb8c) at result.c:217 #4 0x08085b20 in slap_send_search_entry (op=0x9d9efe38, rs=0x9d9efcdc) at result.c:1246 #5 0x0815dbcb in syncprov_sendresp (op=0x9d9efe38, opc=0x9d9efdb8, so=0x8a01da0, e=0x9d9efde8, mode=2) at syncprov.c:825 #6 0x0815df12 in syncprov_qplay (op=0x9d9efe38, rtask=0x9ad957e0) at syncprov.c:896 #7 0x0815e1a7 in syncprov_qtask (ctx=0x9d9f01f0, arg=0x9ad957e0) at syncprov.c:959 #8 0x0817a99b in ldap_int_thread_pool_wrapper (xpool=0x829baf0) at tpool.c:663 #9 0xb7da14fb in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #10 0xb7b70e5e in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 2 (process 24210): #0 0xb7b0d9bc in memcpy () from /lib/tls/i686/cmov/libc.so.6 #1 0xb7e7e6cd in __db_retcopy () from /usr/lib/libdb-4.6.so #2 0xb7e7e80b in __db_ret () from /usr/lib/libdb-4.6.so #3 0xb7e6126b in __dbc_get () from /usr/lib/libdb-4.6.so #4 0xb7e6a04b in __dbc_get_pp () from /usr/lib/libdb-4.6.so #5 0x0814fd28 in hdb_id2entry (be=0x9d5edefc, tid=0xa1b11180, id=2355, e=0x9d52d958) at id2entry.c:151 #6 0x081431e9 in hdb_cache_find_id (op=0x9d5edc24, tid=0xa1b11180, id=2355, eip=0x9d5edaf8, flag=2, lock=0x9d5eda90) at cache.c:923 #7 0x081158a5 in hdb_search (op=0x9d5edc24, rs=0x9d5edb78) at search.c:705 #8 0x08160364 in syncprov_playlog (op=0xa1b0a300, rs=0x9d5ef100, sl=0x82d1c50, srs=0x9c6eb264, ctxcsn=0x9c6eb31c, numcsns=1, sids=0x9c6eb364) at syncprov.c:1592 #9 0x08162893 in syncprov_op_search (op=0xa1b0a300, rs=0x9d5ef100) at syncprov.c:2348 #10 0x080f1396 in overlay_op_walk (op=0xa1b0a300, rs=0x9d5ef100, which=op_search, oi=0x82d19c8, on=0x82d1ac8) at backover.c:659 #11 0x080f161e in over_op_func (op=0xa1b0a300, rs=0x9d5ef100, which=op_search) at backover.c:721 #12 0x080f16c2 in over_op_search (op=0xa1b0a300, rs=0x9d5ef100) at backover.c:743 #13 0x08072169 in fe_op_search (op=0xa1b0a300, rs=0x9d5ef100) at search.c:366 #14 0x08071adc in do_search (op=0xa1b0a300, rs=0x9d5ef100) at search.c:217 #15 0x0806e7c2 in connection_operation (ctx=0x9d5ef1f0, arg_v=0xa1b0a300) at connection.c:1097 #16 0x0806ec9c in connection_read_thread (ctx=0x9d5ef1f0, argv=0x1d) at connection.c:1223 #17 0x0817a99b in ldap_int_thread_pool_wrapper (xpool=0x829baf0) at tpool.c:663 #18 0xb7da14fb in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #19 0xb7b70e5e in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 1 (process 24208): #0 0x080c0e82 in is_ad_subtype (sub=0x0, super=0x8294e08) at ad.c:502 #1 0x0807a6da in attrs_find (a=0xa2d39fa4, desc=0x8294e08) at attr.c:645 #2 0x080964dd in test_presence_filter (op=0x9e6f1b08, e=0x83277f4, desc=0x8294e08) at filterentry.c:848 #3 0x080951ce in test_filter (op=0x9e6f1b08, e=0x83277f4, f=0x9ae022a8) at filterentry.c:108 #4 0x0815efdf in syncprov_matchops (op=0x83455c8, opc=0x9cfed214, saveit=1) at syncprov.c:1251 #5 0x08160fd9 in syncprov_op_mod (op=0x83455c8, rs=0x9e6f3100) at syncprov.c:1905 #6 0x080f1396 in overlay_op_walk (op=0x83455c8, rs=0x9e6f3100, which=op_modify, oi=0x82d19c8, on=0x82d1ac8) at backover.c:659 #7 0x080f161e in over_op_func (op=0x83455c8, rs=0x9e6f3100, which=op_modify) at backover.c:721 #8 0x080f1706 in over_op_modify (op=0x83455c8, rs=0x9e6f3100) at backover.c:755 #9 0x0808c802 in fe_op_modify (op=0x83455c8, rs=0x9e6f3100) at modify.c:301 #10 0x0808c115 in do_modify (op=0x83455c8, rs=0x9e6f3100) at modify.c:175 #11 0x0806e7c2 in connection_operation (ctx=0x9e6f31f0, arg_v=0x83455c8) at connection.c:1097 #12 0x0806ec9c in connection_read_thread (ctx=0x9e6f31f0, argv=0x39) at connection.c:1223 #13 0x0817a99b in ldap_int_thread_pool_wrapper (xpool=0x829baf0) at tpool.c:663 #14 0xb7da14fb in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #15 0xb7b70e5e in clone () from /lib/tls/i686/cmov/libc.so.6 Thanks for your time, Oskar

1 0

Re: (ITS#6032) lap_add: Invalid DN syntax (34) additional info: invalid DN
by quanah＠zimbra.com 25 Mar '09

25 Mar '09

--On Wednesday, March 25, 2009 11:52 AM +0000 sudeshchandimal(a)gmail.com wrote: > Full_Name: sudesh chandimal > Version: openldap-2.4.15 > OS: fedora > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (124.43.51.7) > > > lap_add: Invalid DN syntax (34) > additional info: invalid DN > > this is the error i'm getting after runing this ldif file.. > ># Base object for Request Balance > dn: dview=ECS1_request_bal, dc=my-domain, dc=com > dview: ECS1_request_bal > objectClass: top > objectClass: dview > userPassword: balance Send usage questions to openldap-software(a)openldap.org, not the ITS system. The ITS system is for reporting bugs in the software. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6032) lap_add: Invalid DN syntax (34) additional info: invalid DN
by sudeshchandimal＠gmail.com 25 Mar '09

25 Mar '09

Full_Name: sudesh chandimal Version: openldap-2.4.15 OS: fedora URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (124.43.51.7) lap_add: Invalid DN syntax (34) additional info: invalid DN this is the error i'm getting after runing this ldif file.. # Base object for Request Balance dn: dview=ECS1_request_bal, dc=my-domain, dc=com dview: ECS1_request_bal objectClass: top objectClass: dview userPassword: balance ldif file.............. ldapadd -x -D "cn=Manager, dc=my-domain, dc=com" -w secret -f add_request_bal_entry.ldif please please help me.. quickly....!

1 0

(ITS#6031) An account locked on consumer is unlocked only when password is changed twice in a row on provider
by stlist＠gmail.com 24 Mar '09

24 Mar '09

Full_Name: Samuel Tran Version: 2.3.43 OS: CentOS 5.x URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (216.73.248.203) If I lock an account on a consumer 'pwdMaxFailure' consecutive failed bind attempts, two password changes on the provider is required to unlock the account on the consumer. The first password change updates 'userPassword', 'pwdChangedTime' and removes 'pwdFailureTime'. The second updates 'userPassword', 'pwdChangedTime' and removes 'pwdAccountLockedTime'. The replication mode is delta-syncrepl. Here is the configuration file on the provider: #------------------------------------------------- # Accesslog DB definition (slapo-accesslog) #------------------------------------------------- database hdb suffix "cn=accesslog" rootdn "cn=root,cn=accesslog" rootpw {SSHA}xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx directory /var/lib/ldap/accesslog index default eq index entryUUID,entryCSN,objectClass,reqEnd,reqResult,reqStart limits dn.exact="cn=syncrepl,ou=Accounts,ou=Apps,dc=example,dc=com" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited overlay syncprov syncprov-nopresent TRUE syncprov-reloadhint TRUE #------------------------------------------------- # Primary example.com database definition #------------------------------------------------- database hdb suffix "dc=example,dc=com" rootdn "cn=Manager,dc=example,dc=com" rootpw {SSHA}xxxxxxxxxxxxxxxxxxxxxxxxxxx directory /var/lib/ldap/example.com [snip] index objectClass,uidNumber,gidNumber,memberUid,employeeNumber eq,pres index employeeType,accountActive,ftpActive,mailActive,vacationActive,ou,mailRoutingAddress eq index cn,mail,surname,givenname eq,pres,subinitial index displayName,gecos,telephoneNumber sub,subany index uid,aliasUid eq,sub,subany index entryUUID,entryCSN eq limits dn.exact="cn=syncrepl,ou=Accounts,ou=Apps,dc=example,dc=com" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited overlay syncprov syncprov-checkpoint 100 30 syncprov-sessionlog 100 overlay accesslog logdb cn=accesslog logops writes logsuccess TRUE logpurge 28+00:00 01+00:00 overlay ppolicy ppolicy_use_lockout Here is the configuration file on the consumer: #------------------------------------------------- # Primary example.com database definition #------------------------------------------------- database hdb suffix "dc=example,dc=com" rootdn "cn=Manager,dc=example,dc=com" rootpw {SSHA}xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx directory /var/lib/ldap/example.com [snip] index objectClass,uidNumber,gidNumber,memberUid,employeeNumber eq,pres index employeeType,accountActive,ftpActive,mailActive,vacationActive,ou,mailRoutingAddress,mailAlternateAddress,mailAliasActive,allowedService eq index cn,mail,surname,givenname eq,pres,subinitial index displayName,gecos,telephoneNumber sub,subany index uid,aliasUid eq,sub,subany index entryUUID eq ############################################################# # Syncrepl - Consumer configuration ############################################################# syncrepl rid=002 provider=ldaps://info-ldap-001.example.com:636 bindmethod=simple binddn="cn=syncrepl,ou=Accounts,ou=Apps,dc=example,dc=com" credentials=xxxxxxxx type=refreshAndPersist retry="5 +" searchbase="dc=example,dc=com" logbase="cn=accesslog" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" schemachecking=on syncdata=accesslog overlay ppolicy ppolicy_use_lockout The problem is similar to the one reported in ITS #5398 for OL 2.4.8. I saw Howard's reply stating that he was not able to reproduce the problem in the current OL 2.4.x code. I was wondering if someone was able to reproduce the problem using OL 2.3.43. Thanks.

1 0

Re: (ITS#6030) slapd segfaults when loading already present module
by luca.scamoni＠sys-net.it 23 Mar '09

23 Mar '09

Tested latest commit and it's fixed now thanks Ing. Luca Scamoni Responsabile Ricerca e Sviluppo SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 0382 573859 (137) Mobile: +39 347 1014425 Fax: +39 0382 476497 Email: luca.scamoni(a)sys-net.it -----------------------------------

1 0

Re: (ITS#6030) slapd segfaults when loading already present module
by hyc＠symas.com 23 Mar '09

23 Mar '09

Luca Scamoni wrote: > Howard Chu ha scritto: >> HEAD has been changed to silently ignore these cases, please test. >> >> (I guess we could log something at LDAP_DEBUG_CONFIG level but that >> seems unnecessary at the moment.) >> > thanks, > now it doesn't segfaults anymore but something like: > modulepath /usr/local/openldap/sbin > moduleload syncprov.la > moduleload back_hdb.la > moduleload syncprov.la > > becomes: > dn: cn=module{0},cn=config > objectClass: olcModuleList > cn: module{0} > olcModulePath: /usr/local/openldap/sbin > olcModuleLoad: {0}syncprov.la > olcModuleLoad: {1}back_hdb.la > olcModuleLoad: {2}syncprov.la > > any chance this can cause problems? It's a bit redundant. Perhaps we should fail it instead. > about logging I vote for it > > > Ing. Luca Scamoni > Responsabile Ricerca e Sviluppo > > SysNet s.r.l. > via Dossi, 8 - 27100 Pavia - ITALIA > http://www.sys-net.it > ----------------------------------- > Office: +39 0382 573859 (137) > Mobile: +39 347 1014425 > Fax: +39 0382 476497 > Email: luca.scamoni(a)sys-net.it > ----------------------------------- > > -- -- 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#6030) slapd segfaults when loading already present module
by luca.scamoni＠sys-net.it 23 Mar '09

23 Mar '09

Howard Chu ha scritto: > HEAD has been changed to silently ignore these cases, please test. > > (I guess we could log something at LDAP_DEBUG_CONFIG level but that > seems unnecessary at the moment.) > thanks, now it doesn't segfaults anymore but something like: modulepath /usr/local/openldap/sbin moduleload syncprov.la moduleload back_hdb.la moduleload syncprov.la becomes: dn: cn=module{0},cn=config objectClass: olcModuleList cn: module{0} olcModulePath: /usr/local/openldap/sbin olcModuleLoad: {0}syncprov.la olcModuleLoad: {1}back_hdb.la olcModuleLoad: {2}syncprov.la any chance this can cause problems? about logging I vote for it Ing. Luca Scamoni Responsabile Ricerca e Sviluppo SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 0382 573859 (137) Mobile: +39 347 1014425 Fax: +39 0382 476497 Email: luca.scamoni(a)sys-net.it -----------------------------------

1 0

Re: (ITS#6030) slapd segfaults when loading already present module
by hyc＠symas.com 23 Mar '09

23 Mar '09

HEAD has been changed to silently ignore these cases, please test. (I guess we could log something at LDAP_DEBUG_CONFIG level but that seems unnecessary at the moment.) luca(a)OpenLDAP.org wrote: > Full_Name: Luca Scamoni > Version: RE24/HEAD > OS: any > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (82.63.140.131) > > > When loading a module through cn=config or slapd.conf moduleload directive, if > the module has already been loaded, slapd segfaults. Since it correctly finds > out the module is already registered shouldn't it refuse the modification when > the operation is attempted through cn=config or simply refuse to start when done > through slapd.conf? > > Last log lines (-d -1): > line 20 (moduleload syncprov.la) > loaded module syncprov.la > Control 1.3.6.1.4.1.4203.1.9.1.1 already registered. > syncprov_init: Failed to register control -9 > Segmentation fault > > backtrace: > #0 0x0000000b in ?? () > No symbol table info available. > #1 0x080dcb94 in module_load (file_name=0x89746bb "syncprov.la", argc=0, > argv=0x0) > at module.c:218 > module = (module_loaded_t *) 0x8976718 > error = 0x0 > rc = -9 > initialize = (MODULE_INIT_FN) 0x5f6936<init_module> > #2 0x0805bd1c in config_generic (c=0x8967970) at bconfig.c:1940 > i = 11784196 > __PRETTY_FUNCTION__ = "config_generic" > #3 0x0806a586 in config_set_vals (Conf=0x8168160, c=0x8967970) at config.c:314 > rc = 0 > arg_type = -2013265890 > ptr = (void *) 0x0 > #4 0x0806aa68 in config_add_vals (Conf=0x8168160, c=0x8967970) at config.c:383 > rc = 0 > arg_type = -2013265890 > #5 0x0806ba42 in read_config_file (fname=0x8932308 > "/usr/local/openldap/etc/slapd.conf", > depth=0, cf=0x0, cft=0x8167bc0) at config.c:736 > fp = (FILE *) 0x89692f8 > ct = (ConfigTable *) 0x8168160 > c = (ConfigArgs *) 0x8967970 > rc = 0 > s = {st_dev = 64768, __pad1 = 0, st_ino = 172196293, st_mode = 33152, > st_nlink = 1, > st_uid = 0, st_gid = 0, st_rdev = 0, __pad2 = 0, st_size = 1087, st_blksize = > 4096, > st_blocks = 8, st_atim = {tv_sec = 1237802811, tv_nsec = 0}, st_mtim = {tv_sec > = 1237802556, > tv_nsec = 0}, st_ctim = {tv_sec = 1237802556, tv_nsec = 0}, __unused4 = 0, > __unused5 = 0} > #6 0x08061626 in read_config (fname=0x8932308 > "/usr/local/openldap/etc/slapd.conf", dir=0x0) > at bconfig.c:3613 > be = (BackendDB *) 0x8967800 > cfb = (CfBackInfo *) 0x816c340 > cfdir = 0x11f0bc "" > cfname = 0x8932308 "/usr/local/openldap/etc/slapd.conf" > rc = 0 > __PRETTY_FUNCTION__ = "read_config" > #7 0x08057a5d in main (argc=5, argv=0xbfc1ce24) at main.c:754 > i = -1 > no_detach = 0 > rc = 0 > urls = 0x89323f0 "ldap://:9000" > username = 0x0 > groupname = 0x0 > sandbox = 0x0 > syslogUser = 160 > g_argc = 5 > g_argv = (char **) 0xbfc1ce24 > configfile = 0x8932308 "/usr/local/openldap/etc/slapd.conf" > configdir = 0x0 > serverName = 0xbfc1eb66 "slapd" > serverMode = 1 > scp = (struct sync_cookie *) 0x0 > scp_entry = (struct sync_cookie *) 0x0 > debug_unknowns = (char **) 0x0 > syslog_unknowns = (char **) 0x0 > serverNamePrefix = 0x811b537 "" > l = 1347407256 > slapd_pid_file_unlink = 0 > slapd_args_file_unlink = 0 > firstopt = 0 > __PRETTY_FUNCTION__ = "main" > > > -- -- 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#6030) slapd segfaults when loading already present module
by luca＠OpenLDAP.org 23 Mar '09

23 Mar '09

Full_Name: Luca Scamoni Version: RE24/HEAD OS: any URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.63.140.131) When loading a module through cn=config or slapd.conf moduleload directive, if the module has already been loaded, slapd segfaults. Since it correctly finds out the module is already registered shouldn't it refuse the modification when the operation is attempted through cn=config or simply refuse to start when done through slapd.conf? Last log lines (-d -1): line 20 (moduleload syncprov.la) loaded module syncprov.la Control 1.3.6.1.4.1.4203.1.9.1.1 already registered. syncprov_init: Failed to register control -9 Segmentation fault backtrace: #0 0x0000000b in ?? () No symbol table info available. #1 0x080dcb94 in module_load (file_name=0x89746bb "syncprov.la", argc=0, argv=0x0) at module.c:218 module = (module_loaded_t *) 0x8976718 error = 0x0 rc = -9 initialize = (MODULE_INIT_FN) 0x5f6936 <init_module> #2 0x0805bd1c in config_generic (c=0x8967970) at bconfig.c:1940 i = 11784196 __PRETTY_FUNCTION__ = "config_generic" #3 0x0806a586 in config_set_vals (Conf=0x8168160, c=0x8967970) at config.c:314 rc = 0 arg_type = -2013265890 ptr = (void *) 0x0 #4 0x0806aa68 in config_add_vals (Conf=0x8168160, c=0x8967970) at config.c:383 rc = 0 arg_type = -2013265890 #5 0x0806ba42 in read_config_file (fname=0x8932308 "/usr/local/openldap/etc/slapd.conf", depth=0, cf=0x0, cft=0x8167bc0) at config.c:736 fp = (FILE *) 0x89692f8 ct = (ConfigTable *) 0x8168160 c = (ConfigArgs *) 0x8967970 rc = 0 s = {st_dev = 64768, __pad1 = 0, st_ino = 172196293, st_mode = 33152, st_nlink = 1, st_uid = 0, st_gid = 0, st_rdev = 0, __pad2 = 0, st_size = 1087, st_blksize = 4096, st_blocks = 8, st_atim = {tv_sec = 1237802811, tv_nsec = 0}, st_mtim = {tv_sec = 1237802556, tv_nsec = 0}, st_ctim = {tv_sec = 1237802556, tv_nsec = 0}, __unused4 = 0, __unused5 = 0} #6 0x08061626 in read_config (fname=0x8932308 "/usr/local/openldap/etc/slapd.conf", dir=0x0) at bconfig.c:3613 be = (BackendDB *) 0x8967800 cfb = (CfBackInfo *) 0x816c340 cfdir = 0x11f0bc "" cfname = 0x8932308 "/usr/local/openldap/etc/slapd.conf" rc = 0 __PRETTY_FUNCTION__ = "read_config" #7 0x08057a5d in main (argc=5, argv=0xbfc1ce24) at main.c:754 i = -1 no_detach = 0 rc = 0 urls = 0x89323f0 "ldap://:9000" username = 0x0 groupname = 0x0 sandbox = 0x0 syslogUser = 160 g_argc = 5 g_argv = (char **) 0xbfc1ce24 configfile = 0x8932308 "/usr/local/openldap/etc/slapd.conf" configdir = 0x0 serverName = 0xbfc1eb66 "slapd" serverMode = 1 scp = (struct sync_cookie *) 0x0 scp_entry = (struct sync_cookie *) 0x0 debug_unknowns = (char **) 0x0 syslog_unknowns = (char **) 0x0 serverNamePrefix = 0x811b537 "" l = 1347407256 slapd_pid_file_unlink = 0 slapd_args_file_unlink = 0 firstopt = 0 __PRETTY_FUNCTION__ = "main"

1 0

Re: (ITS#6027) Debug() accesses free()-d memory in register_at() on error
by test.007＠seznam.cz 23 Mar '09

23 Mar '09

Verified. Thanks. Mr. Chu, you're right my build was broken.

1 0

Re: patch filed (ITS#5366)
by peter＠adpm.de 22 Mar '09

22 Mar '09

Hi, I filed a patch that should fix this ITS. It can be found at ftp://ftp.openldap.org/incoming/PeterMarschall-090322.patch and brings the man page in line with the code. Regards Peter -- Peter Marschall peter(a)adpm.de

1 0

Re: (ITS#6029) slapadd lockup
by quanah＠zimbra.com 21 Mar '09

21 Mar '09

After around 24 hours, backtrace is the same: (gdb) thr apply all bt Thread 5 (Thread 1106889024 (LWP 9361)): #0 0x00002b7817902496 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b7819f27de9 in bdb_tool_trickle_task (ctx=<value optimized out>, ptr=<value optimized out>) at tools.c:1124 #2 0x00002b781715a2ca in ldap_int_thread_pool_wrapper (xpool=0x17e07fd0) at ../../../libraries/libldap_r/tpool.c:663 #3 0x00002b78178fe2f7 in start_thread () from /lib64/libpthread.so.0 #4 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 Thread 4 (Thread 1115281728 (LWP 9362)): #0 0x00002b7817902496 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b7819f28163 in bdb_tool_index_task (ctx=<value optimized out>, ptr=<value optimized out>) at tools.c:1147 #2 0x00002b781715a2ca in ldap_int_thread_pool_wrapper (xpool=0x17e07fd0) at ../../../libraries/libldap_r/tpool.c:663 #3 0x00002b78178fe2f7 in start_thread () from /lib64/libpthread.so.0 #4 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 Thread 3 (Thread 1123674432 (LWP 9363)): #0 0x00002b7817902496 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b7819f28163 in bdb_tool_index_task (ctx=<value optimized out>, ptr=<value optimized out>) at tools.c:1147 #2 0x00002b781715a2ca in ldap_int_thread_pool_wrapper (xpool=0x17e07fd0) at ../../../libraries/libldap_r/tpool.c:663 #3 0x00002b78178fe2f7 in start_thread () from /lib64/libpthread.so.0 #4 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 Thread 2 (Thread 1132067136 (LWP 9360)): #0 0x00002b7817902496 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b7819f28014 in bdb_tool_index_add (op=0x7fff93950310, txn=<value optimized out>, e=0x2b7b521d2068) at tools.c:475 #2 0x00002b7819f28970 in hdb_tool_entry_put (be=0x17f39240, e=0x2b7b521d2068, text=0x7fff93960cc0) at tools.c:545 #3 0x00000000004906f9 in slapadd (argc=<value optimized out>, argv=0x7fff93960ec8) at ../../../servers/slapd/slapadd.c:350 #4 0x0000000000416c59 in main (argc=6, argv=0x7fff93960ec8) at ../../../servers/slapd/main.c:391 Thread 1 (Thread 47794824997056 (LWP 9360)): #0 0x00002b7817902496 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b7819f28014 in bdb_tool_index_add (op=0x7fff93950310, txn=<value optimized out>, e=0x2b7b521d2068) at tools.c:475 #2 0x00002b7819f28970 in hdb_tool_entry_put (be=0x17f39240, e=0x2b7b521d2068, text=0x7fff93960cc0) at tools.c:545 #3 0x00000000004906f9 in slapadd (argc=<value optimized out>, argv=0x7fff93960ec8) at ../../../servers/slapd/slapadd.c:350 #4 0x0000000000416c59 in main (argc=6, argv=0x7fff93960ec8) at ../../../servers/slapd/main.c:391 #0 0x00002b7817902496 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 --On Sunday, March 22, 2009 2:37 AM +0000 quanah(a)zimbra.com wrote: > --On Saturday, March 21, 2009 7:09 PM -0700 Howard Chu <hyc(a)symas.com> > wrote: > >> quanah(a)zimbra.com wrote: >>> Full_Name: Quanah Gibson-Mount >>> Version: RE24 3/19/2009 >>> OS: Linux 2.6 >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (75.111.29.239) >>> >>> >>> While testing various load scenarios, slapadd deadlocked on me. >> >> The trace for thread 1 and 2 look identical, so I'm assuming they're the >> same thread. In that case I see 3 tool threads running. How many did you >> have configured? If 1 and 2 are really different threads (certainly their >> thread IDs look quite different), then there's something very wrong in >> the thread library... >> >> print bdb_tool_index_tcount >> > > (gdb) print bdb_tool_index_tcount > $1 = 1 > > >> It looks like one thread has exited early. I'm not sure how that can >> happen since the only way for any index thread to exit is if >> slapd_shutdown is set. Is it set? > > (gdb) print slapd_shutdown > $2 = 0 > > > It's configured with 4 tool threads. > > --Quanah > >>> (gdb) thr apply all bt >>> >>> Thread 5 (Thread 1106889024 (LWP 9361)): >>> # 0 0x00002b7817902496 in pthread_cond_wait@@GLIBC_2.3.2 () from >>> /lib64/libpthread.so.0 >>> # 1 0x00002b7819f27de9 in bdb_tool_trickle_task (ctx=<value optimized >>> # out>, >>> ptr=<value optimized out>) at tools.c:1124 >>> # 2 0x00002b781715a2ca in ldap_int_thread_pool_wrapper >>> # (xpool=0x17e07fd0) at >>> ../../../libraries/libldap_r/tpool.c:663 >>> # 3 0x00002b78178fe2f7 in start_thread () from /lib64/libpthread.so.0 >>> # 4 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 >>> >>> Thread 4 (Thread 1115281728 (LWP 9362)): >>> # 0 0x00002b7817902496 in pthread_cond_wait@@GLIBC_2.3.2 () from >>> /lib64/libpthread.so.0 >>> # 1 0x00002b7819f28163 in bdb_tool_index_task (ctx=<value optimized >>> # out>, >>> ptr=<value optimized out>) at tools.c:1147 >>> # 2 0x00002b781715a2ca in ldap_int_thread_pool_wrapper >>> # (xpool=0x17e07fd0) at >>> ../../../libraries/libldap_r/tpool.c:663 >>> # 3 0x00002b78178fe2f7 in start_thread () from /lib64/libpthread.so.0 >>> # 4 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 >>> >>> Thread 3 (Thread 1123674432 (LWP 9363)): >>> # 0 0x00002b7817902496 in pthread_cond_wait@@GLIBC_2.3.2 () from >>> /lib64/libpthread.so.0 >>> # 1 0x00002b7819f28163 in bdb_tool_index_task (ctx=<value optimized >>> # out>, >>> ptr=<value optimized out>) at tools.c:1147 >>> # 2 0x00002b781715a2ca in ldap_int_thread_pool_wrapper >>> # (xpool=0x17e07fd0) at >>> ../../../libraries/libldap_r/tpool.c:663 >>> # 3 0x00002b78178fe2f7 in start_thread () from /lib64/libpthread.so.0 >>> # 4 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 >>> >>> Thread 2 (Thread 1132067136 (LWP 9360)): >>> # 0 0x00002b7817902496 in pthread_cond_wait@@GLIBC_2.3.2 () from >>> /lib64/libpthread.so.0 >>> # 1 0x00002b7819f28014 in bdb_tool_index_add (op=0x7fff93950310, >>> # txn=<value >>> optimized out>, e=0x2b7b521d2068) at tools.c:475 >>> # 2 0x00002b7819f28970 in hdb_tool_entry_put (be=0x17f39240, >>> # e=0x2b7b521d2068, >>> text=0x7fff93960cc0) at tools.c:545 >>> # 3 0x00000000004906f9 in slapadd (argc=<value optimized out>, >>> argv=0x7fff93960ec8) at ../../../servers/slapd/slapadd.c:350 >>> # 4 0x0000000000416c59 in main (argc=6, argv=0x7fff93960ec8) at >>> ../../../servers/slapd/main.c:391 >>> >>> Thread 1 (Thread 47794824997056 (LWP 9360)): >>> # 0 0x00002b7817902496 in pthread_cond_wait@@GLIBC_2.3.2 () from >>> /lib64/libpthread.so.0 >>> # 1 0x00002b7819f28014 in bdb_tool_index_add (op=0x7fff93950310, >>> # txn=<value >>> optimized out>, e=0x2b7b521d2068) at tools.c:475 >>> # 2 0x00002b7819f28970 in hdb_tool_entry_put (be=0x17f39240, >>> # e=0x2b7b521d2068, >>> text=0x7fff93960cc0) at tools.c:545 >>> # 3 0x00000000004906f9 in slapadd (argc=<value optimized out>, >>> argv=0x7fff93960ec8) at ../../../servers/slapd/slapadd.c:350 >>> # 4 0x0000000000416c59 in main (argc=6, argv=0x7fff93960ec8) at >>> ../../../servers/slapd/main.c:391 >>> # 0 0x00002b7817902496 in pthread_cond_wait@@GLIBC_2.3.2 () from >>> /lib64/libpthread.so.0 >> >> >> -- >> -- Howard Chu >> CTO, Symas Corp. http://www.symas.com >> Director, Highland Sun http://highlandsun.com/hyc/ >> Chief Architect, OpenLDAP http://www.openldap.org/project/ > > > > -- > > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration > > -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6029) slapadd lockup
by quanah＠zimbra.com 21 Mar '09

21 Mar '09

--On Saturday, March 21, 2009 7:09 PM -0700 Howard Chu <hyc(a)symas.com> wrote: > quanah(a)zimbra.com wrote: >> Full_Name: Quanah Gibson-Mount >> Version: RE24 3/19/2009 >> OS: Linux 2.6 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (75.111.29.239) >> >> >> While testing various load scenarios, slapadd deadlocked on me. > > The trace for thread 1 and 2 look identical, so I'm assuming they're the > same thread. In that case I see 3 tool threads running. How many did you > have configured? If 1 and 2 are really different threads (certainly their > thread IDs look quite different), then there's something very wrong in > the thread library... > > print bdb_tool_index_tcount > (gdb) print bdb_tool_index_tcount $1 = 1 > It looks like one thread has exited early. I'm not sure how that can > happen since the only way for any index thread to exit is if > slapd_shutdown is set. Is it set? (gdb) print slapd_shutdown $2 = 0 It's configured with 4 tool threads. --Quanah >> (gdb) thr apply all bt >> >> Thread 5 (Thread 1106889024 (LWP 9361)): >> # 0 0x00002b7817902496 in pthread_cond_wait@@GLIBC_2.3.2 () from >> /lib64/libpthread.so.0 >> # 1 0x00002b7819f27de9 in bdb_tool_trickle_task (ctx=<value optimized >> # out>, >> ptr=<value optimized out>) at tools.c:1124 >> # 2 0x00002b781715a2ca in ldap_int_thread_pool_wrapper >> # (xpool=0x17e07fd0) at >> ../../../libraries/libldap_r/tpool.c:663 >> # 3 0x00002b78178fe2f7 in start_thread () from /lib64/libpthread.so.0 >> # 4 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 >> >> Thread 4 (Thread 1115281728 (LWP 9362)): >> # 0 0x00002b7817902496 in pthread_cond_wait@@GLIBC_2.3.2 () from >> /lib64/libpthread.so.0 >> # 1 0x00002b7819f28163 in bdb_tool_index_task (ctx=<value optimized >> # out>, >> ptr=<value optimized out>) at tools.c:1147 >> # 2 0x00002b781715a2ca in ldap_int_thread_pool_wrapper >> # (xpool=0x17e07fd0) at >> ../../../libraries/libldap_r/tpool.c:663 >> # 3 0x00002b78178fe2f7 in start_thread () from /lib64/libpthread.so.0 >> # 4 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 >> >> Thread 3 (Thread 1123674432 (LWP 9363)): >> # 0 0x00002b7817902496 in pthread_cond_wait@@GLIBC_2.3.2 () from >> /lib64/libpthread.so.0 >> # 1 0x00002b7819f28163 in bdb_tool_index_task (ctx=<value optimized >> # out>, >> ptr=<value optimized out>) at tools.c:1147 >> # 2 0x00002b781715a2ca in ldap_int_thread_pool_wrapper >> # (xpool=0x17e07fd0) at >> ../../../libraries/libldap_r/tpool.c:663 >> # 3 0x00002b78178fe2f7 in start_thread () from /lib64/libpthread.so.0 >> # 4 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 >> >> Thread 2 (Thread 1132067136 (LWP 9360)): >> # 0 0x00002b7817902496 in pthread_cond_wait@@GLIBC_2.3.2 () from >> /lib64/libpthread.so.0 >> # 1 0x00002b7819f28014 in bdb_tool_index_add (op=0x7fff93950310, >> # txn=<value >> optimized out>, e=0x2b7b521d2068) at tools.c:475 >> # 2 0x00002b7819f28970 in hdb_tool_entry_put (be=0x17f39240, >> # e=0x2b7b521d2068, >> text=0x7fff93960cc0) at tools.c:545 >> # 3 0x00000000004906f9 in slapadd (argc=<value optimized out>, >> argv=0x7fff93960ec8) at ../../../servers/slapd/slapadd.c:350 >> # 4 0x0000000000416c59 in main (argc=6, argv=0x7fff93960ec8) at >> ../../../servers/slapd/main.c:391 >> >> Thread 1 (Thread 47794824997056 (LWP 9360)): >> # 0 0x00002b7817902496 in pthread_cond_wait@@GLIBC_2.3.2 () from >> /lib64/libpthread.so.0 >> # 1 0x00002b7819f28014 in bdb_tool_index_add (op=0x7fff93950310, >> # txn=<value >> optimized out>, e=0x2b7b521d2068) at tools.c:475 >> # 2 0x00002b7819f28970 in hdb_tool_entry_put (be=0x17f39240, >> # e=0x2b7b521d2068, >> text=0x7fff93960cc0) at tools.c:545 >> # 3 0x00000000004906f9 in slapadd (argc=<value optimized out>, >> argv=0x7fff93960ec8) at ../../../servers/slapd/slapadd.c:350 >> # 4 0x0000000000416c59 in main (argc=6, argv=0x7fff93960ec8) at >> ../../../servers/slapd/main.c:391 >> # 0 0x00002b7817902496 in pthread_cond_wait@@GLIBC_2.3.2 () from >> /lib64/libpthread.so.0 > > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6029) slapadd lockup
by hyc＠symas.com 21 Mar '09

21 Mar '09

quanah(a)zimbra.com wrote: > Full_Name: Quanah Gibson-Mount > Version: RE24 3/19/2009 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.29.239) > > > While testing various load scenarios, slapadd deadlocked on me. The trace for thread 1 and 2 look identical, so I'm assuming they're the same thread. In that case I see 3 tool threads running. How many did you have configured? If 1 and 2 are really different threads (certainly their thread IDs look quite different), then there's something very wrong in the thread library... print bdb_tool_index_tcount It looks like one thread has exited early. I'm not sure how that can happen since the only way for any index thread to exit is if slapd_shutdown is set. Is it set? > > (gdb) thr apply all bt > > Thread 5 (Thread 1106889024 (LWP 9361)): > #0 0x00002b7817902496 in pthread_cond_wait@@GLIBC_2.3.2 () from > /lib64/libpthread.so.0 > #1 0x00002b7819f27de9 in bdb_tool_trickle_task (ctx=<value optimized out>, > ptr=<value optimized out>) at tools.c:1124 > #2 0x00002b781715a2ca in ldap_int_thread_pool_wrapper (xpool=0x17e07fd0) at > ../../../libraries/libldap_r/tpool.c:663 > #3 0x00002b78178fe2f7 in start_thread () from /lib64/libpthread.so.0 > #4 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 > > Thread 4 (Thread 1115281728 (LWP 9362)): > #0 0x00002b7817902496 in pthread_cond_wait@@GLIBC_2.3.2 () from > /lib64/libpthread.so.0 > #1 0x00002b7819f28163 in bdb_tool_index_task (ctx=<value optimized out>, > ptr=<value optimized out>) at tools.c:1147 > #2 0x00002b781715a2ca in ldap_int_thread_pool_wrapper (xpool=0x17e07fd0) at > ../../../libraries/libldap_r/tpool.c:663 > #3 0x00002b78178fe2f7 in start_thread () from /lib64/libpthread.so.0 > #4 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 > > Thread 3 (Thread 1123674432 (LWP 9363)): > #0 0x00002b7817902496 in pthread_cond_wait@@GLIBC_2.3.2 () from > /lib64/libpthread.so.0 > #1 0x00002b7819f28163 in bdb_tool_index_task (ctx=<value optimized out>, > ptr=<value optimized out>) at tools.c:1147 > #2 0x00002b781715a2ca in ldap_int_thread_pool_wrapper (xpool=0x17e07fd0) at > ../../../libraries/libldap_r/tpool.c:663 > #3 0x00002b78178fe2f7 in start_thread () from /lib64/libpthread.so.0 > #4 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 > > Thread 2 (Thread 1132067136 (LWP 9360)): > #0 0x00002b7817902496 in pthread_cond_wait@@GLIBC_2.3.2 () from > /lib64/libpthread.so.0 > #1 0x00002b7819f28014 in bdb_tool_index_add (op=0x7fff93950310, txn=<value > optimized out>, e=0x2b7b521d2068) at tools.c:475 > #2 0x00002b7819f28970 in hdb_tool_entry_put (be=0x17f39240, e=0x2b7b521d2068, > text=0x7fff93960cc0) at tools.c:545 > #3 0x00000000004906f9 in slapadd (argc=<value optimized out>, > argv=0x7fff93960ec8) at ../../../servers/slapd/slapadd.c:350 > #4 0x0000000000416c59 in main (argc=6, argv=0x7fff93960ec8) at > ../../../servers/slapd/main.c:391 > > Thread 1 (Thread 47794824997056 (LWP 9360)): > #0 0x00002b7817902496 in pthread_cond_wait@@GLIBC_2.3.2 () from > /lib64/libpthread.so.0 > #1 0x00002b7819f28014 in bdb_tool_index_add (op=0x7fff93950310, txn=<value > optimized out>, e=0x2b7b521d2068) at tools.c:475 > #2 0x00002b7819f28970 in hdb_tool_entry_put (be=0x17f39240, e=0x2b7b521d2068, > text=0x7fff93960cc0) at tools.c:545 > #3 0x00000000004906f9 in slapadd (argc=<value optimized out>, > argv=0x7fff93960ec8) at ../../../servers/slapd/slapadd.c:350 > #4 0x0000000000416c59 in main (argc=6, argv=0x7fff93960ec8) at > ../../../servers/slapd/main.c:391 > #0 0x00002b7817902496 in pthread_cond_wait@@GLIBC_2.3.2 () from > /lib64/libpthread.so.0 -- -- 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs