toby@inf.ed.ac.uk wrote:
On 14 Mar 2009, at 15:49, Pierangelo Masarati wrote:
Hello,
Thanks for your quick reply.
(gdb) bt #0 0x00b8d402 in __kernel_vsyscall () #1 0x009e8d20 in raise () from /lib/libc.so.6 #2 0x009ea631 in abort () from /lib/libc.so.6 #3 0x00a20e6b in __libc_message () from /lib/libc.so.6 #4 0x00a28b16 in _int_free () from /lib/libc.so.6 #5 0x00a2c070 in free () from /lib/libc.so.6 #6 0x081d5746 in ber_memfree_x (p=0xa6809478, ctx=0x0) at memory.c: 152 #7 0x081d630c in ber_bvarray_free_x (a=0x9049bb8, ctx=0x0) at memory.c:731 #8 0x081d6343 in ber_bvarray_free (a=0x9049bb8) at memory.c:741 #9 0x08079757 in attr_clean (a=0xb62d41bc) at attr.c:134
The problem seems to be here; apparently, the a->a_nvals array is being incorrectly freed. If you have those core files around, it would be interesting to see the contents of those attributes, e.g.
p *a p a->a_desc[0] p a->a_flags p a->a_nvals[0]
from within frame 9.
(gdb) up #9 0x08079757 in attr_clean (a=0xb62d41bc) at attr.c:134 134 ber_bvarray_free( a->a_nvals ); (gdb) p *a $1 = {a_desc = 0x8faa150, a_vals = 0x90487f0, a_nvals = 0x9049bb8, a_numvals = 631, a_flags = 0, a_next = 0x0} (gdb) p a->a_desc[0] $2 = {ad_next = 0x0, ad_type = 0x8fbba20, ad_cname = {bv_len = 9, bv_val = 0x8fba5d8 "memberUid"}, ad_tags = {bv_len = 0, bv_val = 0x0}, ad_flags = 0} (gdb) p a->a_flags $3 = 0 (gdb) p a->a_nvals[0] $4 = {bv_len = 8, bv_val = 0x905aac0 "v1ggoodh"} (gdb)
#10 0x0807983b in attrs_free (a=0xb62d41bc) at attr.c:196 #11 0x0807c059 in entry_clean (e=0xb5acfdbc) at entry.c:504 #12 0x0811ec17 in ldap_back_search (op=0xa680e5d8, rs=0xb5ad10e0) at search.c:354
Also, it would be interesting to see the parameters of the search; e.g.
p op->o_req_ndn p op->o_request.oq_search p op->o_request.oq_search.rs_filterstr p op->o_request.oq_search.rs_attrs[0] (unless NULL)
from within frame 12
(gdb) up #12 0x0811ec17 in ldap_back_search (op=0xa680e5d8, rs=0xb5ad10e0) at search.c:354 354 entry_clean( &ent ); (gdb) p op->o_req_ndn $5 = {bv_len = 24, bv_val = 0xb44ce1e4 "dc=inf,dc=ed,dc=ac,dc=uk"} (gdb) p op->o_request.oq_search $6 = {rs_scope = 2, rs_deref = 0, rs_slimit = 24576, rs_tlimit = 3600, rs_limit = 0x8fa88b8, rs_attrsonly = 0, rs_attrs = 0xb44ce904, rs_filter = 0xb44ce86c, rs_filterstr = {bv_len = 112, bv_val = 0xb44ce87c "(&(objectClass=posixGroup)(| (memberUid=vlavrenk) (uniqueMember=uid=vlavrenk,ou=people,dc=inf,dc=ed,dc=ac,dc=uk)))"}} (gdb) p op->o_request.oq_search.rs_filterstr $7 = {bv_len = 112, bv_val = 0xb44ce87c "(&(objectClass=posixGroup)(| (memberUid=vlavrenk) (uniqueMember=uid=vlavrenk,ou=people,dc=inf,dc=ed,dc=ac,dc=uk)))"} (gdb) p op->o_request.oq_search.rs_attrs[0] $8 = {an_name = {bv_len = 9, bv_val = 0x907b012 "gidNumber"}, an_desc = 0x8f85930, an_oc_exclude = 0, an_oc = 0x0} (gdb)
Finally, it would be great to see your slapd.conf.
No problem, this is the database, back-ldap, pcache part of it:
database ldap suffix dc=inf,dc=ed,dc=ac,dc=uk rootdn uid=ldaprep/ hostname.inf.ed.ac.uk,cn=inf.ed.ac.uk,cn=gssapi,cn=auth uri "ldap://server1.inf.ed.ac.uk/,ldap:// server2.inf.ed.ac.uk" idassert-bind mode=none bindmethod=sasl saslmech=GSSAPI idassert-authzFrom "dn:*"
overlay pcache
proxycache bdb 5000 4 500 300 proxycachequeries 10000
proxyattrset 0 cn userPassword memberUid uniqueMember gidNumber proxyattrset 1 uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos description objectClass afsHomeDirectory primaryRoles secondary Roles proxyattrset 2 cn nisNetgroupTriple memberNisNetgroup proxyattrset 3 "*"
proxytemplate (uid=) 1 1800 1800 proxytemplate (&(objectClass=)(uid=)) 1 1800 1800 proxytemplate (&(objectClass=)(cn=)) 0 1800 1800 proxytemplate (&(objectClass=)(cn=)) 2 1800 1800 proxytemplate (&(objectClass=)(|(memberUid=) (uniqueMember=))) 0 1800 1800 proxytemplate (&(objectClass=)(uniqueMember=)) 0 1800 1800 proxytemplate (&(objectClass=)(memberUid=)) 0 1800 1800 proxytemplate (&(objectClass=)(uidNumber=)) 1 1800 1800 proxytemplate (&(objectClass=)(gidNumber=)) 0 1800 1800 proxytemplate (&(objectClass=)(amdmapName=)(amdmapKey=)) 3 1800 1800 proxytemplate (&(objectClass=)(uid=)) 3 1800 1800
directory /var/openldap-data
checkpoint 128 60 cachesize 10000 idlcachesize 10000
dbconfig set_cachesize 0 16777216 1 dbconfig set_lg_regionmax 262144 dbconfig set_lg_bsize 2097152
If there's anything else that would be useful, let me know. As I mentioned, I have a number of other core files, including some that look the same as this one.
I did my best to reproduce your setup, but I got no crashes. One thing I'd like to ask is: I see some non-standard attributes in the pcache configuration. Can you tell whether there might occur some schema inconsistencies between the remote server and the proxy? Also, can you tell how often crashes occur, or any detail about the type of operation, the workload and so? I also disabled slab allocation, so that true mallocs occur all times, and valgrind is not showing any memory issue.
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 Fax: +39 0382 476497 Email: ando@sys-net.it -----------------------------------