openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

Re: (ITS#6083) ppolicy should also support invocation of an external password checker
by hyc＠symas.com 30 Apr '09

30 Apr '09

Guillaume.Rousse(a)inria.fr wrote: > Full_Name: Guillaume Rousse > Version: 2.4.16 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (195.83.212.136) > > > Current implementation of ppolicy only accept an internal plugin as password > checker. However, writing native code is more difficult for many sysadmins than > using script languages. Moreover, it's also less safe, as any crash will > endanger the whole slapd process. Allowing to run an external process for > checking password would be desirable. If you're talking about writing a checker feature that fork/execs an external script interpreter, then I'll say up front that this is not a good idea, and we've already been deprecating anything else that operates this way (like back-shell). fork()/system()/spawn() whatever don't mix well with pthreads and will most likely corrupt something. As for isolation/crash vulnerability - this is a *password checker* - it is already a sensitive piece of code. If you're deploying a custom module without adequate testing or code review, you're already in trouble. You could of course take a similar approach as back-sock - open a socket to some other daemon that performs your checks for you. You then have to decide how to behave when the external process isn't answering... Ultimately, what you do inside your checker module is your own business. I see no action needed on our part; this ITS will be closed. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#6084) ppolicy should allow scheduled password expiration
by Guillaume.Rousse＠inria.fr 30 Apr '09

30 Apr '09

Full_Name: Guillaume Rousse Version: 2.4.16 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (195.83.212.136) Current ppolicy implementation allows to administratively lock a password, by setting pwdAccountLockedTime attribute to '000001010000Z' value. However, despite this value actually being a generalized date, setting it to any other date in the future doesn't work as expected. Moreover, this is an operational attribute, which is primarily supposed to be handled by slapd itself. As a consequence, a normal pwdExpirationDate attribute, which itself would set a boolean operational attribute pwdExpired attribute to a true value, would be desirable.

1 0

(ITS#6083) ppolicy should also support invocation of an external password checker
by Guillaume.Rousse＠inria.fr 30 Apr '09

30 Apr '09

Full_Name: Guillaume Rousse Version: 2.4.16 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (195.83.212.136) Current implementation of ppolicy only accept an internal plugin as password checker. However, writing native code is more difficult for many sysadmins than using script languages. Moreover, it's also less safe, as any crash will endanger the whole slapd process. Allowing to run an external process for checking password would be desirable.

1 0

(ITS#6082) ppolicy password checker module should make possible to return error to the client
by Guillaume.Rousse＠inria.fr 30 Apr '09

30 Apr '09

Full_Name: Guillaume Rousse Version: 2.4.16 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (195.83.212.136) Current implementation of password checker doesn't allow exact errors returned by the external module to be returned to the client, for security reason. They are only available in server logs. Quoting man page: If the password is unacceptable, the server will return an error to the client, and ppErrStr may be used to return a human-readable textual explanation of the error. As it is already difficult to have strong password policies accepted by users, making this behaviour configurable, exactly the same way the ppolicy_use_lockout option allows the servers to return more information if wanted to the client, would be desirable.

1 0

(ITS#6081) slapo-rwm(5)'s rwm_entry_get_rw() does not release entries after copying
by masarati＠aero.polimi.it 29 Apr '09

29 Apr '09

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (131.175.154.146) Submitted by: ando In fact, it exploits rwm_send_entry() to muck with entry's data as appropriate, but passes a fake SlapReply structure, with sr_flags reset. We need to enforce entry's release regardless of how the underlying database will take care of it. A fix is coming. p.

1 0

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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs