openldap-bugs April 2008

openldap-bugs@openldap.org

45 participants
192 discussions

(ITS#5456) inaccurate interpretation of LDIF in back perl
by uw＠o3si.de 04 Apr '08

04 Apr '08

Full_Name: Uwe Werler Version: 2.3.32 OS: SLES10 SP1 Kernel 2.6.16.54-0.2.3-xen URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (155.56.68.221) The database backend "back_perl" expects LDIF entries beginning with "dn:" and ending with an empty line. RFC2849 only describes that an entry is everything except an empty line and a line not beginning (after a CR/LF) with a single white space character. After some testing with back_perl I noticed that the LDIF entries produced by the perl module Net::LDAP::LDIF were not acceptet because they are beginning with an empty line and ending only with a simple CR charakter. This behavior breaks RFC2849. After changing LDIF.pm from that module to produce the CR after the entry back_perl accepts this entries too. IMHO this is a misbehavior so I'm very glad if You'll take a look at this issue. Thanks in advance. Regards Uwe

1 0

Re: (ITS#5454) syncrepl refreshAndPersist stops receiving
by hyc＠symas.com 04 Apr '08

04 Apr '08

rein(a)basefarm.no wrote: > Hm, I hope I have found the race condition that causes this :-) I'm now > running with the patch at the end to see if that solves it, only time will > tell.. > > The race is that between the time selecting on the syncrepl socket is > enabled by the call to connection_client_enable() and the release of the > si_mutex a new message may arrive. If so, the next call to do_syncrepl > may fail in its attempt to trylock the mutex and no-one will re-enable > selecting on it again. My patch delays enabling of the socket until the > mutex has been released, which looks safe to me. Or can the access to > si->si_conn without a lock be a problem? How about just moving the enable to after the runqueue manipulation is done? Just need to be sure that do_syncrepl() isn't entered again before si->si_conn gets initialized. It also occurs to me that we probably don't even need to manipulate the slapd runqueue in persist mode, when si->si_conn is already set. I.e., in that case we can only have gotten here because of a listener event, and not because of a runqueue schedule. -- -- 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#5452) seg fault in syncprov_op abandon on master
by quanah＠zimbra.com 04 Apr '08

04 Apr '08

--On Friday, April 04, 2008 1:23 PM +0200 Hallvard B Furuseth <h.b.furuseth(a)usit.uio.no> wrote: > Since it crashes on > if ( so->s_op->o_connid == op->o_connid && > so->s_op->o_msgid == op->orn_msgid ) > please try > frame 0 > print *op > print *so->s_op > and maybe > backtrace full > while you are at it. #0 0x0000002a975f21ec in syncprov_op_abandon (op=0x42002b40, rs=0x42002a50) at syncprov.c:1026 1026 if ( so->s_op->o_connid == op->o_connid && (gdb) frame 0 #0 0x0000002a975f21ec in syncprov_op_abandon (op=0x42002b40, rs=0x42002a50) at syncprov.c:1026 1026 if ( so->s_op->o_connid == op->o_connid && (gdb) print *op $1 = {o_hdr = 0x42002ac0, o_tag = 80, o_time = 0, o_tincr = 0, o_bd = 0x42002830, o_req_dn = {bv_len = 0, bv_val = 0x0}, o_req_ndn = {bv_len = 0, bv_val = 0x0}, o_request = {oq_add = { rs_e = 0x4, rs_modlist = 0x0}, oq_bind = {rb_method = 4, rb_cred = {bv_len = 0, bv_val = 0x0}, rb_edn = {bv_len = 0, bv_val = 0x0}, rb_ssf = 0, rb_tmp_mech = {bv_len = 0, bv_val = 0x0}}, oq_compare = {rs_ava = 0x4}, oq_modify = {rs_modlist = 0x4, rs_increment = 0}, oq_modrdn = {rs_newrdn = {bv_len = 4, bv_val = 0x0}, rs_nnewrdn = {bv_len = 0, bv_val = 0x0}, rs_newSup = 0x0, rs_nnewSup = 0x0, rs_deleteoldrdn = 0}, oq_search = {rs_scope = 4, rs_deref = 0, rs_slimit = 0, rs_tlimit = 0, rs_limit = 0x0, rs_attrsonly = 0, rs_attrs = 0x0, rs_filter = 0x0, rs_filterstr = {bv_len = 0, bv_val = 0x0}}, oq_abandon = {rs_msgid = 4}, oq_cancel = {rs_msgid = 4}, oq_extended = {rs_reqoid = {bv_len = 4, bv_val = 0x0}, rs_flags = 0, rs_reqdata = 0x0}, oq_pwdexop = {rs_extended = {rs_reqoid = {bv_len = 4, bv_val = 0x0}, rs_flags = 0, rs_reqdata = 0x0}, rs_old = {bv_len = 0, bv_val = 0x0}, rs_new = {bv_len = 0, bv_val = 0x0}, rs_mods = 0x0, rs_modtail = 0x0}}, o_abandon = 0, o_cancel = 0, o_groups = 0x0, o_do_not_cache = 0 '\0', o_is_auth_check = 0 '\0', o_nocaching = 0 '\0', o_delete_glue_parent = 0 '\0', o_no_schema_check = 0 '\0', o_ctrlflag = '\0' <repeats 31 times>, o_controls = 0x0, o_authz = { sai_method = 0, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 0, bv_val = 0x0}, sai_ndn = {bv_len = 0, bv_val = 0x0}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, o_ber = 0x0, o_res_ber = 0x0, o_callback = 0x42002810, o_ctrls = 0x0, o_csn = {bv_len = 0, bv_val = 0x0}, o_private = 0x0, o_next = {stqe_next = 0x0}} (gdb) print *so->s_op $2 = {o_hdr = 0x11d8fd60, o_tag = 0, o_time = 0, o_tincr = 0, o_bd = 0x0, o_req_dn = {bv_len = 0, bv_val = 0x0}, o_req_ndn = {bv_len = 0, bv_val = 0x0}, o_request = {oq_add = {rs_e = 0x0, rs_modlist = 0x0}, oq_bind = {rb_method = 0, rb_cred = {bv_len = 0, bv_val = 0x0}, rb_edn = {bv_len = 0, bv_val = 0x0}, rb_ssf = 0, rb_tmp_mech = {bv_len = 0, bv_val = 0x0}}, oq_compare = {rs_ava = 0x0}, oq_modify = {rs_modlist = 0x0, rs_increment = 0}, oq_modrdn = {rs_newrdn = {bv_len = 0, bv_val = 0x0}, rs_nnewrdn = {bv_len = 0, bv_val = 0x0}, rs_newSup = 0x0, rs_nnewSup = 0x0, rs_deleteoldrdn = 0}, oq_search = {rs_scope = 0, rs_deref = 0, rs_slimit = 0, rs_tlimit = 0, rs_limit = 0x0, rs_attrsonly = 0, rs_attrs = 0x0, rs_filter = 0x0, rs_filterstr = {bv_len = 0, bv_val = 0x0}}, oq_abandon = {rs_msgid = 0}, oq_cancel = {rs_msgid = 0}, oq_extended = {rs_reqoid = {bv_len = 0, bv_val = 0x0}, rs_flags = 0, rs_reqdata = 0x0}, oq_pwdexop = {rs_extended = {rs_reqoid = {bv_len = 0, bv_val = 0x0}, rs_flags = 0, rs_reqdata = 0x0}, rs_old = {bv_len = 0, bv_val = 0x0}, rs_new = { bv_len = 0, bv_val = 0x0}, rs_mods = 0x0, rs_modtail = 0x0}}, o_abandon = 0, o_cancel = 0, o_groups = 0x0, o_do_not_cache = 0 '\0', o_is_auth_check = 0 '\0', o_nocaching = 0 '\0', o_delete_glue_parent = 0 '\0', o_no_schema_check = 0 '\0', o_ctrlflag = '\0' <repeats 31 times>, o_controls = 0x11d8fdd8, o_authz = {sai_method = 0, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 0, bv_val = 0x0}, sai_ndn = {bv_len = 0, bv_val = 0x0}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, o_ber = 0x0, o_res_ber = 0x0, o_callback = 0x0, o_ctrls = 0x0, o_csn = {bv_len = 0, bv_val = 0x0}, o_private = 0x0, o_next = {stqe_next = 0x12307c00}} (gdb) backtrace full #0 0x0000002a975f21ec in syncprov_op_abandon (op=0x42002b40, rs=0x42002a50) at syncprov.c:1026 on = (slap_overinst *) 0xde1c40 si = (syncprov_info_t *) 0xde2ee0 so = (syncops *) 0x12392240 soprev = (syncops *) 0x12394bd0 #1 0x000000000049b8dd in overlay_op_walk (op=0x42002b40, rs=0x42002a50, which=op_abandon, oi=0xde1e00, on=0xde1c40) at backover.c:640 func = (BI_op_bind **) 0xde1c98 rc = 32768 #2 0x000000000049bb39 in over_op_func (op=0x42002b40, rs=0x42002a50, which=op_abandon) at backover.c:702 oi = (slap_overinfo *) 0xde1e00 on = (slap_overinst *) 0xde1c40 be = (BackendDB *) 0xddf540 db = {bd_info = 0xde1c40, be_ctrls = "\000\001\001\001\000\000\001\000\001\000\001\001\001\000\001", '\0' <repeats 17 times>, "\001", be_flags = 256, 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 = 0xdd7920, be_nsuffix = 0xdd7900, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = {bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 12, bv_val = 0xdd8410 "cn=accesslog"}, be_rootndn = {bv_len = 12, bv_val = 0xdd8490 "cn=accesslog"}, be_rootpw = {bv_len = 0, bv_val = 0x0}, be_max_deref_depth = 15, be_def_limit = { lms_t_soft = -1, lms_t_hard = 0, lms_s_soft = -1, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x0, be_acl = 0x8b0000, be_dfltaccess = ACL_READ, be_replica = 0x0, be_replogfile = 0x0, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0xf35a40, be_pcl_mutex = { __m_reserved = 0, __m_count = 0, __m_owner = 0x0, __m_kind = 0, __m_lock = {__status = 0, __spinlock = 0}}, be_pcl_mutexp = 0xddf680, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0x2a972f0fe0, be_private = 0x889c80, be_next = {stqe_next = 0xde1a80}} cb = {sc_next = 0x0, sc_response = 0x49b297 <over_back_response>, sc_cleanup = 0, sc_private = 0xde1e00} rc = 32768 __PRETTY_FUNCTION__ = "over_op_func" #3 0x000000000049bca7 in over_op_abandon (op=0x42002b40, rs=0x42002a50) at backover.c:760 No locals. #4 0x0000000000450729 in fe_op_abandon (op=0x42002b40, rs=0x42002a50) at abandon.c:115 No locals. #5 0x000000000042b249 in connection_abandon (c=0x12603dd0) at connection.c:792 o = (Operation *) 0x11d8f900 next = (Operation *) 0x0 op = {o_hdr = 0x42002ac0, o_tag = 80, o_time = 0, o_tincr = 0, o_bd = 0x42002830, o_req_dn = {bv_len = 0, bv_val = 0x0}, o_req_ndn = {bv_len = 0, bv_val = 0x0}, o_request = { oq_add = {rs_e = 0x4, rs_modlist = 0x0}, oq_bind = {rb_method = 4, rb_cred = {bv_len = 0, bv_val = 0x0}, rb_edn = {bv_len = 0, bv_val = 0x0}, rb_ssf = 0, rb_tmp_mech = {bv_len = 0, bv_val = 0x0}}, oq_compare = {rs_ava = 0x4}, oq_modify = {rs_modlist = 0x4, rs_increment = 0}, oq_modrdn = {rs_newrdn = {bv_len = 4, bv_val = 0x0}, rs_nnewrdn = {bv_len = 0, bv_val = 0x0}, rs_newSup = 0x0, rs_nnewSup = 0x0, rs_deleteoldrdn = 0}, oq_search = {rs_scope = 4, rs_deref = 0, rs_slimit = 0, rs_tlimit = 0, rs_limit = 0x0, rs_attrsonly = 0, rs_attrs = 0x0, rs_filter = 0x0, rs_filterstr = {bv_len = 0, bv_val = 0x0}}, oq_abandon = {rs_msgid = 4}, oq_cancel = {rs_msgid = 4}, oq_extended = {rs_reqoid = {bv_len = 4, bv_val = 0x0}, rs_flags = 0, rs_reqdata = 0x0}, oq_pwdexop = {rs_extended = {rs_reqoid = {bv_len = 4, bv_val = 0x0}, rs_flags = 0, rs_reqdata = 0x0}, rs_old = {bv_len = 0, bv_val = 0x0}, rs_new = {bv_len = 0, bv_val = 0x0}, rs_mods = 0x0, rs_modtail = 0x0}}, o_abandon = 0, o_cancel = 0, o_groups = 0x0, o_do_not_cache = 0 '\0', o_is_auth_check = 0 '\0', o_nocaching = 0 '\0', o_delete_glue_parent = 0 '\0', o_no_schema_check = 0 '\0', o_ctrlflag = '\0' <repeats 31 times>, o_controls = 0x0, o_authz = { sai_method = 0, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 0, bv_val = 0x0}, sai_ndn = {bv_len = 0, bv_val = 0x0}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, o_ber = 0x0, o_res_ber = 0x0, o_callback = 0x42002810, o_ctrls = 0x0, o_csn = {bv_len = 0, bv_val = 0x0}, o_private = 0x0, o_next = {stqe_next = 0x0}} ohdr = {oh_opid = 0, oh_connid = 583, oh_conn = 0x12603dd0, oh_msgid = 0, oh_protocol = 0, oh_tid = 0, oh_threadctx = 0x0, oh_tmpmemctx = 0x0, oh_tmpmfuncs = 0x0, oh_log_prefix = '\0' <repeats 49 times>} 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} #6 0x000000000042b41c in connection_closing (c=0x12603dd0, why=0x4be9a0 "connection lost") at connection.c:840 sd = 38 __PRETTY_FUNCTION__ = "connection_closing" #7 0x000000000042ca0f in connection_read (s=38, cri=0x42002d90) at connection.c:1457 rc = -2 c = (Connection *) 0x12603dd0 __PRETTY_FUNCTION__ = "connection_read" #8 0x000000000042c1f8 in connection_read_thread (ctx=0x42002e10, argv=0x26) at connection.c:1254 rc = 42 cri = {op = 0x11d8f900, func = 0, arg = 0x0, nullop = 0} s = 38 #9 0x0000002a956c3bd7 in ldap_int_thread_pool_wrapper (xpool=0x88ce10) at tpool.c:478 pool = (struct ldap_int_thread_pool_s *) 0x88ce10 ctx = (ldap_int_thread_ctx_t *) 0xf375d0 ltc_key = {{ltk_key = 0x48717a, ltk_data = 0xe658c0, ltk_free = 0x486f64 <slap_sl_mem_destroy>}, {ltk_key = 0x976100, ltk_data = 0xf, ltk_free = 0x2a971e9cf9 <bdb_locker_id_free>}, {ltk_key = 0x2a971dae1f, ltk_data = 0x159be000, ltk_free = 0x2a971dadff <search_stack_free>}, {ltk_key = 0x976680, ltk_data = 0xf, ltk_free = 0x2a971e9cf9 <bdb_locker_id_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 1107310944 i = 219 keyslot = 219 hash = 219 #10 0x0000003342606137 in ?? () No symbol table info available. #11 0x0000000000000000 in ?? () No symbol table info available. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5455) EntryInfo state not reset if entry_db lock fails
by rein＠basefarm.no 04 Apr '08

04 Apr '08

Full_Name: Rein Tollevik Version: CVS head OS: linux and solaris URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.93.160.250) In bdb_cache_find_id() in servers/slapd/back-bdb/cache.c it decrements the bei_finders of the EntryInfo and resets the loading flag in bei_state. These statements are only run if locking the entry_db succeed, but as they reset state the function has altered they should always be run. I.e, move these statements and the surrounding lock calls out of the block they currently are in. Rein Tollevik Basefarm AS

1 0

Re: (ITS#5454) syncrepl refreshAndPersist stops receiving
by rein＠basefarm.no 04 Apr '08

04 Apr '08

On Thu, 3 Apr 2008, rein(a)basefarm.no wrote: > Our persistent syncrepl consumers stops receiving data after a while, with no > indication of why :-( They don't recognize restarts of the producer, so the > only way to get the replication running again is to restart the consumers. > > So far it looks to me as if the syncrepl thread has managed to return without > adding the connection socket back to slap_daemon.sd_readers. But whether that > is correct or not, and how it has managed to do it if so, I cannot tell. Hm, I hope I have found the race condition that causes this :-) I'm now running with the patch at the end to see if that solves it, only time will tell.. The race is that between the time selecting on the syncrepl socket is enabled by the call to connection_client_enable() and the release of the si_mutex a new message may arrive. If so, the next call to do_syncrepl may fail in its attempt to trylock the mutex and no-one will re-enable selecting on it again. My patch delays enabling of the socket until the mutex has been released, which looks safe to me. Or can the access to si->si_conn without a lock be a problem? Rein Index: OpenLDAP/servers/slapd/syncrepl.c diff -u OpenLDAP/servers/slapd/syncrepl.c:1.9 OpenLDAP/servers/slapd/syncrepl.c:1.10 --- OpenLDAP/servers/slapd/syncrepl.c:1.9 Fri Mar 28 14:25:55 2008 +++ OpenLDAP/servers/slapd/syncrepl.c Fri Apr 4 16:54:05 2008 @@ -1166,6 +1166,7 @@ ber_socket_t s; int i, defer = 1, fail = 0; Backend *be; + int enable_conn = 0; Debug( LDAP_DEBUG_TRACE, "=>do_syncrepl %s\n", si->si_ridtxt, 0, 0 ); @@ -1271,11 +1272,7 @@ * If we failed, tear down the connection and reschedule. */ if ( rc == LDAP_SUCCESS ) { - if ( si->si_conn ) { - connection_client_enable( si->si_conn ); - } else { - si->si_conn = connection_client_setup( s, do_syncrepl, arg ); - } + enable_conn = 1; } else if ( si->si_conn ) { dostop = 1; } @@ -1342,6 +1339,14 @@ ldap_pvt_thread_mutex_unlock( &slapd_rq.rq_mutex ); ldap_pvt_thread_mutex_unlock( &si->si_mutex ); + if ( enable_conn ) { + if ( si->si_conn ) { + connection_client_enable( si->si_conn ); + } else { + si->si_conn = connection_client_setup( s, do_syncrepl, arg ); + } + } + if ( rc ) { if ( fail == RETRYNUM_TAIL ) { Debug( LDAP_DEBUG_ANY,

1 0

Re: (ITS#5452) seg fault in syncprov_op abandon on master
by h.b.furuseth＠usit.uio.no 04 Apr '08

04 Apr '08

Since it crashes on if ( so->s_op->o_connid == op->o_connid && so->s_op->o_msgid == op->orn_msgid ) please try frame 0 print *op print *so->s_op and maybe backtrace full while you are at it. -- Hallvard

1 0

Re: (ITS#5454) syncrepl refreshAndPersist stops receiving
by rein＠basefarm.no 04 Apr '08

04 Apr '08

On Fri, 4 Apr 2008, Howard Chu wrote: > rein(a)basefarm.no wrote: >> So far it looks to me as if the syncrepl thread has managed to return >> without >> adding the connection socket back to slap_daemon.sd_readers. But whether >> that >> is correct or not, and how it has managed to do it if so, I cannot tell. > > Since you're working with HEAD ... Were there any write operations on > cn=config just before the hang? (Thinking it may be connected to the > SYNC_PAUSED handling at line 1303, except any subsequent request would wake > up the listener anyway.) No, the config backend isn't even configured into the server. I have also tried without the auditlog just to make sure that wasn't involved, but it happend anyhow. We have also added a linux server on one of the sites to see if the problem is related to solaris. So far it hasn't stopped receiving updates, but is has only run since last evening so it is far too early to conclude anything. Rein

1 0

Re: (ITS#5454) syncrepl refreshAndPersist stops receiving
by hyc＠symas.com 04 Apr '08

04 Apr '08

rein(a)basefarm.no wrote: > So far it looks to me as if the syncrepl thread has managed to return without > adding the connection socket back to slap_daemon.sd_readers. But whether that > is correct or not, and how it has managed to do it if so, I cannot tell. Since you're working with HEAD ... Were there any write operations on cn=config just before the hang? (Thinking it may be connected to the SYNC_PAUSED handling at line 1303, except any subsequent request would wake up the listener anyway.) > Any pointers as to what can be wrong are highly appreciated. I have a core file > from a server that has stopped receiving if there is anything I should look for > there. > > Rein Tollevik > Basefarm AS > > > -- -- 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#5444) slapd seg. fault using mulitmirrored mode
by ando＠sys-net.it 03 Apr '08

03 Apr '08

hyc(a)symas.com wrote: > OK, I've reproduced the crash and patched it in HEAD, and added a consumer > write to the test050 script. Please test. Works for me. Thanks, p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5452) seg fault in syncprov_op abandon on master
by quanah＠zimbra.com 03 Apr '08

03 Apr '08

--On Thursday, April 03, 2008 6:41 PM +0000 quanah(a)zimbra.com wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.3.41 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (24.23.156.219) > > > Core was generated by `/opt/zimbra/openldap/libexec/slapd -l LOCAL0 -4 -u > zimbra -h ldap://'. also: (gdb) print so $1 = (syncops *) 0x12392240 (gdb) print *so $2 = {s_next = 0x12393510, s_base = {bv_len = 12, bv_val = 0x1238dd50 "cn=accesslog"}, s_eid = 1, s_op = 0x11d8fc00, s_rid = 100, s_filterstr = {bv_len = 0, bv_val = 0x0}, s_flags = 1, s_inuse = 1, s_res = 0x0, s_restail = 0x0, s_qtask = 0x0, s_mutex = {__m_reserved = 0, __m_count = 0, __m_owner = 0x0, __m_kind = 0, __m_lock = {__status = 0, __spinlock = 0}}} from frame 0. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

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 2008