Full_Name: Toby Blake Version: 2.3.38 OS: Fedora Core 5/6 URL: Submission from: (NULL) (129.215.218.33) While running slapd as a proxy-caching server, it sometimes falls over with a signal 11 segfault. I haven't been able to reproduce this and it can occur when the system is quiet and nothing much running.... Core was generated by `/usr/sbin/slapd -h ldap:///'. Program terminated with signal 11, Segmentation fault. #0 0x008314f3 in strcasecmp () from /lib/libc.so.6 Here's the db portion of slapd.conf: database ldap suffix dc=inf,dc=ed,dc=ac,dc=uk rootdn uid=ldaprep/clive.inf.ed.ac.uk,cn=inf.ed.ac.uk,cn=gssapi,cn=auth uri "ldap://testdir.inf.ed.ac.uk/" idassert-bind mode=none bindmethod=sasl saslmech=GSSAPI idassert-authzFrom "dn:*" overlay pcache proxycache bdb 5000 2 500 300 proxycachequeries 10000 proxyattrset 0 uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos description objectClass afsHomeDirectory primaryRoles secondary Roles proxyattrset 1 cn userPassword memberUid uniqueMember gidNumber nisNe tgroupTriple memberNisNetgroup objectClass proxytemplate (uid=) 0 1800 1800 proxytemplate (&(objectClass=)(uid=)) 0 1800 1800 proxytemplate (&(objectClass=)(cn=)) 1 1800 1800 proxytemplate (&(objectClass=)(|(memberUid=)(uniqueMember=))) 0 1800 1800 proxytemplate (&(objectClass=)(uniqueMember=)) 0 1800 1800 proxytemplate (&(objectClass=)(memberUid=)) 0 1800 1800 proxytemplate (&(objectClass=)(uidNumber=)) 0 1800 1800 proxytemplate (&(objectClass=)(gidNumber=)) 1 1800 1800 directory /var/openldap-data dbconfig set_cachesize 0 16777216 1 dbconfig set_lg_regionmax 262144 dbconfig set_lg_bsize 2097152 include /etc/openldap/slapd.conf.indices And, here's the full backtrace from gdb... #0 0x008314f3 in strcasecmp () from /lib/libc.so.6 No symbol table info available. #1 0x0809c83d in an_find (a=0xb0c412d0, s=0xad1f8994) at ad.c:842 No locals. #2 0x08117321 in pcache_op_search (op=0xb0c271b8, rs=0xad6f91c4) at pcache.c:1150 cb = <value optimized out> on = (slap_overinst *) 0x8a4f9d0 cm = (cache_manager *) 0x8a4fac0 qm = (query_manager *) 0x8a6aed8 i = <value optimized out> filter_attrs = (AttributeName *) 0xad1f896c query = {filter = 0xb0c3d178, attrs = 0xb0c411b8, save_attrs = 0xad1f88cc, base = {bv_len = 24, bv_val = 0xad1f81e4 "dc=inf,dc=ed,dc=ac,dc=uk"}, scope = 2} attr_set = 0 template_id = 3 answerable = <value optimized out> cacheable = 1 fattr_cnt = 3 fattr_got_oc = 1 tempstr = {bv_len = 47, bv_val = 0xad1f88fc "(&(objectClass=)(|(memberUid=)(uniqueMember=)))"} #3 0x080bb404 in overlay_op_walk (op=0xb0c271b8, rs=0xad6f91c4, which=op_search, oi=0x8a4f8e0, on=0x8a4f9d0) at backover.c:639 rc = -1329434184 #4 0x080bb89d in over_op_func (op=0xb0c271b8, rs=0xad6f91c4, which=op_search) at backover.c:701 oi = (slap_overinfo *) 0x8a4f8e0 on = (slap_overinst *) 0x8a4f9d0 be = (BackendDB *) 0x8a4f4c8 db = {bd_info = 0x8a4f9d0, be_ctrls = "\000", '\001' <repeats 14 times>, '\0' <repeats 17 times>, "\001", be_flags = 257, 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 = 0x8a6af10, be_nsuffix = 0x8a6ade0, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = {bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 64, bv_val = 0x8a4f838 "uid=ldaprep/clive.inf.ed.ac.uk,cn=inf.ed.ac.uk,cn=gssapi,cn=auth"}, be_rootndn = {bv_len = 64, bv_val = 0x8a4f898 "uid=ldaprep/clive.inf.ed.ac.uk,cn=inf.ed.ac.uk,cn=gssapi,cn=auth"}, be_rootpw = {bv_len = 0, bv_val = 0x0}, be_max_deref_depth = 15, be_def_limit = {lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 24576, 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 = 0x8a6a6c0, 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 = 0x8aa4820, be_pcl_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __kind = 0, __nusers = 0, {__spins = 0, __list = {__next = 0x0}}}, __size = '\0' <repeats 23 times>, __align = 0}, be_pcl_mutexp = 0x8a4f598, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0x81cd360, be_private = 0x8a4f5d0, be_next = {stqe_next = 0x0}} cb = {sc_next = 0x0, sc_response = 0x80bb180 <over_back_response>, sc_cleanup = 0, sc_private = 0x8a4f8e0} rc = 0 __PRETTY_FUNCTION__ = "over_op_func" #5 0x0806316f in fe_op_search (op=0xb0c271b8, rs=0xad6f91c4) at search.c:355 entry = (Entry *) 0xad6f8118 bd = (BackendDB *) 0x81d1240 #6 0x08063b21 in do_search (op=0xb0c271b8, rs=0xad6f91c4) at search.c:217 base = {bv_len = 24, bv_val = 0xb0c40440 "dc=inf,dc=ed,dc=ac,dc=uk"} siz = 1 i = 1 #7 0x080611f9 in connection_operation (ctx=0xad6f9238, arg_v=0xb0c271b8) at connection.c:1133 curelm = <value optimized out> rc = <value optimized out> 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 *) 0xb6885288 memctx = (void *) 0x8b0c630 memctx_null = (void *) 0x0 __PRETTY_FUNCTION__ = "connection_operation" #8 0x08131fd3 in ldap_int_thread_pool_wrapper (xpool=0x8a324f8) at tpool.c:478 ctx = (ldap_int_thread_ctx_t *) 0xb0c16600 ltc_key = {{ltk_key = 0x80ac320, ltk_data = 0x8b0c630, ltk_free = 0x80ac210 <slap_sl_mem_destroy>}, {ltk_key = 0x8aa5430, ltk_data = 0x9b, ltk_free = 0x80e9550 <bdb_locker_id_free>}, { ltk_key = 0x80c9170, ltk_data = 0xac9f7008, ltk_free = 0x80c9230 <search_stack_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 29 times>} tid = 2909772688 i = 583 hash = <value optimized out> #9 0x0093945b in start_thread () from /lib/libpthread.so.0 No symbol table info available. #10 0x0089123e in clone () from /lib/libc.so.6 No symbol table info available. (gdb) Please let me know if any more deugging information would be useful. Cheers Toby Blake University of Edinburgh
> While running slapd as a proxy-caching server, it sometimes falls over > with a > signal 11 segfault. I haven't been able to reproduce this and it can > occur when > the system is quiet and nothing much running.... I think this issue has been already fixed, incidentally, in HEAD/re24, but went unnoticed in re23. You should replace the call to ch_malloc() that's around line 1140 in servers/slapd/overlays/pcache.c with a call to ch_calloc(); something like *new_attrs = (AttributeName*)ch_calloc( count + 1, sizeof(AttributeName)); (sorry, I can't access the network right now but by webmail). In fact, right now, the array of AttributeName "new_attrs" is accessed by an_find() while not yet NULL terminated. Please check and report (to create the problem, you need to use filters that contain the attributes that will be cached). 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@sys-net.it ---------------------------------------
Hi there, Firstly, thanks for the really quick reply. > I think this issue has been already fixed, incidentally, in HEAD/re24, but > went unnoticed in re23. You should replace the call to ch_malloc() that's > around line 1140 in servers/slapd/overlays/pcache.c with a call to > ch_calloc(); something like > > *new_attrs = (AttributeName*)ch_calloc( count + 1, > sizeof(AttributeName)); Yep, it's there - line 1138. I'll patch this and report back. > (sorry, I can't access the network right now but by webmail). In > fact, right now, the array of AttributeName "new_attrs" is accessed > by an_find() while not yet NULL terminated. Please check and report > (to create the problem, you need to use filters that contain the > attributes that will be cached). I would have expected the problem to show up more frequently, if I just need to use a filter that will result in attributes being cached. Cheers Toby
> I would have expected the problem to show up more frequently, if I > just need to use a filter that will result in attributes being cached. well, the issue you seem to see is quite clear; probably it doesn't show up that frequently because by chance there happens to be a NULL somewhere along the path before a SIGSEGV is triggered. Running slapd under valgrind or similar memory debuggers would probably track it much quicker. And there might be more; only, this is for sure a bug. 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@sys-net.it ---------------------------------------
>> I would have expected the problem to show up more frequently, if I >> just need to use a filter that will result in attributes being cached. > > well, the issue you seem to see is quite clear; probably it doesn't show > up that frequently because by chance there happens to be a NULL somewhere > along the path before a SIGSEGV is triggered. Running slapd under > valgrind or similar memory debuggers would probably track it much quicker. > And there might be more; only, this is for sure a bug. OK, yes, I see what you're saying. I'll patch and report back. Toby
changed notes changed state Open to Feedback
changed notes moved from Incoming to Software Bugs
changed notes changed state Feedback to Test
changed notes changed state Test to Release
I said: > I'll patch and report back. Apologies for the delaying in confirming... Yep, this fixed the problem I was seeing. Many thanks Toby
changed notes changed state Release to Closed
moved from Software Bugs to Archive.Software Bugs
pcache fixed in RE23 RE23 only