openldap-bugs February 2012

openldap-bugs@openldap.org

33 participants
146 discussions

Re: (ITS#7166) MDB segfault
by quanah＠zimbra.com 15 Feb '12

15 Feb '12

--On Wednesday, February 15, 2012 1:00 PM +0000 tomasz.rutkowski(a)tombas.pl wrote: > Full_Name: Tomasz Rutkowski > Version: 2.4.28, 2.4.29 > OS: PLD Linux (Th) x86_64 > URL: > Submission from: (NULL) (91.216.16.90) > > > back_mdb crashes when it's accessed through back_relay (rwm-suffixmassage > rewrite) for authentication, works normal for search/write however. Please provide a full backtrace from gdb, with debugging symbols. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7167) regression, ldap_result() returns -1
by jvcelak＠redhat.com 15 Feb '12

15 Feb '12

Full_Name: Jan Vcelak Version: 2.4.29 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (209.132.186.34) There is a possible regression caused by 06ec9f1db2bb9dc304a4adcd0d0506203cf9e6b6. SSSD's event loop listens for events on a file descriptor retrieved using ber_sockbuf_ctrl(sb, LBER_SB_OPT_GET_FD, &ber_fd). If there are some data to be read, processing using ldap_result is triggered. (Internally, tevent from Samba project is used, which uses epoll.) But sometimes, ldap_result() returns -1 error code. It seems that the descriptor is marked as readable untimely. This problem is not present with OpenLDAP 2.4.26, it appears with all future versions. When the mentioned commit is reverted, everything works well. Original report in our Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=771484 It was also reported in Ubuntu: https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/929888 And i similar report, hopefully with the same cause: https://bugzilla.redhat.com/show_bug.cgi?id=790414

1 0

(ITS#7166) MDB segfault
by tomasz.rutkowski＠tombas.pl 15 Feb '12

15 Feb '12

Full_Name: Tomasz Rutkowski Version: 2.4.28, 2.4.29 OS: PLD Linux (Th) x86_64 URL: Submission from: (NULL) (91.216.16.90) back_mdb crashes when it's accessed through back_relay (rwm-suffixmassage rewrite) for authentication, works normal for search/write however. relevant part of config: dn: olcDatabase={1}relay,cn=config objectClass: olcRelayConfig objectClass: olcDatabaseConfig objectClass: olcConfig objectClass: top olcDatabase: {1}relay olcSuffix: dc=tombas,dc=pl structuralObjectClass: olcRelayConfig entryUUID: b49ff4ea-4b45-49f6-8c22-68a781a6a5a4 creatorsName: cn=admin,cn=config createTimestamp: 20120206145349Z entryCSN: 20120207115116.293644Z#000000#00e#000000 modifiersName: cn=admin,cn=config modifyTimestamp: 20120207115116Z dn: olcOverlay={0}rwm,olcDatabase={1}relay,cn=config objectClass: olcRwmConfig objectClass: olcOverlayConfig objectClass: olcConfig objectClass: top olcOverlay: {0}rwm structuralObjectClass: olcRwmConfig entryUUID: f716d56b-b55d-4873-87b2-67e9c5b707c3 creatorsName: cn=admin,cn=config createTimestamp: 20120206145428Z olcRwmRewrite: {0}rwm-suffixmassage ou=accounts,o=tombas entryCSN: 20120214135243.684294Z#000000#00d#000000 modifiersName: cn=admin,cn=config modifyTimestamp: 20120214135243Z with best regards Tomasz Rutkowski

1 0

Re: (ITS#7150) SEGFAULT in openldap-2.4.28 & 2.4.29
by david.coutadeur＠linagora.com 15 Feb '12

15 Feb '12

Hi, After a more detailed analysis, I finally had a segfault. (after 10 to 15 tests, as described below) I don't know if this is the same bug this time, so please tell me and I will open a new ticket if necessary. Thank you in advance for helping. D. (gdb) bt full #0 sp_avl_cmp (c1=0x8b4004c8, c2=0xa37cf28) at syncprov.c:366 rc = <value optimized out> #1 0x081afe3e in avl_delete (root=0xa255648, data=0x8b4004c8, fcmp=0x81948a0 <sp_avl_cmp>) at avl.c:197 p = <value optimized out> q = <value optimized out> r = <value optimized out> top = <value optimized out> side = <value optimized out> side_bf = <value optimized out> shorter = <value optimized out> nside = <value optimized out> pptr = {0x89908, 0x0, 0x0, 0x0, 0xe8043c, 0x0, 0xfdc, 0x8d994858, 0xe7b95c, 0xfdc, 0xa372570, 0x0, 0xa288350, 0xe8043c, 0xa372570, 0x8d994878, 0xe7c324, 0xfdc, 0xa372570, 0x0, 0xe7af2c, 0x8cb9136e, 0x81b3634, 0x0, 0xe8043c, 0xe, 0xa3d3a40, 0x8d9948b8, 0xe7d081, 0xa3e3618, 0x8cb91358, 0x823c27} pdir = "\000\000\000\000lI\231\215\064\066\033\bn>\000\000\244\345t\000\310\004@\213\b\346\067\n\310H\231\215" depth = 0 #2 0x08199f7f in syncprov_op_cleanup (op=0xa37e608, rs=0x8d995108) at syncprov.c:1401 cb = 0x8cb91258 opc = 0x8cb91268 si = 0xa255610 sm = 0xa255688 snext = <value optimized out> mt = 0x8b4004c8 #3 0x08089654 in slap_cleanup_play (op=0xa37e608, rs=0x8d995108) at result.c:541 sc_next = 0x8d994dec sc = 0x8cb91258 scp = 0x8d994928 #4 0x0808a150 in send_ldap_response (op=0xa37e608, rs=0x8d995108) at result.c:733 berbuf = { buffer = "\000\000\001\000\000\001\000\000\377\377\377\377", '\000' <repeats 12 times>, "f\023\271\214\064#\271\214\000\000\000\000f\023\271\214p%7\n\000\000\000\000\314I\231\215\001\000\000\000\000\000\000\000\314mK\236x\271\347\000\001\000\000\000`+@\213D`K\236\230\063\066\n\250<6\n\000\000\000\000\000\000\000\000\005\000\000\000P7@\213`\343\070\n\000\000\000\000\n\000\000\000(\234\200\330\000\000\000\000\000\000\000\000@4\"\000\000\000\000\000(\234\200\330\210J\231\215\270\214 \000\230\063\066\n`+@\213\314mK\236\r\000\000\000\001\000\000\000\021\217;O(\234\200\330\000\000\000\000`&%\n`&%\n8J\231\215b\f\"\000\224mK\236\230\063\066\n(\234\200أ\347\022\b\a", '\000' <repeats 31 times>, "D'%\n\224mK\236\000\000\000", ialign = 65536, lalign = 65536, falign = 9.18354962e-41, dalign = 5.4323095486619588e-312, palign = 0x10000 <Address 0x10000 out of bounds>} ber = <value optimized out> rc = 32768 bytes = 14 __PRETTY_FUNCTION__ = "send_ldap_response" #5 0x0808af1f in slap_send_ldap_result (op=0xa37e608, rs=0x8d995108) at result.c:860 tmp = 0x0 otext = 0x0 oref = 0x0 __PRETTY_FUNCTION__ = "slap_send_ldap_result" #6 0x0812bde5 in bdb_add (op=0xa37e608, rs=0x8d995108) at add.c:511 pdn = {bv_len = 23, bv_val = 0x8b40372f "ou=people,dc=afp,dc=com"} p = 0x8fc4c0fc oe = 0x8fc4c804 ei = 0xa37d1c8 textbuf = "\000\000\000\000\320O\"\n", '\000' <repeats 48 times>, "\001", '\000' <repeats 198 times> children = 0xa223b20 entry = 0xa223980 ltid = 0x0 lt2 = 0x8b402bf0 eid = 57976 opinfo = {boi_oe = {oe_next = {sle_next = 0x8d99509c}, oe_key = 0x0}, boi_txn = 0x8b402b60, boi_locks = 0x0, boi_err = 0, boi_acl_cache = 0 '\000', boi_flag = 0 '\000'} lock = {off = 133260, ndx = 772, gen = 2004, mode = DB_LOCK_READ} num_retries = 0 success = 0 postread_ctrl = 0x0 ctrls = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0} num_ctrls = 0 #7 0x080e33a1 in overlay_op_walk (op=0xa37e608, rs=0x8d995108, which=op_add, oi=0xa254ff0, on=0xa255508) at backover.c:671 rc = 32768 #8 0x080e3a0a in over_op_func (op=0xa37e608, rs=0x8d995108, which=op_add) at backover.c:723 oi = 0xa254ff0 on = 0xa255508 be = 0xa252560 db = {bd_info = 0x821d41c, bd_self = 0xa252560, be_ctrls = "\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001\001\000\000\000\000\001\000\001\000\000\000\000\000\000\000\000\000\001", be_flags = 563464, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0xa288350, be_nsuffix = 0xa288368, be_schemadn = { bv_len = 0, bv_val = 0x0}, be_schemandn = {bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 24, bv_val = 0xa287648 "cn=Manager,dc=afp,dc=com"}, be_rootndn = {bv_len = 24, bv_val = 0xa2876d0 "cn=manager,dc=afp,dc=com"}, be_rootpw = {bv_len = 38, bv_val = 0xa2876f0 "{SSHA}rEmMhg3MU5xkQX5Ng92tH4WzGMlA+nGU"}, be_max_deref_depth = 15, be_def_limit = { lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 15000, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0xa255748, be_acl = 0x0, be_dfltaccess = ACL_READ, be_extra_anlist = 0x0, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0xa363388, be_pcl_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __kind = 0, __nusers = 0, {__spins = 0, __list = {__next = 0x0}}}, __size = '\000' <repeats 23 times>, __align = 0}, be_syncinfo = 0xa28aec8, be_pb = 0x0, be_cf_ocs = 0x821f840, be_private = 0xa252660, be_next = { stqe_next = 0xa288538}} cb = {sc_next = 0x0, sc_response = 0x80e30e0 <over_back_response>, sc_cleanup = 0, sc_private = 0xa254ff0} sc = <value optimized out> rc = <value optimized out> __PRETTY_FUNCTION__ = "over_op_func" #9 0x08081129 in fe_op_add (op=0xa37e608, rs=0x8d995108) at add.c:334 repl_user = 0 rc = <value optimized out> bd = 0x82234c0 textbuf = "\000\000\000\000\000\000\000\000\060[\231\215\000\000\000\000\035\000\000\000\020\070@\213\001\000\000\000xN\231\215\270\026@\213(I\"\n\002\000\000\000\250N\231\215\255\214\v\b\270\026@\213\224N\231\215\001\000\000\000\000\000\000\000x9@\213\000\000\000\000\n\000\000\000\001\000\000\000\340\067@\213\n\000\000\000\060\070@\213\320\026@\213(I\"\n\270\026@\213\370N\231\215oc\t\b\002\000\000\000X( \n\370N\231\215\321_\t\bh\234!\n\240\066@\213'<\202\000\000\000\000\000\f\000\000\000W.@\213n>\000\000\244\345t\000\320O\"\n\320O\"\n\370N\231\215\035\205q\000 .\"\b\314h\032\216\030O\231\215\245\063\b\b .\"\b\240\066@\213\000\000\000\000\270\026@\213\244i\032\216\000\000\000\000HO\231\215\267\r\b\b\320O\"\n\320O\"\n\001\000\000\000HO\231\215\020\000\000\000\340h\032\216\377\377\377\377" __PRETTY_FUNCTION__ = "fe_op_add" #10 0x08081a13 in do_add (op=0xa37e608, rs=0x8d995108) at add.c:194 ber = <value optimized out> last = 0x8b402e71 "" dn = {bv_len = 38, bv_val = 0x8b402d98 "uid=dcoutadeur,ou=People,dc=afp,dc=com"} len = 28 tag = <value optimized out> modlist = 0x8b4015f0 modtail = 0x8b403694 tmp = {sml_mod = {sm_desc = 0x80ce5ca, sm_values = 0x8b4036a0, sm_nvalues = 0x0, sm_numvals = 2375635128, sm_op = 0, sm_flags = 0, sm_type = {bv_len = 12, bv_val = 0x8b402e57 "userPassword"}}, sml_next = 0x823c27} textbuf = "\025\000\000\000\310\031@\213\b\026@\213\006\340(\000\220[\231\215\000\000\000\000\000\000\000\000\020\000@\213\025\000\000\000\310\031@\213\310+@\213\005\070/\000\200O@\213T\245(\000\000\000\000\000\020\000@\213\364\237\067\000\220[\231\215\000\000\000\000\233\071@\213@:=\n\370O\231\215T\213\202\000b\213\202\000;\334\347\000\"\000\000\000\233\071@\213\b\000\000\000\201\354(\000\fP\231\215<\004\350\000\270P\231\215\312\315\347\000\370\326\070\n\233\071@\213\b\000\000\000\001\200\255\373\b\347\067\n@\000\000\000\243P\231\215@\000@\213\026\347\067\n@\000@\213\b\347\067\n@\261\067\000,\000\000\000\020\000@\213", '\000' <repeats 20 times>, "5\000\000\000@\000@\213\000\000\000\000\340\021@\213\000\000\000\000\000\000\000\000\260+@\213\000\000\000\000\001\000\000\000\004\000\020\000\350Q\231\215\310P\231\215" rc = <value optimized out> freevals = <value optimized out> oex = {oe = {oe_next = {sle_next = 0x0}, oe_key = 0x8081330}, oe_db = 0x0} #11 0x0807988c in connection_operation (ctx=0x8d9951e8, arg_v=0xa37e608) at connection.c:1150 rc = <value optimized out> cancel = <value optimized out> rs = {sr_type = REP_RESULT, sr_tag = 105, sr_msgid = 2, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = {sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}, sru_sasl = {r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}}, sr_flags = 0} tag = 104 opidx = SLAP_OP_ADD conn = 0xb7f3bc10 memctx = 0xa372570 memctx_null = 0x0 __PRETTY_FUNCTION__ = "connection_operation" #12 0x0807a0fd in connection_read_thread (ctx=0x8d9951e8, argv=0x22) at connection.c:1286 s = <value optimized out> #13 0x00717a24 in ldap_int_thread_pool_wrapper (xpool=0xa2265c8) at tpool.c:688 task = 0xa382e10 work_list = <value optimized out> ctx = {ltu_id = 2375637904, ltu_key = {{ltk_key = 0x80ce400, ltk_data = 0xa372570, ltk_free = 0x80ce430 <slap_sl_mem_destroy>}, {ltk_key = 0xa363398, ltk_data = 0xa371a88, ltk_free = 0x812e4c0 <bdb_reader_free>}, {ltk_key = 0x8078320, ltk_data = 0xa37de68, ltk_free = 0x80783f0 <conn_counter_destroy>}, {ltk_key = 0x808dde0, ltk_data = 0x0, ltk_free = 0x808dbf0 <slap_op_q_destroy>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>}} kctx = <value optimized out> keyslot = 241 hash = 5278961 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #14 0x00821832 in start_thread () from /lib/libpthread.so.0 No symbol table info available. #15 0x002f746e in clone () from /lib/libc.so.6 No symbol table info available. Le 14/02/2012 19:01, Howard Chu a écrit : > David Coutadeur wrote: >> >> Many thanks for your rapid fix ! It seems to work better. Some problems >> remain unfortunately : >> >> slapd freezes, after 10 to 15 rapid tests, interrupted by Ctrl-C after >> 10 seconds (a test is 100 times 100 threads, each doing a bind, an add, >> a modify, a delete, and a logout). >> Memory is stable, but cpu is taken at 99,7% by slapd. > > Sounds like a different problem, which should obviously be handled in a > different bug report. And again, please provide a gdb snapshot of all > the active threads when the problem occurs. >> >> >> >> Le 03/02/2012 18:36, Howard Chu a écrit : >>> Thanks. A fix for this is now in git master (5584e5b) >>> >>>> Le 03/02/2012 18:15, Howard Chu a écrit : >>>>> david.coutadeur(a)linagora.com wrote: >>>>>> I have reproduced the bug with a fresh new HEAD version yesterday, >>>>>> including : >>>>>> 02/02/2012 Howard Chu ITS#7146 fix prev commit >>>>> >>>>> Can you include a "bt full" gdb backtrace on this? >>>>> >>>>>> Le 02/02/2012 20:25, Michael Ströder a écrit : >>>>>>> dcoutadeur(a)linagora.com wrote: >>>>>>>> I have encountered a bug on openldap 2.4.28 and openldap 2.4.29 >>>>>>>> (ie git >>>>>>>> version) >>>>>>> >>>>>>> Which exact git version? Did you build RE24 from git already >>>>>>> containing >>>>>>> the fix for ITS#7113 (dup of ITS#6928)? >>> >> >> > >

1 0

Re: (ITS#7165) Killing slap tools breaks the running mdb
by h.b.furuseth＠usit.uio.no 15 Feb '12

15 Feb '12

I wrote: > Aborting an MDB process can break MDB if another MDB process is > running, because then locks/reader table info are not reset. I forgot the patch I've been using to play with mdb: http://folk.uio.no/hbf/OpenLDAP/its7165.diff

1 0

(ITS#7165) Killing slap tools breaks the running mdb
by h.b.furuseth＠usit.uio.no 14 Feb '12

14 Feb '12

Full_Name: Hallvard B Furuseth Version: master, d861910f55cb1beb5e443caa7e961ed760074352 OS: Linux x86_64 URL: Submission from: (NULL) (195.1.106.125) Submitted by: hallvard Aborting an MDB process can break MDB if another MDB process is running, because then locks/reader table info are not reset. The problems below go away when the last slap process terminates so the lockfile can be reset. Sometimes kill -KILL is needed. ==== lock.conf ==== include servers/slapd/schema/core.schema database mdb suffix o=hi directory lock.dir (A) If a process holding a shared mutex dies, other processes' ops on the mutex can hang/fail: rm -rf lock.dir; mkdir lock.dir servers/slapd/slapd -f lock.conf -h ldapi://ldapi -d0 & MDB_KILL_R=true servers/slapd/slapd -Tcat -f lock.conf ldapsearch -xLLH ldapi://ldapi -b o=hi l=x 1.1 ^C (kills ldapsearch which is waiting for results) kill %% (fails to kill slapd) kill -KILL %% The Posix fix, robust mutexes, is outlined below. With _WIN32, check return code WAIT_ABANDONED. __APPLE__ Posix semaphores: Don't know. SysV semaphores have SEM_UNDO to cancel the process' effect if the process dies, but the peers do not seem to be informed that this happened. if ((rc = pthread_mutexattr_init( &mattr )) || (rc = pthread_mutexattr_setpshared(&mattr, PTHREAD_PROCESS_SHARED)) || (rc = pthread_mutexattr_setrobust( &mattr, PTHREAD_MUTEX_ROBUST )) || (rc = pthread_mutex_init(&mutex, &mattr ))) return rc; ... switch (pthread_mutex_lock(&mutex)) { case 0: break; case EOWNERDEAD: Repair the possibly half-updated data protected by <mutex>; if (successful repair) { pthread_mutex_consistent(&mutex); break; } /* With Posix mutexes, make future use of <mutex> return failure: */ pthread_mutex_unlock(&mutex); /* FALLTHRU */ default: return MDB_PANIC; } ... pthread_mutex_unlock(&mutex); BTW, the above also happens with MDB_KILL_W=true slapcat followed by ldapadd, dunno why slapcat uses a txn without MDB_TXN_RDONLY. In this case, raise(SIGINT) is sufficient. With MDB_KILL_R, that does not kill slapd and we need SIGKILL - it catches SIGINT I guess. Don't know if that difference is intentional. (B1) Repeated kill -KILL slap<tool> while slapd is running can use up the reader table since it does not clear its table slots, making the db unusable. (B2) slapcat report no error after it fails to read the db due to full reader table, it exits with success status. (B3) After one "kill -KILL slap<tool>" while slapd is running, I imagine the stale slot which does not go away can prevent freelist reuse so the db grows quickly. But I have not seen that. bash$ rm -rf lock.dir; mkdir lock.dir bash$ servers/slapd/slapd -f lock.conf -h ldapi://ldapi -d0 & bash$ for (( i=0; i<130; i++)) { MDB_KILL_UR=true servers/slapd/slapd -Tcat -f lock.conf } > /dev/null bash$ servers/slapd/slapd -Tcat -f lock.conf -d-1 2>cat.out (success result, no output, no errors in the log) bash$ ldapsearch -xLLH ldapi://ldapi -b o=hi l=x 1.1 version: 1 [R..RLOCKED..R1] Other (e.g., implementation specific) error (80) Additional information: internal error bash$ Maybe it's easier to have a per-process reader table after all, and a shared table with just the oldest txn per process. Or, each transaction chould have an exclusive file region lock. A writer could try to grab the oldest txn's region lock if that belongs to another process, and clear the txn it if successful. A reader, before giving up, would just search for another pid's txn whose lock it can grab. Except since the system reuses pids, the ID would either have to be more exclusive (e.g. pid + mdb_env_open() time) or mdb_env_open must clear away reader table entries with its own pid. Speaking of which, I don't see the use of the repeated getpid() calls. Should be enough to store the pid in the MDB_env. fcntl record locks do not survive fork(), so an MDB_env doesn't either. And the thread ID is unsed, and must be reset with memset, not 'mr_tid = 0' since pthread_t can be a struct. (C) Mentioned earlier: Startup can fail due to a race condition, when another process starts MDB at the same time and then aborts: - Process 1 starts MDB, gets write lock in mdb_env_setup_locks(). - Process 2 starts MDB, awaits read lock since write lock is taken. - Process 1 dies. - Process 2 gets the read lock and proceeds, but with an uninitialized lockfile since it expects that process 1 initialized it. Fix: An extra exclusive lock around the current lock setup code. kill slapd process, if any rm -rf lock.dir; mkdir lock.dir MDB_RACE=true servers/slapd/slapd -Tcat -f lock.conf & sleep 1; \ servers/slapd/slapd -Tcat -f lock.conf In addition, the above dumps core in mdb_env_close: for (i=0; i<env->me_txns->mti_numreaders; i++) where env->me_txns == (MDB_txninfo *) 0xffffffffffffffff. (D) And of course ^Z when holding a mutex can block other processes' threads, but I suppose BDB has the same problem. DB_SUSPEND=true servers/slapd/slapd -Tadd -f lock.conf < /dev/null servers/slapd/slapd -Tadd -f lock.conf < /dev/null (hanging...) ^C kill %% The fix I can see for now is "don't do that" in the doc. MDB could in addition use pthread_mutex_timedlock() so slapd at least can keep running and can be killed without kill -KILL. Final fix = a lock-free library, when a useful portable one emerges.

1 0

Re: ~*~ [spam] Re: (ITS#7143) Assertion error (crash); using relay backend and translucent ove
by hyc＠symas.com 14 Feb '12

14 Feb '12

Mattias Andersson wrote: > On Sat, 04 Feb 2012 01:59:49 +0100, Howard Chu<hyc(a)symas.com> wrote: >> OK, we need to know exactly what the difference is between the >> ldapsearch query and the browser query. Can you please run slapd -d7 and >> record first the ldapsearch query and then the browser query and post >> the output for each of those? > > Attached the output from the two queries. Thanks. The difference is that the softerra browser was searching with attrsOnly set true, so all of the returned attributes had no values. Setting this option in ldapsearch allowed the issue to be reproduced. This is now fixed in git master. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#7150) SEGFAULT in openldap-2.4.28 & 2.4.29
by hyc＠symas.com 14 Feb '12

14 Feb '12

David Coutadeur wrote: > > Many thanks for your rapid fix ! It seems to work better. Some problems > remain unfortunately : > > slapd freezes, after 10 to 15 rapid tests, interrupted by Ctrl-C after > 10 seconds (a test is 100 times 100 threads, each doing a bind, an add, > a modify, a delete, and a logout). > Memory is stable, but cpu is taken at 99,7% by slapd. Sounds like a different problem, which should obviously be handled in a different bug report. And again, please provide a gdb snapshot of all the active threads when the problem occurs. > > > > Le 03/02/2012 18:36, Howard Chu a écrit : >> Thanks. A fix for this is now in git master (5584e5b) >> >>> Le 03/02/2012 18:15, Howard Chu a écrit : >>>> david.coutadeur(a)linagora.com wrote: >>>>> I have reproduced the bug with a fresh new HEAD version yesterday, >>>>> including : >>>>> 02/02/2012 Howard Chu ITS#7146 fix prev commit >>>> >>>> Can you include a "bt full" gdb backtrace on this? >>>> >>>>> Le 02/02/2012 20:25, Michael Ströder a écrit : >>>>>> dcoutadeur(a)linagora.com wrote: >>>>>>> I have encountered a bug on openldap 2.4.28 and openldap 2.4.29 >>>>>>> (ie git >>>>>>> version) >>>>>> >>>>>> Which exact git version? Did you build RE24 from git already >>>>>> containing >>>>>> the fix for ITS#7113 (dup of ITS#6928)? >> > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#7150) SEGFAULT in openldap-2.4.28 & 2.4.29
by david.coutadeur＠linagora.com 14 Feb '12

14 Feb '12

Many thanks for your rapid fix ! It seems to work better. Some problems remain unfortunately : slapd freezes, after 10 to 15 rapid tests, interrupted by Ctrl-C after 10 seconds (a test is 100 times 100 threads, each doing a bind, an add, a modify, a delete, and a logout). Memory is stable, but cpu is taken at 99,7% by slapd. Le 03/02/2012 18:36, Howard Chu a écrit : > Thanks. A fix for this is now in git master (5584e5b) > >> Le 03/02/2012 18:15, Howard Chu a écrit : >>> david.coutadeur(a)linagora.com wrote: >>>> I have reproduced the bug with a fresh new HEAD version yesterday, >>>> including : >>>> 02/02/2012 Howard Chu ITS#7146 fix prev commit >>> >>> Can you include a "bt full" gdb backtrace on this? >>> >>>> Le 02/02/2012 20:25, Michael Ströder a écrit : >>>>> dcoutadeur(a)linagora.com wrote: >>>>>> I have encountered a bug on openldap 2.4.28 and openldap 2.4.29 >>>>>> (ie git >>>>>> version) >>>>> >>>>> Which exact git version? Did you build RE24 from git already >>>>> containing >>>>> the fix for ITS#7113 (dup of ITS#6928)? >

1 0

(ITS#7164) Prevent change of TLS setting if invalid (Dynamic Config)
by nick＠eurobjects.com 13 Feb '12

13 Feb '12

Full_Name: Nikolaos Milas Version: 2.4.28 OS: CentOS 5.7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (94.65.22.12) If, in a working OpenLDAP installation with dynamic configuration, we inadvertently change the value of: olcTLSCertificateKeyFile: /path/to/key.pem to some invalid value, like: olcTLSCertificateKeyFile: /path/to/non/existing/key.pem then OpenLDAP Server continues to work (and we see no error message whatsoever), but if it is stopped, it refuses to restart. In the logs, while OpenLDAP is starting, we see: Feb 11 16:20:44 vdev slapd[15272]: main: TLS init def ctx failed: -1 and then service is immediately stopped. OpenLDAP Server should check whether the new parameter value points to an existing file, and, if not, it should refuse to change the attribute value. For a more complete procedure, it could also check whether the indicated file includes a valid certificate, suitable for this parameter, and, again, if not, it should refuse to change the attribute value. Also, in case it's possible that one of the TLS File parameters gets an invalid value (e.g. through slapadd), then a meaningful message during startup failure would be helpful, e.g.: "olcTLSCertificateKeyFile: File /path/to/key.pem not found or contains invalid certificate."

1 0

← Newer
1
...
5
6
7
8
9
10
11
...
15
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs February 2012