openldap-bugs

openldap-bugs@openldap.org

1 participants
20963 discussions

Re: (ITS#7197) olcTLSVerifyClient missing options
by quanah＠zimbra.com 04 Apr '12

04 Apr '12

--On Sunday, March 04, 2012 8:40 PM +0000 quanah(a)OpenLDAP.org wrote: see also <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=658749> --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

Re: (ITS#7224) Core dump while trying to run slapd
by ashish＠sendmail.com 04 Apr '12

04 Apr '12

(gdb) p oc $1 = (ObjectClass *) 0x7b91460 (gdb) p *oc $2 = {soc_oclass = {oc_oid = 0x7b910e0 "1.3.6.1.4.1.6152.10.3.2.16", oc_names = 0x0, oc_desc = 0x0, oc_obsolete = 0, oc_sup_oids = 0x0, oc_kind = 1, oc_at_oids_must = 0x0, oc_at_oids_may = 0x0, oc_extensions = 0x0}, soc_cname = {bv_len = 26, bv_val = 0x7b910e0 "1.3.6.1.4.1.6152.10.3.2.16"}, soc_sups = 0x7b91110, soc_required = 0x7b91130, soc_allowed = 0x0, soc_check = 0, soc_oidmacro = 0x0, soc_flags = 0, soc_next = {stqe_next = 0x7b92d40}} (gdb) p names $3 = (char **) 0x0 (gdb) p *names Cannot access memory at address 0x0

1 0

Re: (ITS#7222) Slapd hangs on high load
by hrvoje.habjanic＠zg.t-com.hr 04 Apr '12

04 Apr '12

On 03.04.2012 17:41, Howard Chu wrote: > > You may be able to avoid this bug by using an alternate malloc > library, such as Google tcmalloc. > Hi. I did try - using tcmalloc. And this time, i got SIGSEGV. Odd thing is that this happened in "pthread_mutex_lock" which is in libpthread.so ...? Another bug in centos libs? I would appreciate if you could take a look. Thx. H. p.s. url -> http://free-zg.t-com.hr/HrvojeHabjanic/hang3.log

1 0

Re: (ITS#7182) back-ldap monitoring improvements
by hyc＠symas.com 04 Apr '12

04 Apr '12

hyc(a)symas.com wrote: > Ondrej Kuznik wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 03/27/2012 01:30 PM, hyc(a)symas.com wrote: >>> ondrej.kuznik(a)acision.com wrote: >>>> Full_Name: Ondrej Kuznik >>>> Version: HEAD >>>> OS: Linux >>>> >>> I have pushed patches 1-3 to git master. patch 4 seems to require additional work. >> >> I have reworked the remaining patches according to your suggestions, the >> resulting patchset is at: >> ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20120329-back-ldap-monitoring… > > Committed to master, thanks for the patches. See ITS#7225. Even after the SEGV is patched, the pcache slapd fails to start in test020 because the monitor calls are unable to register their entries. Something is wrong in your initialization code. Also, you're using monitor_entry_stub() directly in the back-ldap code. It is forbidden for modules to directly reference each other's symbols. If you need this function, add it to monitor_extra_t first and call it through there. -- -- 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#7225) back-monitor/ldap crash in test020-proxycache
by h.b.furuseth＠usit.uio.no 04 Apr '12

04 Apr '12

Full_Name: Hallvard B Furuseth Version: master, fc1396fa2e94ee2e752fd7c3ea5bb22f6592398a OS: Linux x86_64 URL: Submission from: (NULL) (129.240.203.186) Submitted by: hallvard back-ldap:ldap_back_monitor_conn_init() calls monitor_back_register_entry_attrs(,,,nbase=NULL,,) which crashes at: 1093 if ( !BER_BVISNULL( nbase ) ) { That checks if nbase->bv_val is NULL, it does not check nbase itself. Backtrace: #0 monitor_back_register_entry_attrs (ndn_in=0x1023d50, a=0x1092be8, cb=0x10f59b0, nbase=0x0, scope=0, filter=0x0) at init.c:1093 #1 ldap_back_monitor_conn_init (be=0x104d0c0, ms=0x1023d28) at monitor.c:658 #2 monitor_back_db_open (be=0x104d0c0, cr=0x7fff704846e0) at init.c:2365 #3 backend_startup_one (be=0x104d0c0, cr=0x7fff704846e0) at backend.c:224 #4 backend_startup (be=0x104d0c0) at backend.c:325 #5 slap_startup (be=0x0) at init.c:219

1 0

Re: (ITS#7222) Slapd hangs on high load
by hrvoje.habjanic＠zg.t-com.hr 04 Apr '12

04 Apr '12

On 03.04.2012 17:41, Howard Chu wrote: >> >> So, am i doing something wrong or openldap is...? > > > Looks like your glibc malloc is deadlocked. A Centos bug, not an > OpenLDAP bug. > > In the trace, you could confirm this in gdb with: > thread 13 > frame 3 > print *mutex > > most likely the "owner" field of this mutex will be 1502, which > corresponds to thread 17, which is waiting for a lock inside libc > malloc/free. > > You may be able to avoid this bug by using an alternate malloc > library, such as Google tcmalloc. > Hi. Thanx for inside info ... :-) And sorry that i was unable to provide more info - core dump alone is 16gb! Also, small sidenote - when this "hang" happens, it only affects existing connections - i'm attacking it with two procesess, each 4 connection. New searches using ldapsearch work fine ... And correction for typo - by "high load" i wrote (1-2 req/sec) - actually it should write 1-2k reg/sec ... What is interesting regarding this, that this "problem" goes back to db-4.7 and openldap-2.4.23 (provided with centos) ... I'll try alternate malloc and report back ... H.

1 0

Re: (ITS#7224) Core dump while trying to run slapd
by masarati＠aero.polimi.it 04 Apr '12

04 Apr '12

On 04/04/2012 02:39 AM, ashish(a)sendmail.com wrote: > Full_Name: Ashish Gawarikar > Version: 2.4.30 > OS: Redhat 5.8 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (108.80.56.188) > > > I got a core dump while trying to run slapd: > > This is the stack trace of the core: > > (gdb) where > #0 oc_delete_names (oc=0xeaa6080) at oc.c:403 > #1 0x0000000000461aa7 in oc_destroy () at oc.c:470 > #2 0x000000000045128e in schema_destroy () at schema_init.c:6846 > #3 0x00000000004050bf in main (argc=<value optimized out>, argv=0x7fff1b533918) > at main.c:1068 > > > A similar stack trace was produced while trying to do slapadd: > > #0 oc_delete_names (oc=0x171e86f0) at oc.c:403 > #1 0x0000000000461aa7 in oc_destroy () at oc.c:470 > #2 0x000000000045128e in schema_destroy () at schema_init.c:6846 > #3 0x0000000000486ecd in slap_tool_destroy () at slapcommon.c:942 > #4 0x0000000000485f73 in slapadd (argc=<value optimized out>, argv=<value > optimized out>) at slapadd.c:493 > #5 0x0000000000404f32 in main (argc=3, argv=0x7fffa4770db8) at main.c:410 > > > These are the configuration params: > --enable-accesslog --enable-auditlog --enable-collect --enable-constraint > --enable-dyngroup --enable-dynlist --enable-hdb --enable-memberof > --enable-ppolicy --enable-refint --enable-relay --enable-retcode --enable-rwm > --enable-seqmod --enable-translucent --enable-unique --enable-valsort > --enable-slapd --disable-mdb --enable-bdb --enable-proctitle --enable-ldap > --enable-meta --enable-rewrite --enable-monitor --enable-aci --enable-cleartext > --enable-crypt --enable-debug --enable-local --enable-lmpasswd > --enable-proxycache --with-threads --enable-static --disable-shared > --enable-local --enable-syslog --localstatedir=/var --sysconfdir=/etc/mail > --enable-ipv6 --with-cyrus-sasl --enable-spasswd --with-tls > > > Please let me know if you need more information. Con you provide: p oc p *oc p names p *names Thanks, p. -- Pierangelo Masarati Associate Professor Dipartimento di Ingegneria Aerospaziale Politecnico di Milano

1 0

(ITS#7224) Core dump while trying to run slapd
by ashish＠sendmail.com 03 Apr '12

03 Apr '12

Full_Name: Ashish Gawarikar Version: 2.4.30 OS: Redhat 5.8 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (108.80.56.188) I got a core dump while trying to run slapd: This is the stack trace of the core: (gdb) where #0 oc_delete_names (oc=0xeaa6080) at oc.c:403 #1 0x0000000000461aa7 in oc_destroy () at oc.c:470 #2 0x000000000045128e in schema_destroy () at schema_init.c:6846 #3 0x00000000004050bf in main (argc=<value optimized out>, argv=0x7fff1b533918) at main.c:1068 A similar stack trace was produced while trying to do slapadd: #0 oc_delete_names (oc=0x171e86f0) at oc.c:403 #1 0x0000000000461aa7 in oc_destroy () at oc.c:470 #2 0x000000000045128e in schema_destroy () at schema_init.c:6846 #3 0x0000000000486ecd in slap_tool_destroy () at slapcommon.c:942 #4 0x0000000000485f73 in slapadd (argc=<value optimized out>, argv=<value optimized out>) at slapadd.c:493 #5 0x0000000000404f32 in main (argc=3, argv=0x7fffa4770db8) at main.c:410 These are the configuration params: --enable-accesslog --enable-auditlog --enable-collect --enable-constraint --enable-dyngroup --enable-dynlist --enable-hdb --enable-memberof --enable-ppolicy --enable-refint --enable-relay --enable-retcode --enable-rwm --enable-seqmod --enable-translucent --enable-unique --enable-valsort --enable-slapd --disable-mdb --enable-bdb --enable-proctitle --enable-ldap --enable-meta --enable-rewrite --enable-monitor --enable-aci --enable-cleartext --enable-crypt --enable-debug --enable-local --enable-lmpasswd --enable-proxycache --with-threads --enable-static --disable-shared --enable-local --enable-syslog --localstatedir=/var --sysconfdir=/etc/mail --enable-ipv6 --with-cyrus-sasl --enable-spasswd --with-tls Please let me know if you need more information.

1 0

Re: (ITS#7219) back-mdb crash when used as accesslog
by quanah＠zimbra.com 03 Apr '12

03 Apr '12

--On Friday, March 30, 2012 11:37 PM +0000 quanah(a)OpenLDAP.org wrote: How to reproduce: What I do is run the add/del of 50k entries used in ITS#7210 5-6 times to > get a reasonably sized accesslog. Initially, I have the log purge set to > run once a day, deleting anything a week old (so nothing gets deleted). > > Then I change the logpurge to "00+00:10 00+00:05". > > After this, slapd dies from hitting the assert. -- 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#7223) back-mdb: accesslog segv on second cleanup run
by quanah＠OpenLDAP.org 03 Apr '12

03 Apr '12

Full_Name: Quanah Gibson-Mount Version: RE24 4/1/2012 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.108.184.39) If you have an accesslog setup using back-mdb, it will segv in the following condition: Do a bunch of modifications, and then set up accesslog to clean them out periodically. In my test, I had it so that the accesslog DB was cleaned every 5 minutes, of any entries > 10 minutes old. Initially I had it set to clean up everything > 1 week old, running once a day, so I could gather data in the accesslog DB without triggering the purge. The first cleanup ran @ 5 minutes, and removed all entries from the accesslog DB, as they were all older than 10 minutes. The second run, with the now empty DB, triggered a SEGV: Program terminated with signal 11, Segmentation fault. #0 0x00007f38dfeb17b0 in mdb_page_alloc (mc=0xd3d8a80, num=1) at ./../../../libraries/libmdb/mdb.c:1317 1317 ./../../../libraries/libmdb/mdb.c: No such file or directory. in ./../../../libraries/libmdb/mdb.c #0 0x00007f38dfeb17b0 in mdb_page_alloc (mc=0xd3d8a80, num=1) at ./../../../libraries/libmdb/mdb.c:1317 txn = 0xd3ce000 np = 0x323d747261745371 pgno = 69385 mid = {mid = 139710414625424, mptr = 0x7f38dfeb5cdf} #1 0x00007f38dfeb18c6 in mdb_page_touch (mc=0xd3d8a80) at ./../../../libraries/libmdb/mdb.c:1349 np = 0xd3f2000 mp = 0x7f24f0114000 pgno = 69525 __PRETTY_FUNCTION__ = "mdb_page_touch" #2 0x00007f38dfeb7bc7 in mdb_cursor_touch (mc=0xd3d8a80) at ./../../../libraries/libmdb/mdb.c:4116 rc = 0 #3 0x00007f38dfeb93dd in mdb_cursor_del (mc=0xd3d8a80, flags=0) at ./../../../libraries/libmdb/mdb.c:4486 leaf = 0x0 rc = 0 #4 0x00007f38dfeaec65 in mdb_idl_delete_keys (cursor=0xd3d8a80, keys=0x3782c08, id=64) at idl.c:597 rc = 0 k = 0 key = {mv_size = 5, mv_data = 0x3782c30} data = {mv_size = 8, mv_data = 0x7f24f012c068} lo = 5 hi = 139706696817899 tmp = 40 i = 0x7f24f012c010 err = 0x7f38dfec37f4 "c_get" __PRETTY_FUNCTION__ = "mdb_idl_delete_keys" #5 0x00007f38dfea4faf in indexer (op=0x7f10dda2a440, txn=0xd3ce000, ai=0x12172c0, ad=0x11b87c0, atname=0x11e9028, vals=0x3782b48, id=64, opid=2, mask=4) at index.c:219 rc = 0 i = 26075136 keys = 0x3782c08 mc = 0xd3d8a80 keyfunc = 0x7f38dfeaea37 <mdb_idl_delete_keys> err = 0x7f38dfec27ea "c_open" __PRETTY_FUNCTION__ = "indexer" #6 0x00007f38dfea5363 in index_at_values (op=0x7f10dda2a440, txn=0xd3ce000, ad=0x11b87c0, type=0x11e8fc0, tags=0x11b87e0, vals=0x3782b48, id=64, opid=2) at index.c:337 rc = 0 mask = 4 ixop = 2 ai = 0x12172c0 #7 0x00007f38dfea54e7 in mdb_index_values (op=0x7f10dda2a440, txn=0xd3ce000, desc=0x11b87c0, vals=0x3782b48, id=64, opid=2) at index.c:386 rc = 0 #8 0x00007f38dfea59af in mdb_index_entry (op=0x7f10dda2a440, txn=0xd3ce000, opid=2, e=0x37823c8) at index.c:558 rc = 0 ap = 0x3782620 #9 0x00007f38dfe994ae in mdb_delete (op=0x7f10dda2a440, rs=0x7f10dda2a2b0) at delete.c:348 mdb = 0x18de000 pdn = {bv_len = 12, bv_val = 0xd5bec20 "cn=accesslog"} e = 0x37823c8 p = 0x3782158 manageDSAit = 0 children = 0x11b8ec0 entry = 0x11b8f00 txn = 0xd3ce000 mc = 0xd3d8a80 opinfo = {moi_oe = {oe_next = {sle_next = 0x0}, oe_key = 0x18de000}, moi_txn = 0xd3ce000, moi_ref = 1, moi_flag = 0 '\000'} moi = 0x7f10dda29ed0 preread_ctrl = 0x0 ctrls = {0x0, 0xfffffffffffffff9, 0x7f10dda29f10, 0x0, 0x0, 0x4} num_ctrls = 0 parent_is_glue = 0 parent_is_leaf = 0 __PRETTY_FUNCTION__ = "mdb_delete" #10 0x00000000004d4a48 in overlay_op_walk (op=0x7f10dda2a440, rs=0x7f10dda2a2b0, which=op_delete, oi=0x166d680, on=0x0) at backover.c:671 func = 0x7f38e00c7d18 rc = 32768 #11 0x00000000004d4c86 in over_op_func (op=0x7f10dda2a440, rs=0x7f10dda2a2b0, which=op_delete) at backover.c:723 oi = 0x166d680 on = 0x1706f00 be = 0x11ee9c0 db = {bd_info = 0x7f38e00c7cc0, bd_self = 0x11ee9c0, be_ctrls = "\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001\000\000\001", '\000' <repeats 14 times>, "\001", be_flags = 2312, 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 = 0x1687840, be_nsuffix = 0x1687820, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = { bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 9, bv_val = 0x16766d0 "cn=config"}, be_rootndn = {bv_len = 9, bv_val = 0x16766b0 "cn=config"}, 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 = 0x16a0e00, 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 = 0x14bf900, be_pcl_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = { __prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0x7f38e00c7ac0, be_private = 0x18de000, be_next = {stqe_next = 0x11ef6c0}} cb = {sc_next = 0x7f38dfa51c60, sc_response = 0x4d3780 <over_back_response>, sc_cleanup = 0, sc_private = 0x166d680} sc = 0x7f10dda2a578 rc = 32768 __PRETTY_FUNCTION__ = "over_op_func" #12 0x00000000004d4e6f in over_op_delete (op=0x7f10dda2a440, rs=0x7f10dda2a2b0) at backover.c:780 No locals. #13 0x00007f38df847f61 in accesslog_purge (ctx=0x7f10dda2ab50, arg=0x1298000) at accesslog.c:689 i = 62 rtask = 0x1298000 li = 0x17ea090 conn = {c_struct_state = SLAP_C_UNINITIALIZED, c_conn_state = SLAP_C_INVALID, c_conn_idx = -1, c_sd = 0, c_close_reason = 0x0, c_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, c_sb = 0x0, c_starttime = 0, c_activitytime = 0, c_connid = 18446744073709551615, c_peer_domain = {bv_len = 0, bv_val = 0x4f9d90 ""}, c_peer_name = {bv_len = 0, bv_val = 0x4f9d90 ""}, c_listener = 0x501ca0, c_sasl_bind_mech = {bv_len = 0, bv_val = 0x0}, c_sasl_dn = {bv_len = 0, bv_val = 0x0}, c_sasl_authz_dn = {bv_len = 0, bv_val = 0x0}, c_authz_backend = 0x0, c_authz_cookie = 0x0, c_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}, c_protocol = 0, c_ops = {stqh_first = 0x0, stqh_last = 0x0}, c_pending_ops = {stqh_first = 0x0, stqh_last = 0x0}, c_write1_mutex = { __data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, c_write1_cv = {__data = {__lock = 0, __futex = 0, __total_seq = 0, __wakeup_seq = 0, __woken_seq = 0, __mutex = 0x0, __nwaiters = 0, __broadcast_seq = 0}, __size = '\000' <repeats 47 times>, __align = 0}, c_write2_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = { __prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, c_write2_cv = {__data = {__lock = 0, __futex = 0, __total_seq = 0, __wakeup_seq = 0, __woken_seq = 0, __mutex = 0x0, __nwaiters = 0, __broadcast_seq = 0}, __size = '\000' <repeats 47 times>, __align = 0}, c_currentber = 0x0, c_writers = 0, c_writing = 0 '\000', c_sasl_bind_in_progress = 0 '\000', c_writewaiter = 0 '\000', c_is_tls = 0 '\000', c_needs_tls_accept = 0 '\000', c_sasl_layers = 0 '\000', c_sasl_done = 0 '\000', c_sasl_authctx = 0x0, c_sasl_sockctx = 0x0, c_sasl_extra = 0x0, c_sasl_bindop = 0x0, c_pagedresults_state = {ps_be = 0x0, ps_size = 0, ps_count = 0, ps_cookie = 0, ps_cookieval = {bv_len = 0, bv_val = 0x0}}, c_n_ops_received = 0, c_n_ops_executing = 0, c_n_ops_pending = 0, c_n_ops_completed = 0, c_n_get = 0, c_n_read = 0, c_n_write = 0, c_extensions = 0x0, c_clientfunc = 0, c_clientarg = 0x0, c_send_ldap_result = 0x454a15 <slap_send_ldap_result>, c_send_search_entry = 0x45571d <slap_send_search_entry>, c_send_search_reference = 0x457c43 <slap_send_search_reference>, c_send_ldap_extended = 0x45527c <slap_send_ldap_extended>, c_send_ldap_intermediate = 0x4554fa <slap_send_ldap_intermediate>} opbuf = {ob_op = {o_hdr = 0x7f10dda2a5b0, o_tag = 74, o_time = 1333399445, o_tincr = 0, o_bd = 0x7f10dda2a0c0, o_req_dn = {bv_len = 44, bv_val = 0xd5bec30 "reqStart=20120402202935.000125Z,cn=accesslog"}, o_req_ndn = {bv_len = 44, bv_val = 0xd5bec00 "reqStart=20120402202935.000125Z,cn=accesslog"}, o_request = {oq_add = {rs_modlist = 0x1, rs_e = 0xffffffffffffffff}, oq_bind = {rb_method = 1, rb_cred = {bv_len = 18446744073709551615, bv_val = 0x0}, rb_edn = {bv_len = 1, bv_val = 0x75cd60 "\003"}, rb_ssf = 3718423536, rb_mech = {bv_len = 27, bv_val = 0x3780008 "p\240\242\335\020\177"}}, oq_compare = {rs_ava = 0x1}, oq_modify = { rs_mods = {rs_modlist = 0x1, rs_no_opattrs = -1 '\377'}, rs_increment = 0}, oq_modrdn = {rs_mods = {rs_modlist = 0x1, rs_no_opattrs = -1 '\377'}, rs_deleteoldrdn = 0, rs_newrdn = {bv_len = 1, bv_val = 0x75cd60 "\003"}, rs_nnewrdn = {bv_len = 139710414627824, bv_val = 0x1b <Address 0x1b out of bounds>}, rs_newSup = 0x3780008, rs_nnewSup = 0x0}, oq_search = {rs_scope = 1, rs_deref = 0, rs_slimit = -1, rs_tlimit = -1, rs_limit = 0x0, rs_attrsonly = 1, rs_attrs = 0x75cd60, rs_filter = 0x7f10dda2a3f0, rs_filterstr = {bv_len = 27, bv_val = 0x3780008 "p\240\242\335\020\177"}}, oq_abandon = {rs_msgid = 1}, oq_cancel = {rs_msgid = 1}, oq_extended = {rs_reqoid = {bv_len = 1, bv_val = 0xffffffffffffffff <Address 0xffffffffffffffff out of bounds>}, rs_flags = 0, rs_reqdata = 0x1}, oq_pwdexop = { rs_extended = {rs_reqoid = {bv_len = 1, bv_val = 0xffffffffffffffff <Address 0xffffffffffffffff out of bounds>}, rs_flags = 0, rs_reqdata = 0x1}, rs_old = { bv_len = 7720288, bv_val = 0x7f10dda2a3f0 "\246"}, rs_new = {bv_len = 27, bv_val = 0x3780008 "p\240\242\335\020\177"}, rs_mods = 0x0, rs_modtail = 0x0}}, o_abandon = 0, o_cancel = 0, o_groups = 0x0, o_do_not_cache = 0 '\000', o_is_auth_check = 0 '\000', o_dont_replicate = 1 '\001', o_acl_priv = ACL_NONE, o_nocaching = 0 '\000', o_delete_glue_parent = 0 '\000', o_no_schema_check = 0 '\000', o_no_subordinate_glue = 0 '\000', o_ctrlflag = '\000' <repeats 31 times>, o_controls = 0x7f10dda2a6f8, o_authz = {sai_method = 0, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 9, bv_val = 0x16766d0 "cn=config"}, sai_ndn = {bv_len = 9, bv_val = 0x16766b0 "cn=config"}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, o_ber = 0x0, o_res_ber = 0x0, o_callback = 0x37820b0, o_ctrls = 0x0, o_csn = {bv_len = 40, bv_val = 0x7f10dda2aac0 "20120402203319.698132Z#000000#000#000000\v\336C"}, o_private = 0x0, o_extra = {slh_first = 0x7f10dda29ed0}, o_next = {stqe_next = 0x0}}, ob_hdr = {oh_opid = 0, oh_connid = 18446744073709551615, oh_conn = 0x7f10dda2a800, oh_msgid = 0, oh_protocol = 0, oh_tid = 139710414632704, oh_threadctx = 0x7f10dda2ab50, oh_tmpmemctx = 0x1651a00, oh_tmpmfuncs = 0x75d320, oh_counters = 0x7607a0, oh_log_prefix = "conn=-1 op=0", '\000' <repeats 243 times>}, ob_controls = {0x0 <repeats 32 times>}} op = 0x7f10dda2a440 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_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} cb = {sc_next = 0x0, sc_response = 0x7f38df84787e <log_old_lookup>, sc_cleanup = 0, sc_private = 0x7f10dda2a360} f = {f_choice = 166, f_un = {f_un_result = -576543792, f_un_desc = 0x7f10dda2a3d0, f_un_ava = 0x7f10dda2a3d0, f_un_ssa = 0x7f10dda2a3d0, f_un_mra = 0x7f10dda2a3d0, f_un_complex = 0x7f10dda2a3d0}, f_next = 0x0} ava = {aa_desc = 0x1251240, aa_value = {bv_len = 15, bv_val = 0x7f10dda2ab00 "20120402203405Z"}} pd = {slots = 100000, used = 100000, dn = 0xe3b8000, ndn = 0xe588000, csn = {bv_len = 40, bv_val = 0x7f10dda2aac0 "20120402203319.698132Z#000000#000#000000\v\336C"}} timebuf = "20120402203405Z\000\241\210\001\000\000" csnbuf = "20120402203319.698132Z#000000#000#000000\v\336C\000\000\000\000\000\366\250\322\343\070\177\000\000\000\000\000\000\002\000\000" old = 1333398845 __PRETTY_FUNCTION__ = "accesslog_purge" #14 0x00007f38e51e9cc9 in ldap_int_thread_pool_wrapper (xpool=0x11d21c0) at tpool.c:688 pool = 0x11d21c0 task = 0x14ca440 work_list = 0x11d2258 ctx = {ltu_id = 139710414632704, ltu_key = {{ltk_key = 0x4b380b, ltk_data = 0x1651a00, ltk_free = 0x4b3630 <slap_sl_mem_destroy>}, {ltk_key = 0x317c000, ltk_data = 0x14cc000, ltk_free = 0x7f38dfeac523 <mdb_reader_free>}, {ltk_key = 0x347e000, ltk_data = 0x14cf400, ltk_free = 0x7f38dfeac523 <mdb_reader_free>}, {ltk_key = 0x7f38dfea23c4, ltk_data = 0x3e80000, ltk_free = 0x7f38dfea23a1 <search_stack_free>}, {ltk_key = 0x7f38dfe9fda9, ltk_data = 0x3880000, ltk_free = 0x7f38dfe9fd61 <scope_chunk_free>}, { ltk_key = 0x43d3cd, ltk_data = 0x167ae00, ltk_free = 0x43d211 <conn_counter_destroy>}, {ltk_key = 0x459151, ltk_data = 0x16fc800, ltk_free = 0x4590a4 <slap_op_q_destroy>}, { ltk_key = 0x0, ltk_data = 0xd5d1600, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 24 times>}} kctx = 0x0 i = 32 keyslot = 965 hash = 2784641989 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #15 0x00007f38e3d259ca in start_thread () from /lib/libpthread.so.0 No symbol table info available. #16 0x00007f38e3a8270d in clone () from /lib/libc.so.6 No symbol table info available. #17 0x0000000000000000 in ?? () No symbol table info available.

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