- openldap-bugs - openldap.org

Re: (ITS#6040) SEGV - hdb_cache_lru_purge / bdb_cache_delete_internal / ldap_pvt_thread_mutex_lock
by quanah＠zimbra.com 28 Apr '09

28 Apr '09

--On Friday, March 27, 2009 9:52 AM +0000 oskar(a)deckle.co.za wrote: A different backtrace from another user of 2.4.16: GNU gdb Red Hat Linux (6.5-25.el5rh) Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu". (gdb) handle SIG33 pass nostop noprint Signal Stop Print Pass to program Description SIG33 No No Yes Real-time event 33 (gdb) set pagination 0 (gdb) attach 4154 Attaching to process 4154 Reading symbols from /opt/openldap2/libexec/slapd...done. Using host libthread_db library "/lib64/libthread_db.so.1". Reading symbols from /usr/lib64/libltdl.so.3...done. Loaded symbols for /usr/lib64/libltdl.so.3 Reading symbols from /opt/db4/lib/libdb-4.7.so...done. Loaded symbols for /opt/db4/lib/libdb-4.7.so Reading symbols from /lib64/libpthread.so.0...done. [Thread debugging using libthread_db enabled] [New Thread 46912501776800 (LWP 4154)] [New Thread 1090525504 (LWP 4175)] [New Thread 1082132800 (LWP 4174)] Loaded symbols for /lib64/libpthread.so.0 Reading symbols from /lib64/libresolv.so.2...done. Loaded symbols for /lib64/libresolv.so.2 Reading symbols from /lib64/libc.so.6...done. Loaded symbols for /lib64/libc.so.6 Reading symbols from /lib64/libdl.so.2...done. Loaded symbols for /lib64/libdl.so.2 Reading symbols from /lib64/ld-linux-x86-64.so.2...done. Loaded symbols for /lib64/ld-linux-x86-64.so.2 0x0000003c024075a5 in pthread_join () from /lib64/libpthread.so.0 (gdb) continue Continuing. [New Thread 1098918208 (LWP 4203)] [New Thread 1107310912 (LWP 4204)] [New Thread 1115703616 (LWP 4205)] [New Thread 1124096320 (LWP 4206)] [New Thread 1132489024 (LWP 4207)] [New Thread 1140881728 (LWP 4208)] [New Thread 1149274432 (LWP 4209)] [New Thread 1157667136 (LWP 4210)] [New Thread 1166059840 (LWP 4211)] [New Thread 1174452544 (LWP 4298)] [New Thread 1182845248 (LWP 4299)] [New Thread 1191237952 (LWP 4300)] [New Thread 1199630656 (LWP 4301)] [New Thread 1208023360 (LWP 4302)] [New Thread 1216416064 (LWP 4303)] [New Thread 1224808768 (LWP 4304)] [New Thread 1233201472 (LWP 4305)] [New Thread 1241594176 (LWP 4306)] [New Thread 1249986880 (LWP 4307)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1090525504 (LWP 4175)] 0x0000003c024082e9 in pthread_mutex_lock () from /lib64/libpthread.so.0 (gdb) backtrace full #0 0x0000003c024082e9 in pthread_mutex_lock () from /lib64/libpthread.so.0 No symbol table info available. #1 0x00000000005c2b01 in ldap_pvt_thread_mutex_lock (mutex=0x58) at thr_posix.c:296 No locals. #2 0x0000000000523d44 in bdb_cache_delete_internal (cache=0x12efd330, e=0x2aac4fb3c8d0, decr=0) at cache.c:1372 rc = 0 decr_leaf = 0 #3 0x0000000000522a32 in hdb_cache_lru_purge (bdb=0x12efd2d0) at cache.c:776 lock = {off = 0, ndx = 324, gen = 1689, mode = DB_LOCK_WRITE} lockp = (DB_LOCK *) 0x40e7f780 elru = (EntryInfo *) 0x2aac4fb3c8d0 elnext = (EntryInfo *) 0x2aac4f1fe610 count = 1 islocked = 1 eimax = 100000 efree = 10011 eifree = 50000 eicount = 0 ecount = 1 iter = 0 #4 0x0000000000523323 in hdb_cache_find_id (op=0x12ee1630, tid=0x12ee3510, id=243315, eip=0x40e7fa40, flag=0, lock=0x40e7fa10) at cache.c:1053 purge = 1 bdb = (struct bdb_info *) 0x12efd2d0 ep = (Entry *) 0x0 rc = 0 load = 1 ei = {bei_parent = 0x0, bei_id = 243315, bei_lockpad = 0, bei_state = 0, bei_finders = 0, bei_nrdn = {bv_len = 0, bv_val = 0x0}, bei_rdn = {bv_len = 0, bv_val = 0x0}, bei_modrdns = 0, bei_ckids = 0, bei_dkids = 0, bei_e = 0x0, bei_kids = 0x0, bei_kids_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\0' <repeats 39 times>, __align = 0}, bei_lrunext = 0x0, bei_lruprev = 0x0} #5 0x00000000004e5105 in hdb_search (op=0x12ee1630, rs=0x41000c80) at search.c:705 scopeok = 0 bdb = (struct bdb_info *) 0x12efd2d0 id = 243315 cursor = 1 lastid = 18446744073709551615 candidates = {1, 243315, 5000071, 0 <repeats 130531 times>, 24, 1090513600, 1090513392, 0, 0, 0, 2050, 0 <repeats 21 times>, 1090513632, 6244688, 0, 90194313217, 0, 8804682956800, 1090517792, 6242840, 4294967296, 317906296, 17179869184, 317600016, 0 <repeats 19 times>, 4795068, 0, 0, 316910368, 1090517216, 0, 1090517216, 316910368, 0, 1090513968, 6006094, 316910368, 4794969, 1090517216, 316910400, 0, 0, 1090514032, 4795242, 0, 316910048, 316910048, 1090517216, 1090525504, 316910368, 1090517376, 4783514, 1090525504, 1090517392, 317448576, 1090522272, 327778448, 1090517472, 317448576, 4794969, 1090517392, 317448608, 0, 56, 1090514208, 4795242, 1090514208, 317448144, 317448144, 1090517392, 1090525504, 317448576, 1090517552, 4783514, 0, 0, 0, 1090517640, 1090517664, 327777992, 0 <repeats 15 times>, 4795068, 0, 0, 316910368, 1090517776, 0, 1090517776, 316910368, 0, 1090514528, 6006094, 316910368, 4794969, 1090517776, 316910400, 0, 0, 1090514592, 4795242, 0, 316910048, 316910048, 1090517776, 1090525504, 316910368, 1090517936, 4783514, 0, 0, 0, 1090522096, 327778736, 327778720, 0 <repeats 22 times>, 1, 1090516592, 6284189, 6284190, 16, 257723479467, 0, 0, 1090516528, 0, 1090515280, 0, 0, 0, 1090516960, 6284180, 1090516608, 0, 0, 0, 0, 18446744073709551615, 94489280512, 6284181, 0, 1090516280, 12884901888, 11, 0, 0, 0, 0, 0, 0, 32, 0, 0, 1929379840, 0, 0...} scopes = {0 <repeats 65536 times>} e = (Entry *) 0x0 base = {e_id = 74, e_name = {bv_len = 0, bv_val = 0x0}, e_nname = {bv_len = 25, bv_val = 0x2aacaf1795a0 "ou=o1,ou=people,o=oxylane"}, e_attrs = 0x0, e_ocflags = 0, e_bv = {bv_len = 0, bv_val = 0x0}, e_private = 0x12ee3ed0} e_root = (Entry *) 0x130f6b38 matched = (Entry *) 0x0 ei = (EntryInfo *) 0x2aac4d6fe6d0 attrs = (AttributeName *) 0x138981a0 realbase = {bv_len = 25, bv_val = 0x2aacaf1795a0 "ou=o1,ou=people,o=oxylane"} mask = 5119 stoptime = 1240904022 manageDSAit = 0 tentries = 1 nentries = 1 idflag = 0 lock = {off = 203872, ndx = 95, gen = 2711, mode = DB_LOCK_READ} opinfo = (struct bdb_op_info *) 0x0 ltid = (DB_TXN *) 0x12ee3510 oex = (OpExtra *) 0x0 #6 0x000000000043ecfa in fe_op_search (op=0x12ee1630, rs=0x41000c80) at search.c:366 bd = (BackendDB *) 0x89cce0 #7 0x000000000043e634 in do_search (op=0x12ee1630, rs=0x41000c80) at search.c:217 base = {bv_len = 25, bv_val = 0x2aacaf178668 "ou=o1,ou=people,o=oxylane"} siz = 1 off = 0 i = 1 #8 0x000000000043b78a in connection_operation (ctx=0x41000dd0, arg_v=0x12ee1630) at connection.c:1097 rc = 80 op = (Operation *) 0x12ee1630 rs = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = {sru_sasl = {r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}, sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}}, sr_flags = 0} tag = 99 opidx = SLAP_OP_SEARCH conn = (Connection *) 0x12f2c7b8 memctx = (void *) 0x12ee1b60 memctx_null = (void *) 0x0 memsiz = 1048576 __PRETTY_FUNCTION__ = "connection_operation" #9 0x000000000043bca5 in connection_read_thread (ctx=0x41000dd0, argv=0xd) at connection.c:1223 rc = 0 cri = {op = 0x12ee1630, func = 0, arg = 0x0, ctx = 0x41000dd0, nullop = 0} s = 13 #10 0x00000000005c15dc in ldap_int_thread_pool_wrapper (xpool=0x12e3da20) at tpool.c:663 pool = (struct ldap_int_thread_pool_s *) 0x12e3da20 task = (ldap_int_thread_task_t *) 0x2aaca82a46f0 work_list = (ldap_int_tpool_plist_t *) 0x12e3dab8 ctx = {ltu_id = 1090525504, ltu_key = {{ltk_key = 0x43b311, ltk_data = 0x12ee1a50, ltk_free = 0x43b174 <conn_counter_destroy>}, {ltk_key = 0x4a653a, ltk_data = 0x12ee1b60, ltk_free = 0x4a6334 <slap_sl_mem_destroy>}, {ltk_key = 0x4553b8, ltk_data = 0x0, ltk_free = 0x455314 <slap_op_q_destroy>}, {ltk_key = 0x130d9a60, ltk_data = 0x12ee3510, ltk_free = 0x524225 <bdb_reader_free>}, {ltk_key = 0x4e62a6, ltk_data = 0x13a97d60, ltk_free = 0x4e6286 <search_stack_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 27 times>}} kctx = (ldap_int_thread_userctx_t *) 0x0 i = 32 keyslot = 986 hash = 2575130586 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #11 0x0000003c024062e7 in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #12 0x0000003c018ce3bd in clone () from /lib64/libc.so.6 No symbol table info available. (gdb) info registers rax 0x0 0 rbx 0x58 88 rcx 0x28 40 rdx 0x0 0 rsi 0x2aac4fb3c8d0 46919559923920 rdi 0x58 88 rbp 0x104f 0x104f rsp 0x40e7f6d0 0x40e7f6d0 r8 0x2aac37ebc138 46919160938808 r9 0x1 1 r10 0x0 0 r11 0x1 1 r12 0x0 0 r13 0x41001940 1090525504 r14 0x41002000 1090527232 r15 0x1000 4096 rip 0x3c024082e9 0x3c024082e9 <pthread_mutex_lock+25> eflags 0x10202 [ IF RF ] cs 0x33 51 ss 0x2b 43 ds 0x0 0 es 0x0 0 fs 0x63 99 gs 0x0 0 (gdb) thread apply all backtrace Thread 22 (Thread 1249986880 (LWP 4307)): #0 0x0000003c0240a496 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00000000005c2ab7 in ldap_pvt_thread_cond_wait (cond=0x12e3da50, mutex=0x12e3da28) at thr_posix.c:277 #2 0x00000000005c155d in ldap_int_thread_pool_wrapper (xpool=0x12e3da20) at tpool.c:654 #3 0x0000003c024062e7 in start_thread () from /lib64/libpthread.so.0 #4 0x0000003c018ce3bd in clone () from /lib64/libc.so.6 Thread 21 (Thread 1241594176 (LWP 4306)): #0 0x0000003c0240a496 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00000000005c2ab7 in ldap_pvt_thread_cond_wait (cond=0x12e3da50, mutex=0x12e3da28) at thr_posix.c:277 #2 0x00000000005c155d in ldap_int_thread_pool_wrapper (xpool=0x12e3da20) at tpool.c:654 #3 0x0000003c024062e7 in start_thread () from /lib64/libpthread.so.0 #4 0x0000003c018ce3bd in clone () from /lib64/libc.so.6 Thread 20 (Thread 1233201472 (LWP 4305)): #0 0x0000003c0240a496 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00000000005c2ab7 in ldap_pvt_thread_cond_wait (cond=0x12e3da50, mutex=0x12e3da28) at thr_posix.c:277 #2 0x00000000005c155d in ldap_int_thread_pool_wrapper (xpool=0x12e3da20) at tpool.c:654 #3 0x0000003c024062e7 in start_thread () from /lib64/libpthread.so.0 #4 0x0000003c018ce3bd in clone () from /lib64/libc.so.6 Thread 19 (Thread 1224808768 (LWP 4304)): #0 0x0000003c0240a496 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00000000005c2ab7 in ldap_pvt_thread_cond_wait (cond=0x12e3da50, mutex=0x12e3da28) at thr_posix.c:277 #2 0x00000000005c155d in ldap_int_thread_pool_wrapper (xpool=0x12e3da20) at tpool.c:654 #3 0x0000003c024062e7 in start_thread () from /lib64/libpthread.so.0 #4 0x0000003c018ce3bd in clone () from /lib64/libc.so.6 Thread 18 (Thread 1216416064 (LWP 4303)): #0 0x0000003c018da178 in __lll_mutex_lock_wait () from /lib64/libc.so.6 #1 0x0000003c01873c07 in _L_lock_14089 () from /lib64/libc.so.6 #2 0x0000003c01872a61 in free () from /lib64/libc.so.6 #3 0x00000000005f29fb in ber_memfree_x (p=0x20e77cf0, ctx=0x0) at memory.c:152 #4 0x00000000005f0dc2 in ber_free (ber=0x20e77cf0, freebuf=1) at io.c:214 #5 0x0000000000455416 in slap_op_free (op=0x172c4ac0, ctx=0x4880fdd0) at operation.c:83 #6 0x000000000043ba28 in connection_operation (ctx=0x4880fdd0, arg_v=0x172c4ac0) at connection.c:1144 #7 0x000000000043bca5 in connection_read_thread (ctx=0x4880fdd0, argv=0x21) at connection.c:1223 #8 0x00000000005c15dc in ldap_int_thread_pool_wrapper (xpool=0x12e3da20) at tpool.c:663 #9 0x0000003c024062e7 in start_thread () from /lib64/libpthread.so.0 #10 0x0000003c018ce3bd in clone () from /lib64/libc.so.6 Thread 17 (Thread 1208023360 (LWP 4302)): #0 0x0000003c0240a496 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00000000005c2ab7 in ldap_pvt_thread_cond_wait (cond=0x12e3da50, mutex=0x12e3da28) at thr_posix.c:277 #2 0x00000000005c155d in ldap_int_thread_pool_wrapper (xpool=0x12e3da20) at tpool.c:654 #3 0x0000003c024062e7 in start_thread () from /lib64/libpthread.so.0 #4 0x0000003c018ce3bd in clone () from /lib64/libc.so.6 Thread 16 (Thread 1199630656 (LWP 4301)): #0 0x0000003c0240a496 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00000000005c2ab7 in ldap_pvt_thread_cond_wait (cond=0x12e3da50, mutex=0x12e3da28) at thr_posix.c:277 #2 0x00000000005c155d in ldap_int_thread_pool_wrapper (xpool=0x12e3da20) at tpool.c:654 #3 0x0000003c024062e7 in start_thread () from /lib64/libpthread.so.0 #4 0x0000003c018ce3bd in clone () from /lib64/libc.so.6 Thread 15 (Thread 1191237952 (LWP 4300)): #0 0x0000003c0240a496 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00000000005c2ab7 in ldap_pvt_thread_cond_wait (cond=0x12e3da50, mutex=0x12e3da28) at thr_posix.c:277 #2 0x00000000005c155d in ldap_int_thread_pool_wrapper (xpool=0x12e3da20) at tpool.c:654 #3 0x0000003c024062e7 in start_thread () from /lib64/libpthread.so.0 #4 0x0000003c018ce3bd in clone () from /lib64/libc.so.6 Thread 14 (Thread 1182845248 (LWP 4299)): #0 0x0000003c0240a496 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00000000005c2ab7 in ldap_pvt_thread_cond_wait (cond=0x12e3da50, mutex=0x12e3da28) at thr_posix.c:277 #2 0x00000000005c155d in ldap_int_thread_pool_wrapper (xpool=0x12e3da20) at tpool.c:654 #3 0x0000003c024062e7 in start_thread () from /lib64/libpthread.so.0 #4 0x0000003c018ce3bd in clone () from /lib64/libc.so.6 Thread 13 (Thread 1174452544 (LWP 4298)): #0 0x0000003c0240a496 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00000000005c2ab7 in ldap_pvt_thread_cond_wait (cond=0x12e3da50, mutex=0x12e3da28) at thr_posix.c:277 #2 0x00000000005c155d in ldap_int_thread_pool_wrapper (xpool=0x12e3da20) at tpool.c:654 #3 0x0000003c024062e7 in start_thread () from /lib64/libpthread.so.0 #4 0x0000003c018ce3bd in clone () from /lib64/libc.so.6 Thread 12 (Thread 1166059840 (LWP 4211)): #0 0x0000003c018b5c57 in sched_yield () from /lib64/libc.so.6 #1 0x00002aaaaadd2f98 in __os_yield () from /opt/db4/lib/libdb-4.7.so #2 0x00002aaaaace13f6 in __db_tas_mutex_lock () from /opt/db4/lib/libdb-4.7.so #3 0x00002aaaaadc0928 in __memp_alloc () from /opt/db4/lib/libdb-4.7.so #4 0x00002aaaaadc2153 in __memp_fget () from /opt/db4/lib/libdb-4.7.so #5 0x00002aaaaacf5511 in __bam_search () from /opt/db4/lib/libdb-4.7.so #6 0x00002aaaaace4f57 in __bamc_init () from /opt/db4/lib/libdb-4.7.so #7 0x00002aaaaace6e2c in __bamc_init () from /opt/db4/lib/libdb-4.7.so #8 0x00002aaaaad7d8ea in __dbc_get () from /opt/db4/lib/libdb-4.7.so #9 0x00002aaaaad89474 in __dbc_get_pp () from /opt/db4/lib/libdb-4.7.so #10 0x00000000005326cc in hdb_idl_fetch_key (be=0x12efd140, db=0x1ebccc70, txn=0x161c30b0, key=0x45688290, ids=0x173c6720, saved_cursor=0x0, get_flag=0) at idl.c:604 #11 0x0000000000536635 in hdb_key_read (be=0x12efd140, db=0x1ebccc70, txn=0x161c30b0, k=0x172c6bc8, ids=0x173c6720, saved_cursor=0x0, get_flag=0) at key.c:50 #12 0x000000000052e5ad in equality_candidates (op=0x161c2b00, rtxn=0x161c30b0, ava=0x172c6a60, ids=0x176c6720, tmp=0x173c6720) at filterindex.c:788 #13 0x000000000052ce70 in hdb_filter_candidates (op=0x161c2b00, rtxn=0x161c30b0, f=0x172c6aa0, ids=0x176c6720, tmp=0x173c6720, stack=0x177c6720) at filterindex.c:154 #14 0x000000000052d9f2 in list_candidates (op=0x161c2b00, rtxn=0x161c30b0, flist=0x172c6a40, ftype=160, ids=0x175c6720, tmp=0x173c6720, save=0x176c6720) at filterindex.c:581 #15 0x000000000052d2e4 in hdb_filter_candidates (op=0x161c2b00, rtxn=0x161c30b0, f=0x172c6ac0, ids=0x175c6720, tmp=0x173c6720, stack=0x176c6720) at filterindex.c:198 #16 0x000000000052d9f2 in list_candidates (op=0x161c2b00, rtxn=0x161c30b0, flist=0x45688870, ftype=161, ids=0x174c6720, tmp=0x173c6720, save=0x175c6720) at filterindex.c:581 #17 0x000000000052d38c in hdb_filter_candidates (op=0x161c2b00, rtxn=0x161c30b0, f=0x45688850, ids=0x174c6720, tmp=0x173c6720, stack=0x175c6720) at filterindex.c:204 #18 0x000000000052d9f2 in list_candidates (op=0x161c2b00, rtxn=0x161c30b0, flist=0x45688830, ftype=160, ids=0x45708aa0, tmp=0x173c6720, save=0x174c6720) at filterindex.c:581 #19 0x000000000052d2e4 in hdb_filter_candidates (op=0x161c2b00, rtxn=0x161c30b0, f=0x45688890, ids=0x45708aa0, tmp=0x173c6720, stack=0x174c6720) at filterindex.c:198 #20 0x00000000004e67f7 in search_candidates (op=0x161c2b00, rs=0x45809c80, e=0x45688a50, txn=0x161c30b0, ids=0x45708aa0, scopes=0x45688aa0) at search.c:1204 #21 0x00000000004e4b47 in hdb_search (op=0x161c2b00, rs=0x45809c80) at search.c:585 #22 0x000000000043ecfa in fe_op_search (op=0x161c2b00, rs=0x45809c80) at search.c:366 #23 0x000000000043e634 in do_search (op=0x161c2b00, rs=0x45809c80) at search.c:217 #24 0x000000000043b78a in connection_operation (ctx=0x45809dd0, arg_v=0x161c2b00) at connection.c:1097 #25 0x000000000043bca5 in connection_read_thread (ctx=0x45809dd0, argv=0x19) at connection.c:1223 #26 0x00000000005c15dc in ldap_int_thread_pool_wrapper (xpool=0x12e3da20) at tpool.c:663 #27 0x0000003c024062e7 in start_thread () from /lib64/libpthread.so.0 #28 0x0000003c018ce3bd in clone () from /lib64/libc.so.6 Thread 11 (Thread 1157667136 (LWP 4210)): #0 0x0000003c0240a496 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002aaaaace186d in __db_pthread_mutex_lock () from /opt/db4/lib/libdb-4.7.so #2 0x00002aaaaace140b in __db_tas_mutex_lock () from /opt/db4/lib/libdb-4.7.so #3 0x00002aaaaad5f341 in __lock_get_internal () from /opt/db4/lib/libdb-4.7.so #4 0x00002aaaaad5f921 in __lock_get_pp () from /opt/db4/lib/libdb-4.7.so #5 0x0000000000521970 in bdb_cache_entry_db_lock (bdb=0x12efd2d0, txn=0x161c3480, ei=0x12ee3ed0, rw=0, tryOnly=0, lock=0x44e87a10) at cache.c:221 #6 0x0000000000522ef5 in hdb_cache_find_id (op=0x161c2620, tid=0x161c3480, id=74, eip=0x44e878c0, flag=0, lock=0x44e87a10) at cache.c:951 #7 0x0000000000529aad in hdb_dn2entry (op=0x161c2620, tid=0x161c3480, dn=0x161c2658, e=0x44e87a40, matched=1, lock=0x44e87a10) at dn2entry.c:67 #8 0x00000000004e3f73 in hdb_search (op=0x161c2620, rs=0x45008c80) at search.c:373 #9 0x000000000043ecfa in fe_op_search (op=0x161c2620, rs=0x45008c80) at search.c:366 #10 0x000000000043e634 in do_search (op=0x161c2620, rs=0x45008c80) at search.c:217 #11 0x000000000043b78a in connection_operation (ctx=0x45008dd0, arg_v=0x161c2620) at connection.c:1097 #12 0x000000000043bca5 in connection_read_thread (ctx=0x45008dd0, argv=0x22) at connection.c:1223 #13 0x00000000005c15dc in ldap_int_thread_pool_wrapper (xpool=0x12e3da20) at tpool.c:663 #14 0x0000003c024062e7 in start_thread () from /lib64/libpthread.so.0 #15 0x0000003c018ce3bd in clone () from /lib64/libc.so.6 Thread 10 (Thread 1149274432 (LWP 4209)): #0 0x0000003c0240a496 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00000000005c2ab7 in ldap_pvt_thread_cond_wait (cond=0x12e3da50, mutex=0x12e3da28) at thr_posix.c:277 #2 0x00000000005c155d in ldap_int_thread_pool_wrapper (xpool=0x12e3da20) at tpool.c:654 #3 0x0000003c024062e7 in start_thread () from /lib64/libpthread.so.0 #4 0x0000003c018ce3bd in clone () from /lib64/libc.so.6 Thread 9 (Thread 1140881728 (LWP 4208)): #0 0x0000003c0240a496 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00000000005c2ab7 in ldap_pvt_thread_cond_wait (cond=0x12e3da50, mutex=0x12e3da28) at thr_posix.c:277 #2 0x00000000005c155d in ldap_int_thread_pool_wrapper (xpool=0x12e3da20) at tpool.c:654 #3 0x0000003c024062e7 in start_thread () from /lib64/libpthread.so.0 #4 0x0000003c018ce3bd in clone () from /lib64/libc.so.6 Thread 8 (Thread 1132489024 (LWP 4207)): #0 0x00002aaaaad5d361 in __lock_locker_is_parent () from /opt/db4/lib/libdb-4.7.so #1 0x00002aaaaad5e544 in __lock_get_internal () from /opt/db4/lib/libdb-4.7.so #2 0x00002aaaaad5f692 in __lock_get () from /opt/db4/lib/libdb-4.7.so #3 0x00002aaaaad8b7f4 in __db_lget () from /opt/db4/lib/libdb-4.7.so #4 0x00002aaaaacf4eaf in __bam_get_root () from /opt/db4/lib/libdb-4.7.so #5 0x00002aaaaacf5222 in __bam_search () from /opt/db4/lib/libdb-4.7.so #6 0x00002aaaaace4f57 in __bamc_init () from /opt/db4/lib/libdb-4.7.so #7 0x00002aaaaace6e2c in __bamc_init () from /opt/db4/lib/libdb-4.7.so #8 0x00002aaaaad7d8ea in __dbc_get () from /opt/db4/lib/libdb-4.7.so #9 0x00002aaaaad89474 in __dbc_get_pp () from /opt/db4/lib/libdb-4.7.so #10 0x00000000005326cc in hdb_idl_fetch_key (be=0x12efd140, db=0x1ebccc70, txn=0x2aac460024d0, key=0x43684290, ids=0x2aac46102e40, saved_cursor=0x0, get_flag=0) at idl.c:604 #11 0x0000000000536635 in hdb_key_read (be=0x12efd140, db=0x1ebccc70, txn=0x2aac460024d0, k=0x2aac460032e8, ids=0x2aac46102e40, saved_cursor=0x0, get_flag=0) at key.c:50 #12 0x000000000052e5ad in equality_candidates (op=0x2aac46000c30, rtxn=0x2aac460024d0, ava=0x2aac46003180, ids=0x2aac46402e40, tmp=0x2aac46102e40) at filterindex.c:788 #13 0x000000000052ce70 in hdb_filter_candidates (op=0x2aac46000c30, rtxn=0x2aac460024d0, f=0x2aac460031c0, ids=0x2aac46402e40, tmp=0x2aac46102e40, stack=0x2aac46502e40) at filterindex.c:154 #14 0x000000000052d9f2 in list_candidates (op=0x2aac46000c30, rtxn=0x2aac460024d0, flist=0x2aac46003160, ftype=160, ids=0x2aac46302e40, tmp=0x2aac46102e40, save=0x2aac46402e40) at filterindex.c:581 #15 0x000000000052d2e4 in hdb_filter_candidates (op=0x2aac46000c30, rtxn=0x2aac460024d0, f=0x2aac460031e0, ids=0x2aac46302e40, tmp=0x2aac46102e40, stack=0x2aac46402e40) at filterindex.c:198 #16 0x000000000052d9f2 in list_candidates (op=0x2aac46000c30, rtxn=0x2aac460024d0, flist=0x43684870, ftype=161, ids=0x2aac46202e40, tmp=0x2aac46102e40, save=0x2aac46302e40) at filterindex.c:581 #17 0x000000000052d38c in hdb_filter_candidates (op=0x2aac46000c30, rtxn=0x2aac460024d0, f=0x43684850, ids=0x2aac46202e40, tmp=0x2aac46102e40, stack=0x2aac46302e40) at filterindex.c:204 #18 0x000000000052d9f2 in list_candidates (op=0x2aac46000c30, rtxn=0x2aac460024d0, flist=0x43684830, ftype=160, ids=0x43704aa0, tmp=0x2aac46102e40, save=0x2aac46202e40) at filterindex.c:581 #19 0x000000000052d2e4 in hdb_filter_candidates (op=0x2aac46000c30, rtxn=0x2aac460024d0, f=0x43684890, ids=0x43704aa0, tmp=0x2aac46102e40, stack=0x2aac46202e40) at filterindex.c:198 #20 0x00000000004e67f7 in search_candidates (op=0x2aac46000c30, rs=0x43805c80, e=0x43684a50, txn=0x2aac460024d0, ids=0x43704aa0, scopes=0x43684aa0) at search.c:1204 #21 0x00000000004e4b47 in hdb_search (op=0x2aac46000c30, rs=0x43805c80) at search.c:585 #22 0x000000000043ecfa in fe_op_search (op=0x2aac46000c30, rs=0x43805c80) at search.c:366 #23 0x000000000043e634 in do_search (op=0x2aac46000c30, rs=0x43805c80) at search.c:217 #24 0x000000000043b78a in connection_operation (ctx=0x43805dd0, arg_v=0x2aac46000c30) at connection.c:1097 #25 0x000000000043bca5 in connection_read_thread (ctx=0x43805dd0, argv=0x15) at connection.c:1223 #26 0x00000000005c15dc in ldap_int_thread_pool_wrapper (xpool=0x12e3da20) at tpool.c:663 #27 0x0000003c024062e7 in start_thread () from /lib64/libpthread.so.0 #28 0x0000003c018ce3bd in clone () from /lib64/libc.so.6 Thread 7 (Thread 1124096320 (LWP 4206)): #0 0x0000003c0240a496 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00000000005c2ab7 in ldap_pvt_thread_cond_wait (cond=0x12e3da50, mutex=0x12e3da28) at thr_posix.c:277 #2 0x00000000005c155d in ldap_int_thread_pool_wrapper (xpool=0x12e3da20) at tpool.c:654 #3 0x0000003c024062e7 in start_thread () from /lib64/libpthread.so.0 #4 0x0000003c018ce3bd in clone () from /lib64/libc.so.6 Thread 6 (Thread 1115703616 (LWP 4205)): #0 0x0000003c0240d798 in pread64 () from /lib64/libpthread.so.0 #1 0x00002aaaaadd24ee in __os_io () from /opt/db4/lib/libdb-4.7.so #2 0x00002aaaaadc11c5 in __memp_pgread () from /opt/db4/lib/libdb-4.7.so #3 0x00002aaaaadc2b7f in __memp_fget () from /opt/db4/lib/libdb-4.7.so #4 0x00002aaaaacf5511 in __bam_search () from /opt/db4/lib/libdb-4.7.so #5 0x00002aaaaace4f57 in __bamc_init () from /opt/db4/lib/libdb-4.7.so #6 0x00002aaaaace6e2c in __bamc_init () from /opt/db4/lib/libdb-4.7.so #7 0x00002aaaaad7d8ea in __dbc_get () from /opt/db4/lib/libdb-4.7.so #8 0x00002aaaaad89474 in __dbc_get_pp () from /opt/db4/lib/libdb-4.7.so #9 0x000000000053032e in hdb_id2entry (be=0x12efd140, tid=0x2aac45000900, id=4194444, e=0x426828b0) at id2entry.c:125 #10 0x0000000000522f69 in hdb_cache_find_id (op=0x12ee4960, tid=0x2aac45000900, id=4194444, eip=0x42682a40, flag=0, lock=0x42682a10) at cache.c:958 #11 0x00000000004e5105 in hdb_search (op=0x12ee4960, rs=0x42803c80) at search.c:705 #12 0x000000000043ecfa in fe_op_search (op=0x12ee4960, rs=0x42803c80) at search.c:366 #13 0x000000000043e634 in do_search (op=0x12ee4960, rs=0x42803c80) at search.c:217 #14 0x000000000043b78a in connection_operation (ctx=0x42803dd0, arg_v=0x12ee4960) at connection.c:1097 #15 0x000000000043bca5 in connection_read_thread (ctx=0x42803dd0, argv=0x11) at connection.c:1223 #16 0x00000000005c15dc in ldap_int_thread_pool_wrapper (xpool=0x12e3da20) at tpool.c:663 #17 0x0000003c024062e7 in start_thread () from /lib64/libpthread.so.0 #18 0x0000003c018ce3bd in clone () from /lib64/libc.so.6 Thread 5 (Thread 1107310912 (LWP 4204)): #0 0x0000003c0240a496 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00000000005c2ab7 in ldap_pvt_thread_cond_wait (cond=0x12e3da50, mutex=0x12e3da28) at thr_posix.c:277 #2 0x00000000005c155d in ldap_int_thread_pool_wrapper (xpool=0x12e3da20) at tpool.c:654 #3 0x0000003c024062e7 in start_thread () from /lib64/libpthread.so.0 #4 0x0000003c018ce3bd in clone () from /lib64/libc.so.6 Thread 4 (Thread 1098918208 (LWP 4203)): #0 0x0000003c0186f798 in _int_malloc () from /lib64/libc.so.6 #1 0x0000003c01870c9d in malloc () from /lib64/libc.so.6 #2 0x00000000005f2b13 in ber_memalloc_x (s=2940, ctx=0x0) at memory.c:226 #3 0x000000000045f486 in ch_malloc (size=2940) at ch_malloc.c:54 #4 0x0000000000530402 in hdb_id2entry (be=0x12efd140, tid=0x12ea8150, id=4937379, e=0x416808b0) at id2entry.c:143 #5 0x0000000000522f69 in hdb_cache_find_id (op=0x12ee2530, tid=0x12ea8150, id=4937379, eip=0x41680a40, flag=0, lock=0x41680a10) at cache.c:958 #6 0x00000000004e5105 in hdb_search (op=0x12ee2530, rs=0x41801c80) at search.c:705 #7 0x000000000043ecfa in fe_op_search (op=0x12ee2530, rs=0x41801c80) at search.c:366 #8 0x000000000043e634 in do_search (op=0x12ee2530, rs=0x41801c80) at search.c:217 #9 0x000000000043b78a in connection_operation (ctx=0x41801dd0, arg_v=0x12ee2530) at connection.c:1097 #10 0x000000000043bca5 in connection_read_thread (ctx=0x41801dd0, argv=0x24) at connection.c:1223 #11 0x00000000005c15dc in ldap_int_thread_pool_wrapper (xpool=0x12e3da20) at tpool.c:663 #12 0x0000003c024062e7 in start_thread () from /lib64/libpthread.so.0 #13 0x0000003c018ce3bd in clone () from /lib64/libc.so.6 Thread 3 (Thread 1082132800 (LWP 4174)): #0 0x0000003c018ce7a8 in epoll_wait () from /lib64/libc.so.6 #1 0x0000000000437e8c in slapd_daemon_task (ptr=0x0) at daemon.c:2291 #2 0x0000003c024062e7 in start_thread () from /lib64/libpthread.so.0 #3 0x0000003c018ce3bd in clone () from /lib64/libc.so.6 Thread 2 (Thread 1090525504 (LWP 4175)): #0 0x0000003c024082e9 in pthread_mutex_lock () from /lib64/libpthread.so.0 #1 0x00000000005c2b01 in ldap_pvt_thread_mutex_lock (mutex=0x58) at thr_posix.c:296 #2 0x0000000000523d44 in bdb_cache_delete_internal (cache=0x12efd330, e=0x2aac4fb3c8d0, decr=0) at cache.c:1372 #3 0x0000000000522a32 in hdb_cache_lru_purge (bdb=0x12efd2d0) at cache.c:776 #4 0x0000000000523323 in hdb_cache_find_id (op=0x12ee1630, tid=0x12ee3510, id=243315, eip=0x40e7fa40, flag=0, lock=0x40e7fa10) at cache.c:1053 #5 0x00000000004e5105 in hdb_search (op=0x12ee1630, rs=0x41000c80) at search.c:705 #6 0x000000000043ecfa in fe_op_search (op=0x12ee1630, rs=0x41000c80) at search.c:366 #7 0x000000000043e634 in do_search (op=0x12ee1630, rs=0x41000c80) at search.c:217 #8 0x000000000043b78a in connection_operation (ctx=0x41000dd0, arg_v=0x12ee1630) at connection.c:1097 #9 0x000000000043bca5 in connection_read_thread (ctx=0x41000dd0, argv=0xd) at connection.c:1223 #10 0x00000000005c15dc in ldap_int_thread_pool_wrapper (xpool=0x12e3da20) at tpool.c:663 #11 0x0000003c024062e7 in start_thread () from /lib64/libpthread.so.0 #12 0x0000003c018ce3bd in clone () from /lib64/libc.so.6 Thread 1 (Thread 46912501776800 (LWP 4154)): #0 0x0000003c024075a5 in pthread_join () from /lib64/libpthread.so.0 #1 0x00000000005c2a0f in ldap_pvt_thread_join (thread=1082132800, thread_return=0x0) at thr_posix.c:197 #2 0x0000000000438c33 in slapd_daemon () at daemon.c:2665 #3 0x000000000041bcb2 in main (argc=5, argv=0x7fff8a4f4f48) at main.c:948 #0 0x0000003c024082e9 in pthread_mutex_lock () from /lib64/libpthread.so.0 (gdb) quit The program is running. Quit anyway (and detach it)? (y or n) Detaching from program: /opt/openldap2/libexec/slapd, process 4154 --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6080) Page Fault in ber_strndup_x
by roger.smith＠bluecoat.com 28 Apr '09

28 Apr '09

Full_Name: Roger Smith Version: 2.4.16 OS: Any URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (65.46.48.194) The function ldap_bv2dn_x is supposed to handle a buffer that is not NULL terminated, as are the functions ldap_bv2rdn_x, str2strval, and ber_strndup_x (through macro LDAP_STRNDUPX)which are in it's codepath. However, in ber_strndup_x (liblber/memory.c) a call is made to strlen which expects a NULL terminated string. At a minimum, this will waste CPU cycles as strlen can continue far past the end of the buffer until it finds a NULL. In the worst case, this sometimes causes a page fault when strlen continues off into protected memory. This code should be changed to use strnlen, or a locally defined equivilent. e.g. 669,673c669 < len = strlen( s ); < < if ( len > l ) { < len = l; < } --- > len = strnlen( s, l );

1 0

Re: (ITS#6040) SEGV - hdb_cache_lru_purge / bdb_cache_delete_internal / ldap_pvt_thread_mutex_lock
by oskar＠deckle.co.za 28 Apr '09

28 Apr '09

Hi We're still unfortunately stuck on 2.4.15 pending various changecontrols on our side. I have a work-around, however for 2.4.15 - in case anyone ever reads this ticket and has further problems. By dramatically increasing the cachesize and idlcachesize entries in the relevant hdb database section, the cache is walked less often, and cleaned out less often. This reduces the number of times the problem could occur, which seems to have reduced the incidence from around 4* a day down to zero times in the last 20 days. We are using cachesize of 20000 and idlsize of 60000. This increases memory size, but gives us stability. Thanks, Oskar On 27 Mar 2009, at 09:52, openldap-its(a)OpenLDAP.org wrote: > > *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** > > Thanks for your report to the OpenLDAP Issue Tracking System. Your > report has been assigned the tracking number ITS#6040. > > One of our support engineers will look at your report in due course. > Note that this may take some time because our support engineers > are volunteers. They only work on OpenLDAP when they have spare > time. > > If you need to provide additional information in regards to your > issue report, you may do so by replying to this message. Note that > any mail sent to openldap-its(a)openldap.org with (ITS#6040) > in the subject will automatically be attached to the issue report. > > mailto:openldap-its@openldap.org?subject=(ITS#6040) > > You may follow the progress of this report by loading the following > URL in a web browser: > http://www.OpenLDAP.org/its/index.cgi?findid=6040 > > Please remember to retain your issue tracking number (ITS#6040) > on any further messages you send to us regarding this report. If > you don't then you'll just waste our time and yours because we > won't be able to properly track the report. > > Please note that the Issue Tracking System is not intended to > be used to seek help in the proper use of OpenLDAP Software. > Such requests will be closed. > > OpenLDAP Software is user supported. > http://www.OpenLDAP.org/support/ > > -------------- > Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved.

1 0

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

28 Apr '09

Hi Apologies - I was incorrect in item 2. We have not yet upgraded to 2.4.16 - that changecontrol is still pending. So the patch I referred to applies to 2.4.15. Thanks, and good luck. Oskar On 28 Apr 2009, at 15:16, Oskar Pearson wrote: > Hi David > > On 28 Apr 2009, at 12:20, David Angerer wrote: > >> Hi there, >> >> Already posted this a while ago to openldap-bugs, but havn't got a >> response yet. As the problem still persist in my environment, I'll >> give it another try here. >> >> We upgraded to openldap 2.4.16 a while ago. Since then we are >> experiencing relatively frequent core dumps (average uptime is around >> 2-3 days). Investigating the root cause we came across ITS#6034 which >> reminded us much of problem we are facing, but should be fixed in >> 2.4.16. > > We've not had a crash related to this (or its #5836) since doing the > following four things: > > 1) Fixing path-mtu issues on the network with the VPN, so that when > large transactions occurred, the network wouldn't go into infinite > wait, chewing up threads. Links flapping up and down, or path-mtu- > discovery icmp filtering can have the same effect and be out of your > control. > > 2) Upgrading to 2.4.16 > > 3) setting this in slapd.conf (after applying the patch in the next > step) > writetimeout 30 > > 4) Applying the patch here. > The patch is a hacked up version of the patch relating to #5836 > pulled out of CVS, which removes some of the threading aspects, and > "clarifies" some of the code in the process. > > If I were you, I'd try to pull the #5836 patch out of CVS and see if > that helps you. If not, or you need a very urgent fix to see if this > helps, then consider using this patch. > > I have to make numerous disclaimers about this patch... > 4a) some of it may be a less-optimal way of performing the same > changes that are mentioned in #5836 in trunk. I originally started > hacking that code as I encountered some "wierdness" in it - where > straces didn't do what I expected. In retrospect, I think some of > that may have been optimisations that I didn't understand at the > time. I tested my hacked-up patch, and it worked, so I've stuck to > it since. I intend to re-pull the original patch out of the cvs > source sometime and re-test it, but I've not had time. > 4b) It works for us, but I make you absolutely no promises - I am > releasing it under the same licence as openldap (no warantee, etc > etc etc). > 4c) it probably only reduces the problem because of some corner-case > that I am completely unaware of. EG: it may mean the assert-ing code > is never reached because the connections never reach the expected > thread state. > 4d) I've not done any C code for years, nor do I have very much > experience with the openldap source. > 4e) I fully expect at least three flames from Howard Chu including > great detail about why this patch is horrible. :) But at least it > has some useful comments. :) > > > <oskar-connection-patch-v1> > > > Hope that helps. > > Oskar > > >> Setup: >> Solaris 10 >> Openldap 2.4.16 (64bit) >> Berkeley DB 4.7 >> >> 1 Master >> 5 Replicas with deltasyncrepl >> >> Cores only happened to the master so far, replicas are running >> stable so far. >> >> I couldn't find a reference to this ITS in the 2.4.16 changelog >> (probably listed as other ITS or fixed earlier). >> Also if the fix made it's way into 2.4.16, I am wondering why we >> still >> observe this cores. >> >> If you need further information or have any suggestions please let me >> know. Please find some debugging information below. >> >> Kind regards, >> David >> >> (dbx) threads >> t@1 a l@1 ?() LWP suspended in __lwp_wait() >> t@2 a l@2 slapd_daemon_task() LWP suspended in __pollsys() >> t@3 a l@3 ldap_int_thread_pool_wrapper() sleep on >> 0x1004dd428 in __lwp_park() >> t@4 a l@4 ldap_int_thread_pool_wrapper() LWP suspended in >> ___lwp_cond_wait() >> t@5 a l@5 ldap_int_thread_pool_wrapper() LWP suspended in >> ___lwp_cond_wait() >> t@6 a l@6 ldap_int_thread_pool_wrapper() LWP suspended in >> ___lwp_cond_wait() >> t@7 a l@7 ldap_int_thread_pool_wrapper() sleep on >> 0x1004dd670 in __lwp_park() >> t@8 a l@8 ldap_int_thread_pool_wrapper() LWP suspended in >> ___lwp_cond_wait() >> t@9 a l@9 ldap_int_thread_pool_wrapper() sleep on >> 0x1004a9908 in __lwp_park() >> o t@10 a l@10 ldap_int_thread_pool_wrapper() signal SIGABRT >> in >> __lwp_kill() >> t@11 a l@11 ldap_int_thread_pool_wrapper() sleep on >> 0x1004a9908 in __lwp_park() >> t@12 a l@12 ldap_int_thread_pool_wrapper() LWP suspended in >> ___lwp_cond_wait() >>> t@13 a l@13 ldap_int_thread_pool_wrapper() LWP suspended in >> slap_access_allowed() >> t@14 a l@14 ldap_int_thread_pool_wrapper() LWP suspended in >> ___lwp_cond_wait() >> t@15 a l@15 ldap_int_thread_pool_wrapper() sleep on >> 0x1004dd1e0 in __lwp_park() >> t@16 a l@16 ldap_int_thread_pool_wrapper() LWP suspended in >> ___lwp_cond_wait() >> t@17 a l@17 ldap_int_thread_pool_wrapper() sleep on >> 0x1004a9908 in __lwp_park() >> t@18 a l@18 ldap_int_thread_pool_wrapper() LWP suspended in >> __lock_getlocker_int() >> (dbx) lwp l@10 >> Current function is connection_state_closing >> 686 assert( c->c_struct_state == SLAP_C_USED ); >> t@10 (l@10) stopped in __lwp_kill at 0xffffffff7decea00 >> 0xffffffff7decea00: __lwp_kill+0x0008: bcc,a,pt %icc,__lwp_kill >> +0x18 >> ! 0xffffffff7decea10 >> (dbx) where >> [1] __lwp_kill(0x0, 0x6, 0x10004b128, 0x19d480, 0x0, 0x0), at >> 0xffffffff7decea00 [2] raise(0x6, 0x0, 0x100445d58, >> 0xffffffffffffffff, 0xffffffff7dfe6000, 0x0), at 0xffffffff7de6b4f4 >> [3] abort(0x1, 0x1b8, 0x10004b128, 0x19d480, 0x0, 0x0), at >> 0xffffffff7de48c8c [4] __assert(0x100271f48, 0x100271f70, 0x2ae, >> 0x0, >> 0x19d138, 0x100069f70), at 0xffffffff7de48f30 =>[5] >> connection_state_closing(c = 0x1004dce30), line 686 in "connection.c" >> [6] send_ldap_ber(op = 0xffffffff733ff768, ber = 0xffffffff733ff028), >> line 148 in "result.c" >> [7] slap_send_search_entry(op = 0xffffffff733ff768, rs = >> 0xffffffff733ff2d0), line 1247 in "result.c" >> [8] syncprov_sendresp(op = 0xffffffff733ff768, opc = >> 0xffffffff733ff4a0, so = 0x113c0a930, e = 0xffffffff733ff500, mode = >> 3), line 848 in "syncprov.c" >> [9] syncprov_qplay(op = 0xffffffff733ff768, so = 0x113c0a930), line >> 913 in "syncprov.c" >> [10] syncprov_qtask(ctx = 0xffffffff733ffc20, arg = 0x113c0a930), >> line 971 in "syncprov.c" >> [11] ldap_int_thread_pool_wrapper(xpool = 0x10046a250), line 663 in >> "tpool.c" >> (dbx) list 680,690 >> 680 int connection_state_closing( Connection *c ) >> 681 { >> 682 /* c_mutex must be locked by caller */ >> 683 >> 684 int state; >> 685 assert( c != NULL ); >> 686 assert( c->c_struct_state == SLAP_C_USED ); >> 687 >> 688 state = c->c_conn_state; >> 689 >> 690 assert( state != SLAP_C_INVALID ); >> (dbx) print c >> c = 0x1004dce30 >> (dbx) print *c >> *c = { >> c_struct_state = 1 >> c_conn_state = 0 >> c_conn_idx = 26 >> c_sd = -1 >> c_close_reason = 0x100271eb0 "?" >> c_mutex = { >> __pthread_mutex_flags = { >> __pthread_mutex_flag1 = 4U >> __pthread_mutex_flag2 = '\0' >> __pthread_mutex_ceiling = '\0' >> __pthread_mutex_type = 0 >> __pthread_mutex_magic = 19800U >> } >> __pthread_mutex_lock = { >> __pthread_mutex_lock64 = { >> __pthread_mutex_pad = "" >> } >> __pthread_mutex_lock32 = { >> __pthread_ownerpid = 0 >> __pthread_lockword = 0 >> } >> __pthread_mutex_owner64 = 0 >> } >> __pthread_mutex_data = 0 >> } >> c_sb = 0x118772d90 >> c_starttime = 0 >> c_activitytime = 0 >> c_connid = 18446744073709551615U >> c_peer_domain = { >> bv_len = 0 >> bv_val = (nil) >> } >> c_peer_name = { >> bv_len = 0 >> bv_val = (nil) >> } >> c_listener = (nil) >> c_sasl_bind_mech = { >> bv_len = 0 >> bv_val = (nil) >> } >> c_sasl_dn = { >> bv_len = 0 >> bv_val = (nil) >> } >> c_sasl_authz_dn = { >> bv_len = 0 >> bv_val = (nil) >> } >> c_authz_backend = (nil) >> c_authz_cookie = (nil) >> c_authz = { >> sai_method = 128U >> sai_mech = { >> bv_len = 0 >> bv_val = (nil) >> } >> sai_dn = { >> bv_len = 0 >> bv_val = (nil) >> } >> sai_ndn = { >> bv_len = 0 >> bv_val = (nil) >> } >> sai_ssf = 0 >> sai_transport_ssf = 0 >> sai_tls_ssf = 0 >> sai_sasl_ssf = 0 >> } >> c_protocol = 0 >> c_ops = { >> stqh_first = (nil) >> stqh_last = 0x1004dcf38 >> } >> c_pending_ops = { >> stqh_first = (nil) >> stqh_last = 0x1004dcf48 >> } >> c_write1_mutex = { >> __pthread_mutex_flags = { >> __pthread_mutex_flag1 = 4U >> __pthread_mutex_flag2 = '\0' >> __pthread_mutex_ceiling = '\0' >> __pthread_mutex_type = 0 >> __pthread_mutex_magic = 19800U >> } >> __pthread_mutex_lock = { >> __pthread_mutex_lock64 = { >> __pthread_mutex_pad = "" >> } >> __pthread_mutex_lock32 = { >> __pthread_ownerpid = 0 >> __pthread_lockword = 4278190080U >> } >> __pthread_mutex_owner64 = 4278190080U >> } >> __pthread_mutex_data = 18446744071451976704U >> } >> c_write1_cv = { >> __pthread_cond_flags = { >> __pthread_cond_flag = "" >> __pthread_cond_type = 0 >> __pthread_cond_magic = 17238U >> } >> __pthread_cond_data = 0 >> } >> c_write2_mutex = { >> __pthread_mutex_flags = { >> __pthread_mutex_flag1 = 4U >> __pthread_mutex_flag2 = '\0' >> __pthread_mutex_ceiling = '\0' >> __pthread_mutex_type = 0 >> __pthread_mutex_magic = 19800U >> } >> __pthread_mutex_lock = { >> __pthread_mutex_lock64 = { >> __pthread_mutex_pad = "" >> } >> __pthread_mutex_lock32 = { >> __pthread_ownerpid = 0 >> __pthread_lockword = 0 >> } >> __pthread_mutex_owner64 = 0 >> } >> __pthread_mutex_data = 0 >> } >> c_write2_cv = { >> __pthread_cond_flags = { >> __pthread_cond_flag = "" >> __pthread_cond_type = 0 >> __pthread_cond_magic = 17238U >> } >> __pthread_cond_data = 0 >> } >> c_currentber = (nil) >> c_writers = 0 >> c_sasl_bind_in_progress = '\0' >> c_writewaiter = '\0' >> c_sasl_layers = '\0' >> c_sasl_done = '\0' >> c_sasl_authctx = (nil) >> c_sasl_sockctx = (nil) >> c_sasl_extra = (nil) >> c_sasl_bindop = (nil) >> c_pagedresults_state = { >> ps_be = (nil) >> ps_size = 0 >> ps_count = 0 >> ps_cookie = 0 >> ps_cookieval = { >> bv_len = 0 >> bv_val = (nil) >> } >> } >> c_n_ops_received = 3 >> c_n_ops_executing = 0 >> c_n_ops_pending = 0 >> c_n_ops_completed = 3 >> c_n_get = 4 >> c_n_read = 3 >> c_n_write = 1 >> c_extensions = (nil) >> c_clientfunc = (nil) >> c_clientarg = (nil) >> c_send_ldap_result = 0x10006b900 = >> &slap_send_ldap_result(Operation *op, SlapReply *rs) >> c_send_search_entry = 0x10006cda0 = >> &slap_send_search_entry(Operation *op, SlapReply *rs) >> c_send_search_reference = 0x10006fa80 = >> &slap_send_search_reference(Operation *op, SlapReply *rs) >> c_send_ldap_extended = 0x10006c5f8 = >> &slap_send_ldap_extended(Operation *op, SlapReply *rs) >> c_send_ldap_intermediate = 0x10006ca28 = >> &slap_send_ldap_intermediate(Operation *op, SlapReply *rs) } >

1 0

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

28 Apr '09

--Apple-Mail-3-627969786 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi David On 28 Apr 2009, at 12:20, David Angerer wrote: > Hi there, > > Already posted this a while ago to openldap-bugs, but havn't got a > response yet. As the problem still persist in my environment, I'll > give it another try here. > > We upgraded to openldap 2.4.16 a while ago. Since then we are > experiencing relatively frequent core dumps (average uptime is around > 2-3 days). Investigating the root cause we came across ITS#6034 which > reminded us much of problem we are facing, but should be fixed in > 2.4.16. We've not had a crash related to this (or its #5836) since doing the following four things: 1) Fixing path-mtu issues on the network with the VPN, so that when large transactions occurred, the network wouldn't go into infinite wait, chewing up threads. Links flapping up and down, or path-mtu- discovery icmp filtering can have the same effect and be out of your control. 2) Upgrading to 2.4.16 3) setting this in slapd.conf (after applying the patch in the next step) writetimeout 30 4) Applying the patch here. The patch is a hacked up version of the patch relating to #5836 pulled out of CVS, which removes some of the threading aspects, and "clarifies" some of the code in the process. If I were you, I'd try to pull the #5836 patch out of CVS and see if that helps you. If not, or you need a very urgent fix to see if this helps, then consider using this patch. I have to make numerous disclaimers about this patch... 4a) some of it may be a less-optimal way of performing the same changes that are mentioned in #5836 in trunk. I originally started hacking that code as I encountered some "wierdness" in it - where straces didn't do what I expected. In retrospect, I think some of that may have been optimisations that I didn't understand at the time. I tested my hacked-up patch, and it worked, so I've stuck to it since. I intend to re-pull the original patch out of the cvs source sometime and re-test it, but I've not had time. 4b) It works for us, but I make you absolutely no promises - I am releasing it under the same licence as openldap (no warantee, etc etc etc). 4c) it probably only reduces the problem because of some corner-case that I am completely unaware of. EG: it may mean the assert-ing code is never reached because the connections never reach the expected thread state. 4d) I've not done any C code for years, nor do I have very much experience with the openldap source. 4e) I fully expect at least three flames from Howard Chu including great detail about why this patch is horrible. :) But at least it has some useful comments. :) --Apple-Mail-3-627969786 Content-Disposition: attachment; filename=oskar-connection-patch-v1 Content-Type: application/octet-stream; x-unix-mode=0644; name="oskar-connection-patch-v1" Content-Transfer-Encoding: 7bit diff -urN openldap-2.4.15-plain-source/doc/man/man5/slapd-config.5 openldap-2.4.15-oskar-connection-patch/doc/man/man5/slapd-config.5 --- openldap-2.4.15-plain-source/doc/man/man5/slapd-config.5 2009-01-22 00:00:50.000000000 +0000 +++ openldap-2.4.15-oskar-connection-patch/doc/man/man5/slapd-config.5 2009-03-11 14:15:59.000000000 +0000 @@ -451,7 +451,9 @@ .B olcIdleTimeout: <integer> Specify the number of seconds to wait before forcibly closing an idle client connection. A setting of 0 disables this -feature. The default is 0. +feature. The default is 0. You may also want to set the +.B olcWriteTimeout +option. .TP .B olcIndexIntLen: <integer> Specify the key length for ordered integer indices. The most significant @@ -750,11 +752,12 @@ Specify the maximum number of threads to use in tool mode. This should not be greater than the number of CPUs in the system. The default is 1. -.\"ucdata-path is obsolete / ignored... -.\".TP -.\".B ucdata-path <path> -.\"Specify the path to the directory containing the Unicode character -.\"tables. The default path is DATADIR/ucdata. +.TP +.B olcWriteTimeout: <integer> +Specify the number of seconds to wait before forcibly closing +a connection with an outstanding write. This allows recovery from +various network hang conditions. A setting of 0 disables this +feature. The default is 0. .SH TLS OPTIONS If .B slapd diff -urN openldap-2.4.15-plain-source/servers/slapd/bconfig.c openldap-2.4.15-oskar-connection-patch/servers/slapd/bconfig.c --- openldap-2.4.15-plain-source/servers/slapd/bconfig.c 2009-02-13 03:16:59.000000000 +0000 +++ openldap-2.4.15-oskar-connection-patch/servers/slapd/bconfig.c 2009-03-11 14:16:14.000000000 +0000 @@ -706,6 +706,9 @@ &config_updateref, "( OLcfgDbAt:0.13 NAME 'olcUpdateRef' " "EQUALITY caseIgnoreMatch " "SUP labeledURI )", NULL, NULL }, + { "writetimeout", "timeout", 2, 2, 0, ARG_INT, + &global_writetimeout, "( OLcfgGlAt:88 NAME 'olcWriteTimeout' " + "SYNTAX OMsInteger SINGLE-VALUE )", NULL, NULL }, { NULL, NULL, 0, 0, 0, ARG_IGNORED, NULL, NULL, NULL, NULL } }; @@ -764,7 +767,7 @@ "olcTLSCACertificatePath $ olcTLSCertificateFile $ " "olcTLSCertificateKeyFile $ olcTLSCipherSuite $ olcTLSCRLCheck $ " "olcTLSRandFile $ olcTLSVerifyClient $ olcTLSDHParamFile $ " - "olcTLSCRLFile $ olcToolThreads $ " + "olcTLSCRLFile $ olcToolThreads $ olcWriteTimeout $ " "olcObjectIdentifier $ olcAttributeTypes $ olcObjectClasses $ " "olcDitContentRules $ olcLdapSyntaxes ) )", Cft_Global }, { "( OLcfgGlOc:2 " diff -urN openldap-2.4.15-plain-source/servers/slapd/config.c openldap-2.4.15-oskar-connection-patch/servers/slapd/config.c --- openldap-2.4.15-plain-source/servers/slapd/config.c 2009-02-13 03:16:59.000000000 +0000 +++ openldap-2.4.15-oskar-connection-patch/servers/slapd/config.c 2009-03-11 14:16:54.000000000 +0000 @@ -62,6 +62,7 @@ slap_mask_t global_disallows = 0; int global_gentlehup = 0; int global_idletimeout = 0; +int global_writetimeout = 0; char *global_host = NULL; char *global_realm = NULL; char *sasl_host = NULL; diff -urN openldap-2.4.15-plain-source/servers/slapd/connection.c openldap-2.4.15-oskar-connection-patch/servers/slapd/connection.c --- openldap-2.4.15-plain-source/servers/slapd/connection.c 2009-01-30 18:51:16.000000000 +0000 +++ openldap-2.4.15-oskar-connection-patch/servers/slapd/connection.c 2009-03-11 21:44:57.000000000 +0000 @@ -244,6 +244,42 @@ return i; } +/* + * Timeout connections that are having trouble writing + */ +int connections_timeout_write(time_t now) +{ + int i = 0; + int connindex; + Connection* c; + + for( c = connection_first( &connindex ); + c != NULL; + c = connection_next( c, &connindex ) ) + { + /* Don't timeout an outbound connection */ + if( c->c_conn_state == SLAP_C_CLIENT ) { + continue; + } + + if (! c->c_writewaiter ) { + continue; + } + + if( difftime( c->c_activitytime+global_writetimeout, now) < 0 ) { + /* close it */ + Debug( LDAP_DEBUG_CONNS, + "connection_closing: due to write timeout", NULL, 0, 0 ); + connection_closing( c, "writetimeout" ); + connection_close( c ); + i++; + } + } + connection_done( c ); + + return i; +} + static Connection* connection_get( ber_socket_t s ) { Connection *c; diff -urN openldap-2.4.15-plain-source/servers/slapd/daemon.c openldap-2.4.15-oskar-connection-patch/servers/slapd/daemon.c --- openldap-2.4.15-plain-source/servers/slapd/daemon.c 2009-02-13 02:35:39.000000000 +0000 +++ openldap-2.4.15-oskar-connection-patch/servers/slapd/daemon.c 2009-03-11 23:11:00.000000000 +0000 @@ -2033,25 +2033,23 @@ { int l; time_t last_idle_check = 0; - struct timeval idle; + time_t last_write_timeout_check = 0; int ebadf = 0; #define SLAPD_IDLE_CHECK_LIMIT 4 +#define SLAPD_WRITE_CHECK_LIMIT 8 - if ( global_idletimeout > 0 ) { - last_idle_check = slap_get_time(); - /* Set the select timeout. - * Don't just truncate, preserve the fractions of - * seconds to prevent sleeping for zero time. - */ - idle.tv_sec = global_idletimeout / SLAPD_IDLE_CHECK_LIMIT; - idle.tv_usec = global_idletimeout - \ - ( idle.tv_sec * SLAPD_IDLE_CHECK_LIMIT ); - idle.tv_usec *= 1000000 / SLAPD_IDLE_CHECK_LIMIT; - } else { - idle.tv_sec = 0; - idle.tv_usec = 0; - } + /* This is how long we are going to sleep for, before we next need to check for idle or + * timed-out connections */ + struct timeval next_sleep; + + /* + * If the write timeout or idle timeout are both unset, there is no reason for the + * select/epoll loop to timeout. We thus default the sleep time to zero, + * which never times out + */ + next_sleep.tv_sec = 0; + next_sleep.tv_usec = 0; slapd_add( wake_sds[0], 0, NULL ); @@ -2143,6 +2141,8 @@ #define SLAPD_EBADF_LIMIT 16 time_t now; + time_t tv_idlenextcheck = 0; + time_t tv_writenextcheck = 0; SLAP_EVENT_DECL; @@ -2155,14 +2155,89 @@ now = slap_get_time(); - if ( ( global_idletimeout > 0 ) && - difftime( last_idle_check + - global_idletimeout/SLAPD_IDLE_CHECK_LIMIT, now ) < 0 ) + /* + * Decide whether it's time to call the idle timeout or write timeout code, + * based on the last time we did such a check, plus whether there are any + * filedescriptors which have pending writes + */ + if ( ( global_idletimeout > 0 ) && + difftime( (last_idle_check + + global_idletimeout/SLAPD_IDLE_CHECK_LIMIT), now ) < 0 ) + { + connections_timeout_idle( now ); + last_idle_check = now; + } + + if ( (global_writetimeout > 0) && + difftime( (last_write_timeout_check + + global_writetimeout/SLAPD_WRITE_CHECK_LIMIT), now) < 0 ) { - connections_timeout_idle( now ); - last_idle_check = now; + connections_timeout_write( now ); + last_write_timeout_check = now; + } + + /* + * Now that we've timed out any pending sessions, we need to ascertain when the + * next time we return to this code is. + * + * We calculate this value based on the last run that we did of each type. We then + * calculate the difference in seconds between now and the next scheduled time, and then + * sleep for that amount of time the sleep value into the SLAP_EVENT_WAIT sleep value + * + * We must return based on the smaller value of either the idle-timeout handler's value, or the + * write-timeout value, excluding zero values. + * + */ + if ( global_idletimeout > 0 ) + { + tv_idlenextcheck = last_idle_check + + (global_idletimeout / SLAPD_WRITE_CHECK_LIMIT); + + /* If we missed our last deadline for the idle check, re-schedule it to + * some time in the future + */ + if (tv_idlenextcheck < now) + tv_idlenextcheck = now + + (global_idletimeout / SLAPD_WRITE_CHECK_LIMIT); + + assert (tv_idlenextcheck > 0); + assert (tv_idlenextcheck >= now); + } + if ( global_writetimeout > 0 ) + { + tv_writenextcheck = last_write_timeout_check + + (global_writetimeout / SLAPD_WRITE_CHECK_LIMIT); + + /* If we missed our last deadline for the write check, re-schedule it to + * some time in the future + */ + if (tv_writenextcheck < now) + tv_writenextcheck = now + + (global_writetimeout / SLAPD_WRITE_CHECK_LIMIT); + assert (tv_writenextcheck > 0); + assert (tv_writenextcheck >= now); + } + + if (tv_idlenextcheck && tv_writenextcheck) { + /* Figure out the smaller time, and sleep for that long */ + if (tv_idlenextcheck < tv_writenextcheck) { + tv.tv_sec = (tv_idlenextcheck - now) + 1; + tv.tv_usec = 0; + } else { + tv.tv_sec = (tv_writenextcheck - now) + 1; + tv.tv_usec = 0; + } + } else if (tv_idlenextcheck) { + tv.tv_sec = (tv_idlenextcheck - now) + 1; + tv.tv_usec = 0; + } else if (tv_writenextcheck) { + tv.tv_sec = (tv_writenextcheck - now) + 1; + tv.tv_usec = 0; + } else { + /* Sleep forever */ + tv.tv_sec = 0; + tv.tv_usec = 0; } - tv = idle; #ifdef SIGHUP if ( slapd_gentle_shutdown ) { @@ -2211,7 +2286,7 @@ nfds = SLAP_EVENT_MAX; - if ( global_idletimeout && slap_daemon.sd_nactives ) at = 1; + if ( (global_idletimeout || global_writetimeout) && slap_daemon.sd_nactives ) at = 1; ldap_pvt_thread_mutex_unlock( &slap_daemon.sd_mutex ); diff -urN openldap-2.4.15-plain-source/servers/slapd/proto-slap.h openldap-2.4.15-oskar-connection-patch/servers/slapd/proto-slap.h --- openldap-2.4.15-plain-source/servers/slapd/proto-slap.h 2009-02-17 19:14:41.000000000 +0000 +++ openldap-2.4.15-oskar-connection-patch/servers/slapd/proto-slap.h 2009-03-11 23:11:38.000000000 +0000 @@ -728,6 +728,7 @@ LDAP_SLAPD_F (int) connections_shutdown LDAP_P((void)); LDAP_SLAPD_F (int) connections_destroy LDAP_P((void)); LDAP_SLAPD_F (int) connections_timeout_idle LDAP_P((time_t)); +LDAP_SLAPD_F (int) connections_timeout_write LDAP_P((time_t)); LDAP_SLAPD_F (Connection *) connection_client_setup LDAP_P(( ber_socket_t s, @@ -1930,6 +1931,7 @@ LDAP_SLAPD_V (int) global_gentlehup; LDAP_SLAPD_V (int) global_idletimeout; +LDAP_SLAPD_V (int) global_writetimeout; LDAP_SLAPD_V (char *) global_host; LDAP_SLAPD_V (char *) global_realm; LDAP_SLAPD_V (char *) sasl_host; --Apple-Mail-3-627969786 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hope that helps. Oskar > Setup: > Solaris 10 > Openldap 2.4.16 (64bit) > Berkeley DB 4.7 > > 1 Master > 5 Replicas with deltasyncrepl > > Cores only happened to the master so far, replicas are running > stable so far. > > I couldn't find a reference to this ITS in the 2.4.16 changelog > (probably listed as other ITS or fixed earlier). > Also if the fix made it's way into 2.4.16, I am wondering why we still > observe this cores. > > If you need further information or have any suggestions please let me > know. Please find some debugging information below. > > Kind regards, > David > > (dbx) threads > t@1 a l@1 ?() LWP suspended in __lwp_wait() > t@2 a l@2 slapd_daemon_task() LWP suspended in __pollsys() > t@3 a l@3 ldap_int_thread_pool_wrapper() sleep on > 0x1004dd428 in __lwp_park() > t@4 a l@4 ldap_int_thread_pool_wrapper() LWP suspended in > ___lwp_cond_wait() > t@5 a l@5 ldap_int_thread_pool_wrapper() LWP suspended in > ___lwp_cond_wait() > t@6 a l@6 ldap_int_thread_pool_wrapper() LWP suspended in > ___lwp_cond_wait() > t@7 a l@7 ldap_int_thread_pool_wrapper() sleep on > 0x1004dd670 in __lwp_park() > t@8 a l@8 ldap_int_thread_pool_wrapper() LWP suspended in > ___lwp_cond_wait() > t@9 a l@9 ldap_int_thread_pool_wrapper() sleep on > 0x1004a9908 in __lwp_park() > o t@10 a l@10 ldap_int_thread_pool_wrapper() signal SIGABRT in > __lwp_kill() > t@11 a l@11 ldap_int_thread_pool_wrapper() sleep on > 0x1004a9908 in __lwp_park() > t@12 a l@12 ldap_int_thread_pool_wrapper() LWP suspended in > ___lwp_cond_wait() >> t@13 a l@13 ldap_int_thread_pool_wrapper() LWP suspended in > slap_access_allowed() > t@14 a l@14 ldap_int_thread_pool_wrapper() LWP suspended in > ___lwp_cond_wait() > t@15 a l@15 ldap_int_thread_pool_wrapper() sleep on > 0x1004dd1e0 in __lwp_park() > t@16 a l@16 ldap_int_thread_pool_wrapper() LWP suspended in > ___lwp_cond_wait() > t@17 a l@17 ldap_int_thread_pool_wrapper() sleep on > 0x1004a9908 in __lwp_park() > t@18 a l@18 ldap_int_thread_pool_wrapper() LWP suspended in > __lock_getlocker_int() > (dbx) lwp l@10 > Current function is connection_state_closing > 686 assert( c->c_struct_state == SLAP_C_USED ); > t@10 (l@10) stopped in __lwp_kill at 0xffffffff7decea00 > 0xffffffff7decea00: __lwp_kill+0x0008: bcc,a,pt %icc,__lwp_kill+0x18 > ! 0xffffffff7decea10 > (dbx) where > [1] __lwp_kill(0x0, 0x6, 0x10004b128, 0x19d480, 0x0, 0x0), at > 0xffffffff7decea00 [2] raise(0x6, 0x0, 0x100445d58, > 0xffffffffffffffff, 0xffffffff7dfe6000, 0x0), at 0xffffffff7de6b4f4 > [3] abort(0x1, 0x1b8, 0x10004b128, 0x19d480, 0x0, 0x0), at > 0xffffffff7de48c8c [4] __assert(0x100271f48, 0x100271f70, 0x2ae, 0x0, > 0x19d138, 0x100069f70), at 0xffffffff7de48f30 =>[5] > connection_state_closing(c = 0x1004dce30), line 686 in "connection.c" > [6] send_ldap_ber(op = 0xffffffff733ff768, ber = 0xffffffff733ff028), > line 148 in "result.c" > [7] slap_send_search_entry(op = 0xffffffff733ff768, rs = > 0xffffffff733ff2d0), line 1247 in "result.c" > [8] syncprov_sendresp(op = 0xffffffff733ff768, opc = > 0xffffffff733ff4a0, so = 0x113c0a930, e = 0xffffffff733ff500, mode = > 3), line 848 in "syncprov.c" > [9] syncprov_qplay(op = 0xffffffff733ff768, so = 0x113c0a930), line > 913 in "syncprov.c" > [10] syncprov_qtask(ctx = 0xffffffff733ffc20, arg = 0x113c0a930), > line 971 in "syncprov.c" > [11] ldap_int_thread_pool_wrapper(xpool = 0x10046a250), line 663 in > "tpool.c" > (dbx) list 680,690 > 680 int connection_state_closing( Connection *c ) > 681 { > 682 /* c_mutex must be locked by caller */ > 683 > 684 int state; > 685 assert( c != NULL ); > 686 assert( c->c_struct_state == SLAP_C_USED ); > 687 > 688 state = c->c_conn_state; > 689 > 690 assert( state != SLAP_C_INVALID ); > (dbx) print c > c = 0x1004dce30 > (dbx) print *c > *c = { > c_struct_state = 1 > c_conn_state = 0 > c_conn_idx = 26 > c_sd = -1 > c_close_reason = 0x100271eb0 "?" > c_mutex = { > __pthread_mutex_flags = { > __pthread_mutex_flag1 = 4U > __pthread_mutex_flag2 = '\0' > __pthread_mutex_ceiling = '\0' > __pthread_mutex_type = 0 > __pthread_mutex_magic = 19800U > } > __pthread_mutex_lock = { > __pthread_mutex_lock64 = { > __pthread_mutex_pad = "" > } > __pthread_mutex_lock32 = { > __pthread_ownerpid = 0 > __pthread_lockword = 0 > } > __pthread_mutex_owner64 = 0 > } > __pthread_mutex_data = 0 > } > c_sb = 0x118772d90 > c_starttime = 0 > c_activitytime = 0 > c_connid = 18446744073709551615U > c_peer_domain = { > bv_len = 0 > bv_val = (nil) > } > c_peer_name = { > bv_len = 0 > bv_val = (nil) > } > c_listener = (nil) > c_sasl_bind_mech = { > bv_len = 0 > bv_val = (nil) > } > c_sasl_dn = { > bv_len = 0 > bv_val = (nil) > } > c_sasl_authz_dn = { > bv_len = 0 > bv_val = (nil) > } > c_authz_backend = (nil) > c_authz_cookie = (nil) > c_authz = { > sai_method = 128U > sai_mech = { > bv_len = 0 > bv_val = (nil) > } > sai_dn = { > bv_len = 0 > bv_val = (nil) > } > sai_ndn = { > bv_len = 0 > bv_val = (nil) > } > sai_ssf = 0 > sai_transport_ssf = 0 > sai_tls_ssf = 0 > sai_sasl_ssf = 0 > } > c_protocol = 0 > c_ops = { > stqh_first = (nil) > stqh_last = 0x1004dcf38 > } > c_pending_ops = { > stqh_first = (nil) > stqh_last = 0x1004dcf48 > } > c_write1_mutex = { > __pthread_mutex_flags = { > __pthread_mutex_flag1 = 4U > __pthread_mutex_flag2 = '\0' > __pthread_mutex_ceiling = '\0' > __pthread_mutex_type = 0 > __pthread_mutex_magic = 19800U > } > __pthread_mutex_lock = { > __pthread_mutex_lock64 = { > __pthread_mutex_pad = "" > } > __pthread_mutex_lock32 = { > __pthread_ownerpid = 0 > __pthread_lockword = 4278190080U > } > __pthread_mutex_owner64 = 4278190080U > } > __pthread_mutex_data = 18446744071451976704U > } > c_write1_cv = { > __pthread_cond_flags = { > __pthread_cond_flag = "" > __pthread_cond_type = 0 > __pthread_cond_magic = 17238U > } > __pthread_cond_data = 0 > } > c_write2_mutex = { > __pthread_mutex_flags = { > __pthread_mutex_flag1 = 4U > __pthread_mutex_flag2 = '\0' > __pthread_mutex_ceiling = '\0' > __pthread_mutex_type = 0 > __pthread_mutex_magic = 19800U > } > __pthread_mutex_lock = { > __pthread_mutex_lock64 = { > __pthread_mutex_pad = "" > } > __pthread_mutex_lock32 = { > __pthread_ownerpid = 0 > __pthread_lockword = 0 > } > __pthread_mutex_owner64 = 0 > } > __pthread_mutex_data = 0 > } > c_write2_cv = { > __pthread_cond_flags = { > __pthread_cond_flag = "" > __pthread_cond_type = 0 > __pthread_cond_magic = 17238U > } > __pthread_cond_data = 0 > } > c_currentber = (nil) > c_writers = 0 > c_sasl_bind_in_progress = '\0' > c_writewaiter = '\0' > c_sasl_layers = '\0' > c_sasl_done = '\0' > c_sasl_authctx = (nil) > c_sasl_sockctx = (nil) > c_sasl_extra = (nil) > c_sasl_bindop = (nil) > c_pagedresults_state = { > ps_be = (nil) > ps_size = 0 > ps_count = 0 > ps_cookie = 0 > ps_cookieval = { > bv_len = 0 > bv_val = (nil) > } > } > c_n_ops_received = 3 > c_n_ops_executing = 0 > c_n_ops_pending = 0 > c_n_ops_completed = 3 > c_n_get = 4 > c_n_read = 3 > c_n_write = 1 > c_extensions = (nil) > c_clientfunc = (nil) > c_clientarg = (nil) > c_send_ldap_result = 0x10006b900 = > &slap_send_ldap_result(Operation *op, SlapReply *rs) > c_send_search_entry = 0x10006cda0 = > &slap_send_search_entry(Operation *op, SlapReply *rs) > c_send_search_reference = 0x10006fa80 = > &slap_send_search_reference(Operation *op, SlapReply *rs) > c_send_ldap_extended = 0x10006c5f8 = > &slap_send_ldap_extended(Operation *op, SlapReply *rs) > c_send_ldap_intermediate = 0x10006ca28 = > &slap_send_ldap_intermediate(Operation *op, SlapReply *rs) } --Apple-Mail-3-627969786--

1 0

Re: (ITS#6074) SEGV in pthread_mutex_lock()
by richton＠nbcs.rutgers.edu 28 Apr '09

28 Apr '09

Similar outcome, possibly the same issue, except now I'm looking with libumem, so this should Actually Be A Bad Free (in theory). The default transaction history buffer wasn't big enough to have the block history, unfortunately. I'll play with it some more, and also see if I can reproduce in tests/, over the next week or two... current thread: t@19 [1] __lwp_kill(0x0, 0x6, 0xffffffffffffffe6, 0xffffffff7f212590, 0x2f, 0xffffffff7f3241d0), at 0xffffffff7eea8b8c [2] raise(0x6, 0x0, 0x0, 0xffffffff42e7e158, 0x0, 0xffffffff42e7e7f8), at 0xffffffff7ee58cd0 [3] umem_do_abort(0xb, 0xffffffff7f21f384, 0x25730a00, 0x7efefeff, 0x81010100, 0xff00), at 0xffffffff7f212590 [4] umem_err_recoverable(0xffffffff7f21f378, 0xffffffff7f32a6f8, 0x12179c850, 0xffffffff7f21f358, 0x3a10c000, 0x0), at 0xffffffff7f212834 [5] process_free(0x12179c850, 0x1, 0x0, 0x0, 0x2, 0x0), at 0xffffffff7f2120d4 =>[6] ber_memfree_x(p = 0x12179c850, ctx = (nil)), line 152 in "memory.c" [7] ch_free(ptr = 0x12179c850), line 139 in "ch_malloc.c" [8] hdb_entry_return(e = 0x107e8a888), line 218 in "id2entry.c" [9] hdb_cache_lru_purge(bdb = 0x1009c13d0), line 756 in "cache.c" [10] hdb_cache_find_id(op = 0x1281699d0, tid = 0x12675fe90, id = 12840U, eip = 0xffffffff42e7e848, flag = 0, lock = 0xffffffff42e7e7f8), line 1053 in "cache.c" [11] hdb_search(op = 0x1281699d0, rs = 0xffffffff42fff998), line 706 in "search.c" [12] glue_sub_search(op = 0x1281699d0, rs = 0xffffffff42fff998, b0 = 0xffffffff42ffeda8, on = 0x100700dd0), line 342 in "backglue.c" [13] glue_op_search(op = 0x1281699d0, rs = 0xffffffff42fff998), line 465 in "backglue.c" [14] overlay_op_walk(op = 0x1281699d0, rs = 0xffffffff42fff998, which = op_search, oi = 0x100701010, on = 0x100700dd0), line 659 in "backover.c" [15] over_op_func(op = 0x1281699d0, rs = 0xffffffff42fff998, which = op_search), line 721 in "backover.c" [16] over_op_search(op = 0x1281699d0, rs = 0xffffffff42fff998), line 743 in "backover.c" [17] fe_op_search(op = 0x1281699d0, rs = 0xffffffff42fff998), line 366 in "search.c" [18] overlay_op_walk(op = 0x1281699d0, rs = 0xffffffff42fff998, which = op_search, oi = 0x1007016d0, on = (nil)), line 669 in "backover.c" [19] over_op_func(op = 0x1281699d0, rs = 0xffffffff42fff998, which = op_search), line 721 in "backover.c" [20] over_op_search(op = 0x1281699d0, rs = 0xffffffff42fff998), line 743 in "backover.c" [21] do_search(op = 0x1281699d0, rs = 0xffffffff42fff998), line 217 in "search.c" [22] connection_operation(ctx = 0xffffffff42fffc20, arg_v = 0x1281699d0), line 1097 in "connection.c" [23] connection_read_thread(ctx = 0xffffffff42fffc20, argv = 0xbd), line 1223 in "connection.c" [24] ldap_int_thread_pool_wrapper(xpool = 0x10064b6a0), line 663 in "tpool.c"

1 0

Re: (ITS#6034) Assert failure - connection_state_closing / send_ldap_ber / slap_send_search_entry / syncprov_sendresp
by idangerer＠gmail.com 28 Apr '09

28 Apr '09

Hi there, Already posted this a while ago to openldap-bugs, but havn't got a response yet. As the problem still persist in my environment, I'll give it another try here. We upgraded to openldap 2.4.16 a while ago. Since then we are experiencing relatively frequent core dumps (average uptime is around 2-3 days). Investigating the root cause we came across ITS#6034 which reminded us much of problem we are facing, but should be fixed in 2.4.16. Setup: Solaris 10 Openldap 2.4.16 (64bit) Berkeley DB 4.7 1 Master 5 Replicas with deltasyncrepl Cores only happened to the master so far, replicas are running stable so far. I couldn't find a reference to this ITS in the 2.4.16 changelog (probably listed as other ITS or fixed earlier). Also if the fix made it's way into 2.4.16, I am wondering why we still observe this cores. If you need further information or have any suggestions please let me know. Please find some debugging information below. Kind regards, David (dbx) threads t@1 a l@1 ?() LWP suspended in __lwp_wait() t@2 a l@2 slapd_daemon_task() LWP suspended in __pollsys() t@3 a l@3 ldap_int_thread_pool_wrapper() sleep on 0x1004dd428 in __lwp_park() t@4 a l@4 ldap_int_thread_pool_wrapper() LWP suspended in ___lwp_cond_wait() t@5 a l@5 ldap_int_thread_pool_wrapper() LWP suspended in ___lwp_cond_wait() t@6 a l@6 ldap_int_thread_pool_wrapper() LWP suspended in ___lwp_cond_wait() t@7 a l@7 ldap_int_thread_pool_wrapper() sleep on 0x1004dd670 in __lwp_park() t@8 a l@8 ldap_int_thread_pool_wrapper() LWP suspended in ___lwp_cond_wait() t@9 a l@9 ldap_int_thread_pool_wrapper() sleep on 0x1004a9908 in __lwp_park() o t@10 a l@10 ldap_int_thread_pool_wrapper() signal SIGABRT in __lwp_kill() t@11 a l@11 ldap_int_thread_pool_wrapper() sleep on 0x1004a9908 in __lwp_park() t@12 a l@12 ldap_int_thread_pool_wrapper() LWP suspended in ___lwp_cond_wait() > t@13 a l@13 ldap_int_thread_pool_wrapper() LWP suspended in slap_access_allowed() t@14 a l@14 ldap_int_thread_pool_wrapper() LWP suspended in ___lwp_cond_wait() t@15 a l@15 ldap_int_thread_pool_wrapper() sleep on 0x1004dd1e0 in __lwp_park() t@16 a l@16 ldap_int_thread_pool_wrapper() LWP suspended in ___lwp_cond_wait() t@17 a l@17 ldap_int_thread_pool_wrapper() sleep on 0x1004a9908 in __lwp_park() t@18 a l@18 ldap_int_thread_pool_wrapper() LWP suspended in __lock_getlocker_int() (dbx) lwp l@10 Current function is connection_state_closing 686 assert( c->c_struct_state == SLAP_C_USED ); t@10 (l@10) stopped in __lwp_kill at 0xffffffff7decea00 0xffffffff7decea00: __lwp_kill+0x0008: bcc,a,pt %icc,__lwp_kill+0x18 ! 0xffffffff7decea10 (dbx) where [1] __lwp_kill(0x0, 0x6, 0x10004b128, 0x19d480, 0x0, 0x0), at 0xffffffff7decea00 [2] raise(0x6, 0x0, 0x100445d58, 0xffffffffffffffff, 0xffffffff7dfe6000, 0x0), at 0xffffffff7de6b4f4 [3] abort(0x1, 0x1b8, 0x10004b128, 0x19d480, 0x0, 0x0), at 0xffffffff7de48c8c [4] __assert(0x100271f48, 0x100271f70, 0x2ae, 0x0, 0x19d138, 0x100069f70), at 0xffffffff7de48f30 =>[5] connection_state_closing(c = 0x1004dce30), line 686 in "connection.c" [6] send_ldap_ber(op = 0xffffffff733ff768, ber = 0xffffffff733ff028), line 148 in "result.c" [7] slap_send_search_entry(op = 0xffffffff733ff768, rs = 0xffffffff733ff2d0), line 1247 in "result.c" [8] syncprov_sendresp(op = 0xffffffff733ff768, opc = 0xffffffff733ff4a0, so = 0x113c0a930, e = 0xffffffff733ff500, mode = 3), line 848 in "syncprov.c" [9] syncprov_qplay(op = 0xffffffff733ff768, so = 0x113c0a930), line 913 in "syncprov.c" [10] syncprov_qtask(ctx = 0xffffffff733ffc20, arg = 0x113c0a930), line 971 in "syncprov.c" [11] ldap_int_thread_pool_wrapper(xpool = 0x10046a250), line 663 in "tpool.c" (dbx) list 680,690 680 int connection_state_closing( Connection *c ) 681 { 682 /* c_mutex must be locked by caller */ 683 684 int state; 685 assert( c != NULL ); 686 assert( c->c_struct_state == SLAP_C_USED ); 687 688 state = c->c_conn_state; 689 690 assert( state != SLAP_C_INVALID ); (dbx) print c c = 0x1004dce30 (dbx) print *c *c = { c_struct_state = 1 c_conn_state = 0 c_conn_idx = 26 c_sd = -1 c_close_reason = 0x100271eb0 "?" c_mutex = { __pthread_mutex_flags = { __pthread_mutex_flag1 = 4U __pthread_mutex_flag2 = '\0' __pthread_mutex_ceiling = '\0' __pthread_mutex_type = 0 __pthread_mutex_magic = 19800U } __pthread_mutex_lock = { __pthread_mutex_lock64 = { __pthread_mutex_pad = "" } __pthread_mutex_lock32 = { __pthread_ownerpid = 0 __pthread_lockword = 0 } __pthread_mutex_owner64 = 0 } __pthread_mutex_data = 0 } c_sb = 0x118772d90 c_starttime = 0 c_activitytime = 0 c_connid = 18446744073709551615U c_peer_domain = { bv_len = 0 bv_val = (nil) } c_peer_name = { bv_len = 0 bv_val = (nil) } c_listener = (nil) c_sasl_bind_mech = { bv_len = 0 bv_val = (nil) } c_sasl_dn = { bv_len = 0 bv_val = (nil) } c_sasl_authz_dn = { bv_len = 0 bv_val = (nil) } c_authz_backend = (nil) c_authz_cookie = (nil) c_authz = { sai_method = 128U sai_mech = { bv_len = 0 bv_val = (nil) } sai_dn = { bv_len = 0 bv_val = (nil) } sai_ndn = { bv_len = 0 bv_val = (nil) } sai_ssf = 0 sai_transport_ssf = 0 sai_tls_ssf = 0 sai_sasl_ssf = 0 } c_protocol = 0 c_ops = { stqh_first = (nil) stqh_last = 0x1004dcf38 } c_pending_ops = { stqh_first = (nil) stqh_last = 0x1004dcf48 } c_write1_mutex = { __pthread_mutex_flags = { __pthread_mutex_flag1 = 4U __pthread_mutex_flag2 = '\0' __pthread_mutex_ceiling = '\0' __pthread_mutex_type = 0 __pthread_mutex_magic = 19800U } __pthread_mutex_lock = { __pthread_mutex_lock64 = { __pthread_mutex_pad = "" } __pthread_mutex_lock32 = { __pthread_ownerpid = 0 __pthread_lockword = 4278190080U } __pthread_mutex_owner64 = 4278190080U } __pthread_mutex_data = 18446744071451976704U } c_write1_cv = { __pthread_cond_flags = { __pthread_cond_flag = "" __pthread_cond_type = 0 __pthread_cond_magic = 17238U } __pthread_cond_data = 0 } c_write2_mutex = { __pthread_mutex_flags = { __pthread_mutex_flag1 = 4U __pthread_mutex_flag2 = '\0' __pthread_mutex_ceiling = '\0' __pthread_mutex_type = 0 __pthread_mutex_magic = 19800U } __pthread_mutex_lock = { __pthread_mutex_lock64 = { __pthread_mutex_pad = "" } __pthread_mutex_lock32 = { __pthread_ownerpid = 0 __pthread_lockword = 0 } __pthread_mutex_owner64 = 0 } __pthread_mutex_data = 0 } c_write2_cv = { __pthread_cond_flags = { __pthread_cond_flag = "" __pthread_cond_type = 0 __pthread_cond_magic = 17238U } __pthread_cond_data = 0 } c_currentber = (nil) c_writers = 0 c_sasl_bind_in_progress = '\0' c_writewaiter = '\0' c_sasl_layers = '\0' c_sasl_done = '\0' c_sasl_authctx = (nil) c_sasl_sockctx = (nil) c_sasl_extra = (nil) c_sasl_bindop = (nil) c_pagedresults_state = { ps_be = (nil) ps_size = 0 ps_count = 0 ps_cookie = 0 ps_cookieval = { bv_len = 0 bv_val = (nil) } } c_n_ops_received = 3 c_n_ops_executing = 0 c_n_ops_pending = 0 c_n_ops_completed = 3 c_n_get = 4 c_n_read = 3 c_n_write = 1 c_extensions = (nil) c_clientfunc = (nil) c_clientarg = (nil) c_send_ldap_result = 0x10006b900 = &slap_send_ldap_result(Operation *op, SlapReply *rs) c_send_search_entry = 0x10006cda0 = &slap_send_search_entry(Operation *op, SlapReply *rs) c_send_search_reference = 0x10006fa80 = &slap_send_search_reference(Operation *op, SlapReply *rs) c_send_ldap_extended = 0x10006c5f8 = &slap_send_ldap_extended(Operation *op, SlapReply *rs) c_send_ldap_intermediate = 0x10006ca28 = &slap_send_ldap_intermediate(Operation *op, SlapReply *rs) }

1 0

ITS#5860 slapd in openldap-2.4.16 still doesn't respect memory bounds
by sscdvp＠gmail.com 28 Apr '09

28 Apr '09

I have tried openldap-2.4.16 (latest) BDB 4.7.25 with all patches from Oracle on Dell AMD64 RAM 4Gb, 8 CPUs, OS Solaris 10. According to ITS#5860 slapd should not allocate more memory than it was specified. In fact I have the same behaviour as it was with previous version (2.4.11). It correctly allocates 1.2 Gb via shared memory (for set_cachesize 300 MB). But slapd process continuosly grows in memory until 32-bit limit then crashes due to unavalable memory resources. I need to mention bdb database size is less then 1 GB. After restart it rapidly consumes 1.5 GB RSS in few minutes and then it grows beyond the limit during 24 hours. The more queries are processing the more memory it eats. I am using this database for logging which size grows. The question is: is it possible to use 32-bit openldap with relatively large database sizes that override 32-bit per-process memory space? My slapd.conf contains: threads 64 concurrency 50 cachesize 200000 dncachesize 400000 idlcachesize 600000 shm_key 10 DB_CONFIG: set_cachesize 0 300097152 1 set_lk_max_locks 1000000 set_lk_max_lockers 1000000 set_lk_max_objects 1000000 set_lg_regionmax 1048576 set_lg_max 10485760 set_lg_bsize 2097152 ls -ls ./openldap-data total 1212876 -rw-r--r-- 1 slapd nobody 640 Apr 17 08:42 DB_CONFIG -rw------- 1 slapd nobody 8 Apr 16 10:50 __db.001 -rw-r--r-- 1 slapd nobody 4096 Apr 16 10:50 alock -rw------- 1 slapd nobody 6053888 Apr 17 09:50 cn.bdb -rw------- 1 slapd nobody 1024000 Apr 17 09:50 dhcpHWAddress.bdb -rw------- 1 slapd nobody 96583680 Apr 17 09:50 dn2id.bdb -rw------- 1 slapd nobody 515637248 Apr 17 09:50 id2entry.bdb -rw------- 1 slapd nobody 1343488 Apr 17 09:50 objectClass.bdb Any help would be much appreciated. Regards, Sergey.

3 3

(ITS#6079) TLS error strings need to be printf() safe
by richton＠nbcs.rutgers.edu 27 Apr '09

27 Apr '09

Full_Name: Aaron Richton Version: 2.4.16 OS: Solaris 9 URL: Submission from: (NULL) (128.6.31.135) Personally I focus on OpenSSL, where ERR_error_string is permitted to return NULL, so we can't Debug() them arbitrarily. This is handled in _connect: 390 Debug( LDAP_DEBUG_ANY,"TLS: can't connect: %s.\n", 391 ld->ld_error ? ld->ld_error : "" ,0,0); but not in _accept: 440 Debug( LDAP_DEBUG_ANY,"TLS: can't accept: %s.\n", 441 tls_imp->ti_session_errmsg( err, buf, sizeof(buf) ),0,0 ); and at least some rc's don't have error strings, so it's all too easy to: t@14 (l@14) signal SEGV (no mapping at the fault address) in strlen at 0xffffffff7ee3d50c 0xffffffff7ee3d50c: strlen+0x007c: ld [%o1], %o2 Current function is ldap_log_printf current thread: t@14 [1] strlen(0x0, 0x0, 0xffffffff46bff1d0, 0x7efefeff, 0x81010100, 0x107a59610), at 0xffffffff7ee3d50c [2] _doprnt(0xffffffff7ea78960, 0xffffffff46bff1d0, 0xffffffff46bff1d0, 0x0, 0x73, 0x0), at 0xffffffff7ee90f50 [3] vsnprintf(0xffffffff46bff31c, 0x3ff, 0xffffffff7ea78960, 0xffffffff46bff7d8, 0x0, 0xffffffff79a23e48), at 0xffffffff7ee9310c =>[4] ldap_log_printf(ld = (nil), loglvl = -1, fmt = 0xffffffff7ea78960 "TLS: can't accept: %s.\n", ... = (nil), ...), line 56 in "print.c" [5] ldap_pvt_tls_accept(sb = 0x11d459e90, ctx_arg = 0x100a6c610), line 441 in "tls2.c" [6] connection_read(s = 215, cri = 0xffffffff46bffaf8), line 1317 in "connection.c" [7] connection_read_thread(ctx = 0xffffffff46bffc20, argv = 0xd7), line 1216 in "connection.c" [8] ldap_int_thread_pool_wrapper(xpool = 0x10064f6a0), line 663 in "tpool.c" I don't know if you want to do a similar tls_imp->() ? tls_imp->() : "" (it'd work but it looks ugly) or make this the job of *_session_errmsg so I didn't write a patch for this...sorry. Actually, come to think of it, there is: 407 return NULL; in tlso_session_errmsg, that would be dangerous too. NULL might also be returned in tls_m. I don't know is gnutls_strerror is safe or not...

1 0

(ITS#6078) Slapd.exe crashes when writing entries while reading many entries.
by Frank.Offermanns＠caseris.de 27 Apr '09

27 Apr '09

Full_Name: Frank Offermanns Version: 2.4.16 OS: Windows XP URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (217.6.189.242) Hello, i am using OpenLDAP 2.4.16 with Windows XP, compiled with msys/mingw with Windows XP and the berkeley DB 4.7.25 NC The database runs without any replication (though with replication it also crashes) I use the "hdb" Backend. I started the datatbase with "slapd -F slapd.d". Now i add about 21000 Entries under the DN: o=test6,ou=Users,o=caesar. When this is finished i start adding another 21000 Entries under the DN: o=test7,ou=Users,o=caesar. While adding these seconds entries i use the LDAPAdmin 1.1.0.0 to view the subtree at "o=test6,ou=Users,o=caesar". LDAPAdmin starts to read the Users and fails at about the 4000 Entry. At this time my slapd.exe crashed. I also did the test with "slapd -d 1 -F slapd.d" and found the following entries in the logfile: ber_flush2: 77 bytes to sd 2268 ber_get_next: tag 0x30 len 93 contents: <= send_search_entry: conn 0 exit. ber_get_next conn=2 op=4017 do_modify entry_decode: "" ber_scanf fmt ({m) ber: ber_scanf fmt ({e{m[W]}}) ber: <= entry_decode() >>> dnPrettyNormal: <cn=10250,o=test7,ou=users,o=caesar> <<< dnPrettyNormal: <cn=10250,o=test7,ou=users,o=caesar>, <cn=10250,o=test7,ou=users,o=caesar> bdb_dn2entry("cn=10250,o=test7,ou=users,o=caesar") => send_search_entry: conn 0 dn="cn=12034,o=test6,ou=Users,o=caesar" => hdb_dn2id("cn=10250,o=test7,ou=users,o=caesar") ber_flush2: 77 bytes to sd 2268 <= hdb_dn2id: got id=0x53da <= send_search_entry: conn 0 exit. entry_decode: "" entry_decode: "" <= entry_decode() <= entry_decode() bdb_dn2entry("cn=10250,o=test7,ou=users,o=caesar") => send_search_entry: conn 0 dn="cn=12035,o=test6,ou=Users,o=caesar" ber_flush2: 77 bytes to sd 2268 entry_decode: "" <= entry_decode() <= send_search_entry: conn 0 exit. bdb_modify_internal: 0x000053da: c²0250 entry_decode: "" <= entry_decode() entry failed schema check: unrecongized attribute type(s) in RDN hdb_modify: modify failed (34) send_ldap_result: conn=2 op=4017 p=3 send_ldap_response: msgid=1026718 tag=103 err=34 => send_search_entry: conn 0 dn="cn=12036,o=test6,ou=Users,o=caesar" ber_flush2: 53 bytes to sd 2336 ber_flush2: 77 bytes to sd 2268 <= send_search_entry: conn 0 exit. entry_decode: "" <= entry_decode() connection_get(4): got connid=2 connection_read(4): checking for input on id=2 ber_get_next ber_get_next: tag 0x30 len 87 contents: ber_get_next conn=2 op=4018 do_modify ber_scanf fmt ({m) ber: ber_scanf fmt ({e{m[W]}}) ber: >>> dnPrettyNormal: <cn=10250,o=test7,ou=users,o=caesar> <<< dnPrettyNormal: <cn=10250,o=test7,ou=users,o=caesar>, <cn=10250,o=test7,ou=users,o=caesar> bdb_dn2entry("cn=10250,o=test7,ou=users,o=caesar") => hdb_dn2id("cn=10250,o=test7,ou=users,o=caesar") <= hdb_dn2id: got id=0x53da entry_decode: "" <= entry_decode() The pointer at "bdb_modify_internal" seems to be dangling. When i didn't read the entries while writing, there seems to be no problem. The Version 2.4.13 also does not seem to have this problem. (I couldn't get the 2.4.13 Version crashing and the 2.4.16 crashes every time after a short time) Additional Info: I am not sure, if this could be a reason for this error, so i am writing this problem also. Starting at Version 2.4.14 the configure command creates makefiles which are not linkable at mingw/msys at windows. I manually added "-lws2_32" in the makefiles at the lines: AC_LIBS = -lregex -lws2_32 I apologize me for my bad english and hope you can understand me. Regards, Frank Offermanns

1 0

Re: (ITS#6077) Spurious uniqueness errors with filters in unique overlays
by andres＠anarazel.de 25 Apr '09

25 Apr '09

This is a multi-part message in MIME format. --------------080405020304060402030808 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Fixing this for unique_add seams easy enough (see preliminary attached patch) - fixing it for modrdn/modify seems to be another difficulty level as in order to properly apply the filter I think the full modifications have to be applied... If wanted I can produce a patch for this as well, but I would like to know if that is appreciated and if my plan for fixing looks sensible: - Pull the "modification simulation" code out of constraint.c (line 959:1040 and some more in 2.4.16) into constraints.c - Add a overlay-int.h - Make constraint.c and unique.c use that As I dont really know the openldap codebase my analysis could be completely wrong - I would appreciate some feedback. Andres --------------080405020304060402030808 Content-Type: text/x-diff; name="slapd-unique-overlay-spurious-failure-fix-add.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="slapd-unique-overlay-spurious-failure-fix-add.patch" --- openldap-2.4.16.saved/servers/slapd/overlays/unique.c 2009-04-23 23:51:37.925387747 +0200 +++ openldap-2.4.16/servers/slapd/overlays/unique.c 2009-04-26 01:58:54.566927667 +0200 @@ -1071,6 +1071,24 @@ && !dnIsSuffix( &op->o_req_ndn, &uri->ndn )) continue; + if (uri->filter.bv_val && uri->filter.bv_len){ + Filter *f = str2filter_x(op, + uri->filter.bv_val); + if(f == NULL) { + op->o_bd->bd_info = (BackendInfo *) on->on_info; + send_ldap_error(op, rs, LDAP_OTHER, + "unique_search invalid filter"); + return(rs->sr_err); + } + + if(test_filter(NULL, op->ora_e, f) == LDAP_COMPARE_FALSE){ + Debug(LDAP_DEBUG_TRACE, "==> unique_add_skip<%s>\n", + op->o_req_dn.bv_val, 0, 0); + continue; + } + filter_free_x(op, f, 1); + } + if(!(a = op->ora_e->e_attrs)) { op->o_bd->bd_info = (BackendInfo *) on->on_info; send_ldap_error(op, rs, LDAP_INVALID_SYNTAX, --------------080405020304060402030808--

1 0

Re: (ITS#6076) slapo-collect: slapd repeatable segfaults caused by deletion of a single olcCollectInfo config value (when olcCollectInfo contains multiple configuration values)
by daniel＠pluta.biz 25 Apr '09

25 Apr '09

Hallvard B Furuseth schrieb: > Yes, the on-th-fly sorting combined with the delete-single-value > code seems broken. I'm not sure if delete-single-value could ever > be invoked Of course could it be "invoked" before: just use slapd 2.4.16 together with slapo-collect and your favorit ldapmodify client. Right after the "invocation" you'll get an error message complaining about a missing equality rule. Thus there's no hint within collect's source that the single-value delete is faulty I inserted an equality rule and began to wonder... > before you inserted an EQUALITY matching rule though. Do you mean the single-value-delete functionality has been silently "disabled" by removing the EQUALITY matching rule leaving slapo-collect's by design defective single-value-delete code block knowingly unchanged/uncommented? This seems very strange to me even more because slapo-collect is advertises as demonstration overlay (ok, a "quick hacked" one but nevertheless questionable). > I too don't know cn=config all that well:-( <speculation> Instead of correcting handling this issue only in collect.c there perhabs exists a more general possibility to pimp the cn=config internal add mechanisms regarding the handling of ordered config values? In my opinion a very important feature concerning "overlapping"... Á la: cfg_value_add(.., .., SLAPD_CFG_VALSORT_ALPHA|SLAPD_CFG_VALSORT_DN|..) only problem seems to be how to sort a configuration value like: '"ou=test,dc=foo,dc=bar" l,st' by DN's depth </speculation>

1 0

(ITS#5535) smbk5pwd uses private heimdal functions
by admin＠dmarkey.com 24 Apr '09

24 Apr '09

--000e0cd1e8fc2040e9046856eee5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Please review http://dmarkey.com/~dmarkey/smbk5pwd.patch to fix this. Against 2.4.16 smbk5pwd. --000e0cd1e8fc2040e9046856eee5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Please review <a href="http://dmarkey.com/~dmarkey/smbk5pwd.patch">http://dmarkey.com/~dmarkey/smbk5pwd.patch</a> to fix this.<br><br>Against 2.4.16 smbk5pwd.<br><br><br> --000e0cd1e8fc2040e9046856eee5--

1 0

(ITS#6077) Spurious uniqueness errors with filters in unique overlays
by andres＠anarazel.de 24 Apr '09

24 Apr '09

Full_Name: Andres Freund Version: 2.4.16 OS: Linux URL: Submission from: (NULL) (85.178.193.10) If I read the code correctly the unique overlay does not check if the current operation matches the filter of a domain before doing a uniqeness check. This leads to wrongly reported errors. I noticed this after adding a uniqueness constraint on gidNumber on all posixGroup objects (i.e. ldap:///?gidNumber?sub?(objectClass=posixGroup)) - it was not possible anymore to add posixAccounts with that gidNumber. Thanks, Andres Here a modification of the testscript to reproduce the issue: --- openldap-2.4.16.saved/tests/scripts/test024-unique 2009-04-23 23:51:37.942051631 +0200 +++ openldap-2.4.16/tests/scripts/test024-unique 2009-04-25 02:50:40.975257488 +0200 @@ -425,6 +425,7 @@ changetype: modify add: olcUniqueURI olcUniqueURI: ldap:///?sn?sub?(cn=e*) +olcUniqueURI: ldap:///?uid?sub?(cn=edgar) - delete: olcUniqueURI olcUniqueURI: ldap:///?description?one @@ -445,6 +446,7 @@ olcOverlay: {0}unique olcUniqueURI: ldap:///?employeeNumber,displayName?sub olcUniqueURI: ldap:///?sn?sub?(cn=e*) +olcUniqueURI: ldap:///?uid?sub?(cn=edgar) EOF diff $TESTDIR/third-config.ldif $TESTDIR/third-reference.ldif > /dev/null 2>&1 @@ -473,6 +475,27 @@ exit -1 fi + +echo "Adding a record unique in all domains because of filter conditions " + +$LDAPADD -D "$UNIQUEDN" -h $LOCALHOST -p $PORT1 -w $PASSWD > \ + $TESTOUT 2>&1 << EOF +dn: uid=empty,ou=users,o=unique +objectClass: inetOrgPerson +uid: edgar +cn: empty +sn: empty +EOF + +RC=$? +if test $RC != 0 ; then + echo "spurious unique error ($RC)!" + test $KILLSERVERS != no && kill -HUP $KILLPIDS + exit -1 +fi + + + echo "Adding a record unique in one domain, non-unique in the filtered domain..." $LDAPADD -D "$UNIQUEDN" -h $LOCALHOST -p $PORT1 -w $PASSWD > \

1 0

Re: (ITS#6076) slapo-collect: slapd repeatable segfaults caused by deletion of a single olcCollectInfo config value (when olcCollectInfo contains multiple configuration values)
by h.b.furuseth＠usit.uio.no 24 Apr '09

24 Apr '09

Yes, the on-th-fly sorting combined with the delete-single-value code seems broken. I'm not sure if delete-single-value could ever be invoked before you inserted an EQUALITY matching rule though. I too don't know cn=config all that well:-( -- Hallvard

1 0

Re: (ITS#6072) slapo-collect: dnLength != dnDepth
by h.b.furuseth＠usit.uio.no 24 Apr '09

24 Apr '09

oops, lost a few words: I wrote: > I'll fix that and a few other comments and close this ITS, > since you've clarified issue here in ITS#6076. Since you've clarified _the other_ issue here in ITS#6076. -- Hallvard

1 0

Re: (ITS#6072) slapo-collect: dnLength != dnDepth
by h.b.furuseth＠usit.uio.no 24 Apr '09

24 Apr '09

Daniel Pluta writes: > cite: "... this means longer dn's (i.e. more specific dn's) will be > found first when searching..." > > But, longer DNs do not neccessarily are more specific: > > ou=openldap,o=rockz,c=it > dc=abcdefghijklmnopqrstuvwxyz,dc=com (even longer but not more specific) It's just the comment which is unclear. It should be saying that sorting normalized DNs by reverse length ensures that a DN is stored after any of its subordinate DNs. I'll fix that and a few other comments and close this ITS, since you've clarified issue here in ITS#6076. -- Hallvard

1 0

(ITS#6076)
by Daniel.Pluta＠lrz.de 24 Apr '09

24 Apr '09

sorry, there's a small cut&paste error regarding step 12.) Please ignore the first 4 lines. Only the last two lines contain the corresponding output regarding step 11.) Thanks!

1 0

(ITS#6076) slapo-collect: slapd repeatable segfaults caused by deletion of a single olcCollectInfo config value (when olcCollectInfo contains multiple configuration values)
by daniel＠pluta.biz 24 Apr '09

24 Apr '09

Full_Name: Daniel Pluta Version: OPENLDAP_STABLE OS: Linux URL: ftp://ftp.openldap.org/incoming/daniel-pluta-090424.patch Submission from: (NULL) (2001:4ca0:0:f000:ecb9:edd3:5b88:63f0) As already assumed in (ITS6072 FollowUp 5) there seems to be a bug regarding the mapping of c->valx and the to-be-deleted value of the ci->ci_next list. The origin seems to be the on-the-fly manipulation (sorting) of the ci-list that is done by insert_ordered()) whenever a new config value is added... To illustrate the problem in detail I've added some debugging output into collect.c's LDAP_MOD_DELETE-section: case LDAP_MOD_DELETE: if ( c->valx == -1 ) { /* Delete entire attribute */ collect_info *ci; while (( ci = on->on_bi.bi_private )) { on->on_bi.bi_private = ci->ci_next; ch_free( ci->ci_dn.bv_val ); ch_free( ci ); } } else { /* Delete just one value */ collect_info **cip, *ci; int i; cip = (collect_info **)&on->on_bi.bi_private; Debug(LDAP_DEBUG_TRACE, "collect_cf: LDAP_MOD_DELETE: c->valx=%d\n", c->valx, 0, 0); for ( i=0; i <= c->valx; i++, cip = &ci->ci_next ) { ci = *cip; Debug(LDAP_DEBUG_TRACE, "collect_cf: LDAP_MOD_DELETE: i=%d <--> dn=%s\n", i, ci->ci_dn.bv_val, 0); } *cip = ci->ci_next; Debug(LDAP_DEBUG_TRACE, "collect_cf: free: dn=%s\n", ci->ci_dn.bv_val, 0, 0); ch_free( ci->ci_dn.bv_val ); ch_free( ci ); } The patch against OPENLDAP_STABLE could be downloaded from here: ftp://ftp.openldap.org/incoming/daniel-pluta-090424.patch This patch also includes the mini-enhancement proposed in ITS6072 and the micro-bugfix provided in ITS6075. ITS6075 solves a small schema-specific bug which wrongly denied deletion of single olcCollectInfo configuration values at all. Here are my 12 steps to reproduce the crash... 1.) edit collect's configuration setup in slapd.conf by adding the following lines: overlay collect collectinfo ou=customer_A,dc=foo,dc=bar l,st collectinfo ou=customer_B,dc=foo,dc=bar l,st collectinfo ou=customer_C,dc=foo,dc=bar l,st collectinfo ou=customer_D,dc=foo,dc=bar l,st collectinfo ou=customer_E,dc=foo,dc=bar l,st collectinfo ou=customer_F,dc=foo,dc=bar l,st collectinfo ou=users,ou=customer_A,dc=foo,dc=bar l,st collectinfo ou=users,ou=customer_B,dc=foo,dc=bar l,st collectinfo ou=users,ou=customer_C,dc=foo,dc=bar l,st collectinfo ou=users,ou=customer_D,dc=foo,dc=bar l,st collectinfo ou=users,ou=customer_E,dc=foo,dc=bar l,st collectinfo ou=users,ou=customer_F,dc=foo,dc=bar l,st 2.) convert ".conf" into "cn=config" format, by running: slaptest -f ... -F ... The resulting collect cn=config ldif should be similar to: dn: olcOverlay={0}collect objectClass: olcOverlayConfig objectClass: olcCollectConfig olcOverlay: {0}collect olcCollectInfo: "ou=users,ou=customer_f,dc=foo,dc=bar" l,st olcCollectInfo: "ou=users,ou=customer_e,dc=foo,dc=bar" l,st olcCollectInfo: "ou=users,ou=customer_d,dc=foo,dc=bar" l,st olcCollectInfo: "ou=users,ou=customer_c,dc=foo,dc=bar" l,st olcCollectInfo: "ou=users,ou=customer_b,dc=foo,dc=bar" l,st olcCollectInfo: "ou=users,ou=customer_a,dc=foo,dc=bar" l,st olcCollectInfo: "ou=customer_f,dc=foo,dc=bar" l,st olcCollectInfo: "ou=customer_e,dc=foo,dc=bar" l,st olcCollectInfo: "ou=customer_d,dc=foo,dc=bar" l,st olcCollectInfo: "ou=customer_c,dc=foo,dc=bar" l,st olcCollectInfo: "ou=customer_b,dc=foo,dc=bar" l,st olcCollectInfo: "ou=customer_a,dc=foo,dc=bar" l,st structuralObjectClass: olcCollectConfig entryUUID: 51c7d5fa-c50a-102d-9657-f3a43e5eeda2 creatorsName: cn=config createTimestamp: 20090424105633Z entryCSN: 20090424105633.913345Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20090424105633Z 3.) start slapd using the generated config (slapd -F ...) 4.) start browsing cn=config everything is fine 5.) delete the follwing olcCollectInfo Value using this ldif: dn: olcOverlay={0}collect,olcDatabase={2}bdb,cn=config changetype: modify delete: olcCollectInfo olcCollectInfo: "ou=customer_a,dc=foo,dc=bar" l,st - 6.) examine the log based on the above patch (which delivers the following debugging output) collect_cf: LDAP_MOD_DELETE: c->valx=11 collect_cf: LDAP_MOD_DELETE: i=0 <--> dn=ou=users,ou=customer_a,dc=foo,dc=bar collect_cf: LDAP_MOD_DELETE: i=1 <--> dn=ou=users,ou=customer_b,dc=foo,dc=bar collect_cf: LDAP_MOD_DELETE: i=2 <--> dn=ou=users,ou=customer_c,dc=foo,dc=bar collect_cf: LDAP_MOD_DELETE: i=3 <--> dn=ou=users,ou=customer_d,dc=foo,dc=bar collect_cf: LDAP_MOD_DELETE: i=4 <--> dn=ou=users,ou=customer_e,dc=foo,dc=bar collect_cf: LDAP_MOD_DELETE: i=5 <--> dn=ou=users,ou=customer_f,dc=foo,dc=bar collect_cf: LDAP_MOD_DELETE: i=6 <--> dn=ou=customer_a,dc=foo,dc=bar collect_cf: LDAP_MOD_DELETE: i=7 <--> dn=ou=customer_b,dc=foo,dc=bar collect_cf: LDAP_MOD_DELETE: i=8 <--> dn=ou=customer_c,dc=foo,dc=bar collect_cf: LDAP_MOD_DELETE: i=9 <--> dn=ou=customer_d,dc=foo,dc=bar collect_cf: LDAP_MOD_DELETE: i=10 <--> dn=ou=customer_e,dc=foo,dc=bar collect_cf: LDAP_MOD_DELETE: i=11 <--> dn=ou=customer_f,dc=foo,dc=bar collect_cf: free: dn=ou=customer_f,dc=foo,dc=bar ==> Holy sh..! ou=customer_f,dc=foo,dc=bar has been deleted, instead?!?!?! 7.) Though slapd still runs, lets ask about some more details using ldapsearch: dn: olcoverlay={0}collect,olcdatabase={2}bdb,cn=config objectClass: olcOverlayConfig objectClass: olcCollectConfig olcCollectInfo: "ou=users,ou=customer_f,dc=foo,dc=bar" l,st olcCollectInfo: "ou=users,ou=customer_e,dc=foo,dc=bar" l,st olcCollectInfo: "ou=users,ou=customer_d,dc=foo,dc=bar" l,st olcCollectInfo: "ou=users,ou=customer_c,dc=foo,dc=bar" l,st olcCollectInfo: "ou=users,ou=customer_b,dc=foo,dc=bar" l,st olcCollectInfo: "ou=users,ou=customer_a,dc=foo,dc=bar" l,st olcCollectInfo: "ou=customer_f,dc=foo,dc=bar" l,st olcCollectInfo: "ou=customer_e,dc=foo,dc=bar" l,st olcCollectInfo: "ou=customer_d,dc=foo,dc=bar" l,st olcCollectInfo: "ou=customer_c,dc=foo,dc=bar" l,st olcCollectInfo: "ou=customer_b,dc=foo,dc=bar" l,st olcOverlay: {0}collect ==> Impressive! It seems to be that ou=customer_a,dc=foo,dc=bar has been deleted(?!?!) 8.) ok, once again we try to delete a value: dn: olcOverlay={0}collect,olcDatabase={2}bdb,cn=config changetype: modify delete: olcCollectInfo olcCollectInfo: "ou=customer_e,dc=foo,dc=bar" l,st - 9.) but the logging output tells us: "customer_b" gets deleted now... collect_cf: LDAP_MOD_DELETE: c->valx=7 collect_cf: LDAP_MOD_DELETE: i=0 <--> dn=ou=users,ou=customer_a,dc=foo,dc=bar collect_cf: LDAP_MOD_DELETE: i=1 <--> dn=ou=users,ou=customer_b,dc=foo,dc=bar collect_cf: LDAP_MOD_DELETE: i=2 <--> dn=ou=users,ou=customer_c,dc=foo,dc=bar collect_cf: LDAP_MOD_DELETE: i=3 <--> dn=ou=users,ou=customer_d,dc=foo,dc=bar collect_cf: LDAP_MOD_DELETE: i=4 <--> dn=ou=users,ou=customer_e,dc=foo,dc=bar collect_cf: LDAP_MOD_DELETE: i=5 <--> dn=ou=users,ou=customer_f,dc=foo,dc=bar collect_cf: LDAP_MOD_DELETE: i=6 <--> dn=ou=customer_a,dc=foo,dc=bar collect_cf: LDAP_MOD_DELETE: i=7 <--> dn=ou=customer_b,dc=foo,dc=bar collect_cf: free: dn=ou=customer_b,dc=foo,dc=bar 10.) analog to point 7.) ldapsearch reports "customer_e" has been deleted... 11.) so far so good, now lets try to increase our level of fun and delete another olcCollectInfo-value: #!RESULT OK #!CONNECTION ldap://10.111.1.1:3890 #!DATE 2009-04-24T11:36:18.343 dn: olcOverlay={0}collect,olcDatabase={2}bdb,cn=config changetype: modify delete: olcCollectInfo olcCollectInfo: "ou=users,ou=customer_f,dc=foo,dc=bar" l,st - 12.) slapd immediatly crashes, the logging output shows: collect_cf: LDAP_MOD_DELETE: c->valx=0 collect_cf: LDAP_MOD_DELETE: i=0 <--> dn=ou=users,ou=customer_a,dc=foo,dc=bar collect_cf: free: i=1 <--> dn=ou=users,ou=customer_a,dc=foo,dc=bar collect_cf: LDAP_MOD_DELETE: c->valx=6 collect_cf: LDAP_MOD_DELETE: i=0 <--> dn=(null) ==> segfault, ZONK! In my opinion it seems that the crash depends on the on-th-fly sorting of the DN-list which directly depends on the timely order the DNs have been added (processed by "insert_ordered()"). I'm not sure how to "fix" this bug providing an elegant solution because I don't understand the direct/slapd-internal mapping of i to ci->cn_next in detail (usually ldap results are unordered, perhabs something special regarding back-config?). The problem seems to be located here: for ( i=0; i <= c->valx; i++, cip = &ci->ci_next ) These were my two first thoughts regarding a possible workaround: - Always deleting and adding all values, in case one value gets modified? - Using ordered-format "{n}" seems to result in "always delete / add all values", too. I would appreciate your advice!

1 0

Re: (ITS#5382) JLDAP
by rarpit＠novell.com 24 Apr '09

24 Apr '09

--=__PartF5DD40B7.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable hi Jim, We have fixed the issue . We will be checking the same . Thanks for = identifying the issue . =20 regards Arpit=20 =20 --=__PartF5DD40B7.0__= Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Description: HTML <HTML><HEAD> <META http-equiv=3DContent-Type content=3D"text/html; charset=3Diso-8859-15= "> <META content=3D"MSHTML 6.00.2900.3492" name=3DGENERATOR></HEAD> <BODY style=3D"MARGIN: 4px 4px 1px; FONT: 10pt Segoe UI"> <DIV>hi Jim,</DIV> <DIV>    We have fixed the issue . We will be checking the = same . Thanks for identifying the issue .</DIV> <DIV> </DIV> <DIV>regards</DIV> <DIV>Arpit </DIV> <DIV> </DIV></BODY></HTML> --=__PartF5DD40B7.0__=--

1 0

Re: (ITS#5389) Contribution: JLDAP support for password policy response control
by rarpit＠novell.com 24 Apr '09

24 Apr '09

--=__Part133BA653.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable hi Raymond , =20 This is just for my understanding . Is Password Policy response is a = standard ? What is the requirement of this particular feature to be = present in JLDAP? What is this feature and how it can be used ?=20 We can take it in if this is a standard but if this is not a standard = than we cannot take this in as this will make the code bulkier.=20 =20 regards, Arpit=20 --=__Part133BA653.0__= Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Description: HTML <HTML><HEAD> <META http-equiv=3DContent-Type content=3D"text/html; charset=3Diso-8859-15= "> <META content=3D"MSHTML 6.00.2900.3492" name=3DGENERATOR></HEAD> <BODY style=3D"MARGIN: 4px 4px 1px; FONT: 10pt Segoe UI"> <DIV>hi Raymond ,</DIV> <DIV> </DIV> <DIV>   This is just for my understanding . Is Password Policy = response is a standard ? What is the requirement of this particular = feature to be present in JLDAP? What is this feature and how it can be = used ? </DIV> <DIV>   We can take it in if this is a standard but if this is = not a standard than we cannot take this in as this will make the code = bulkier. </DIV> <DIV> </DIV> <DIV>regards,<BR>Arpit </DIV></BODY></HTML> --=__Part133BA653.0__=--

1 0

Re: (ITS#6071) LDAP server becomes unresponsive
by carsten.rieck＠trustcenter.de 24 Apr '09

24 Apr '09

Hello, the update to OpenLDAP 2.4.16 has solved my problem with the unresponsive server. Quanah, thank you very much for your help. From my point of view, the ITS can be closed. Best regards, Carsten -- Dr. Carsten T. Rieck Development TC TrustCenter GmbH Sonninstrasse 24-28, 20097 Hamburg, Germany Tel.: +49-(0)40-808026-0, Fax: -126 Geschaeftsfuehrung/Managing Directors: Robert Steinkrauss , Dr. Sabine Kockskaemper , HRB 96168 Email: carsten.rieck(a)trustcenter.de www.trustcenter.de This email may contain confidential and privileged material for the sole use of the intended recipient. Any review or distribution by others is strictly prohibited. If you are not the intended recipient please contact the sender and delete all copies.

1 0

Re: (ITS#6072) slapo-collect: dnLength != dnDepth
by daniel＠pluta.biz 23 Apr '09

23 Apr '09

Michael Ströder schrieb: > daniel(a)pluta.biz wrote: >> I could not find a suitable api-call to determine a DN's depth. > > How about using ldap_bv2dn() and count the DN components? > >> So I've used >> posix regexp and uploaded that quick&dirty hacked patch right here: > > I guess reg ex splitting won't work for arbitrary DN strings. > > Ciao, Michael. I finaly managed to upload the patch under "incoming/collect.c.patch" Instead of using posix regexp I've used the ldap_bv2dn() based methode recommended by you. I would appreciate your revise. This patch does not include slapo-collect's schema-patch that I've filed some minutes ago (see: ITS#6075) Thanks!

1 0

(ITS#6075) slapo-collect: olcCollectInfo: no equality matching rule
by daniel＠pluta.biz 23 Apr '09

23 Apr '09

Full_Name: Daniel Pluta Version: 2.4.16 OS: Linux URL: ftp://ftp.openldap.org/incoming/daniel-pluta-090423.patch Submission from: (NULL) (91.12.202.8) It's impossible to delete one value from the multi-valued olcCollectInfo in case there are more than 1 olcCollectInfo values configured... Error: "olcCollectInfo: no equality matching rule" I've uploaded a small patch here: ftp://ftp.openldap.org/incoming/daniel-pluta-090423.patch I'm not sure whether ORDERING and SUBSTRINGMATCH are neccessary, optional or even wrong(?). Perhab's they can (have to?) be omitted - please see below... Index: ldap/servers/slapd/overlays/collect.c =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/overlays/collect.c,v retrieving revision 1.5.2.8 diff -u -r1.5.2.8 collect.c --- ldap/servers/slapd/overlays/collect.c 22 Jan 2009 00:01:12 -0000 1.5.2.8 +++ ldap/servers/slapd/overlays/collect.c 23 Apr 2009 20:00:02 -0000 @@ -230,6 +230,9 @@ ARG_MAGIC, collect_cf, "( OLcfgOvAt:19.1 NAME 'olcCollectInfo' " "DESC 'DN of entry and attribute to distribute' " + "EQUALITY caseIgnoreMatch " + "ORDERING caseIgnoreOrderingMatch " + "SUBSTR caseIgnoreSubstringsMatch " "SYNTAX OMsDirectoryString )", NULL, NULL }, { NULL, NULL, 0, 0, 0, ARG_IGNORED } };

1 0

Re: (ITS#6073) ftp.openldap.org "no space left on device"?
by daniel＠pluta.biz 23 Apr '09

23 Apr '09

Status update: it has been fixed - proved by me with: ftp> put daniel-pluta-090423.patch local: daniel-pluta-090423.patch remote: daniel-pluta-090423.patch 227 Entering Passive Mode (204,152,186,57,229,234) 150 Opening BINARY mode data connection for 'daniel-pluta-090423.patch'. 226 Transfer complete (unique file name:daniel-pluta-090423.patch). 735 bytes sent in 0.00 secs (413.2 kB/s) Thanks for addressing/solving this issue. Kurt Zeilenga schrieb: > This problem as been addressed. > > -- Kurt > > On Apr 22, 2009, at 7:45 AM, daniel(a)pluta.biz wrote: > >> Full_Name: Daniel Pluta >> Version: HEAD >> OS: Linux >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (2001:4ca0:0:f000:78be:f928:4392:2caf) >> >> >> ~/build/pkg$ ftp -p 204.152.186.57 >> Connected to 204.152.186.57. >> 220- OpenLDAP FTP Service >> 220 boole.openldap.org FTP server (Version 6.00LS) ready. >> Name (204.152.186.57:d): anonymous >> 331 Guest login ok, send your email address as password. >> Password: >> 230- Copyright 1998-2009, The OpenLDAP Foundation, All Rights Reserved. >> 230- COPYING RESTRICTIONS APPLY, see: >> 230- ftp://ftp.openldap.org/COPYRIGHT >> 230- ftp://ftp.openldap.org/LICENSE >> 230 Guest login ok, access restrictions apply. >> Remote system type is UNIX. >> Using binary mode to transfer files. >> ftp> cd incoming >> 250 CWD command successful. >> ftp> put collect.c.patch >> local: collect.c.patch remote: collect.c.patch >> 227 Entering Passive Mode (204,152,186,57,240,13) >> 150 Opening BINARY mode data connection for 'collect.c.patch.3'. >> 452 Error writing to file: No space left on device. >> 1833 bytes sent in 0.00 secs (1361.2 kB/s) >> ftp> >

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs