openldap-bugs April 2009

openldap-bugs@openldap.org

49 participants
141 discussions

Re: (ITS#5389) Contribution: JLDAP support for password policy response control
by t2tre＠skyblue.eu.com 28 Apr '09

28 Apr '09

Rastogi Arpit wrote: > hi Raymond , > Hi Arpit, > 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 ? > 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. The Password Policy control is based the IETF password policy proposal for LDAP. The following URLs provide more detail on it: https://datatracker.ietf.org/drafts/draft-behera-ldap-password-policy/ http://tools.ietf.org/draft/draft-behera-ldap-password-policy/draft-behera-… Essentially the code I've provided allows users of JLDAP send password policy request control messages and interpret the directory server responses. It can be used in the following instances: * At bind time where the directory server can indicate whether the user's account is about to expire, has expired, or is locked. * If the account is about to expire, how long before this occurs. * If the account has expired, how many grace logins are left before the account is locked out. * At password reset time where the directory server can indicate whether the new password meets password policy requirements including: * Whether the password is strong enough. * Whether the new password set is one that has already been used. These and more are described in the URLs I have provided. Although it is an expired draft, it is supported by OpenLDAP (in slapd via the slapo-ppolicy overlay and is also supported by the ldapsearch client). It is also supported by the following LDAP servers (there may be more but these are the ones I do use): CA/eTrust directory OpenDS SunONE directory IBM Tivoli directory server The functionality provided by the code I've written is also available in other programming languages (Perl via Net::LDAP and in other Java LDAP libraries). > > regards, > Arpit regards Ray -- Raymond B. Edah e-mail: t2tre ^ skyblue.eu.com web: http://www.cs.skyblue.eu.com

1 0

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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs April 2009