[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: (ITS#6021) slapo-pcache/back-ldap slapd crashes
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
-----------------------------------