[Date Prev][Date Next] [Chronological] [Thread] [Top]
(ITS#5665) slapd crashing with slapo-pcache when using attrset "*"

To: openldap-its@OpenLDAP.org
Subject: (ITS#5665) slapd crashing with slapo-pcache when using attrset "*"
From: toby@inf.ed.ac.uk
Date: Fri, 22 Aug 2008 09:44:26 GMT
Full_Name: Toby Blake
Version: 2.4.11
OS: Scientific Linux 5.1
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (129.215.24.127)


Hi there,

I have been seeing problems when using slapo-pcache with
openldap-2.4.11, specifically when using an attrset of "*".

- openldap-2.4.11 on scientific linux 5.1
- We build our own RPMs.  I have built them with no optimisation (-O0)
  for the purposes of debugging.

Relevant part of slapd.conf:

overlay                 pcache
proxycache              bdb 5000 1 500 60
proxycachequeries       10000
proxyattrset            0 "*"
proxytemplate           (uid=) 0 60 60

What seems to happen is that a matching query will get answered and
added to the cache - all is fine until that entry expires and is then
deleted from the cache.  The next matching query will then cause slapd
to crash, either with an abort or a segfault.  This is repeatable.

I have been testing with the above configuration and the following
queries:

ldapsearch -x "uid=toby"
ldapsearch -x "uid=blah"

(the first for a positive reply, the second for a negative)

I have seen three different types of crash, all at the same point
(i.e. directly triggered by the query following the entry being
deleted from the cache).

So, here are the 3 different backtraces:

backtrace 1:

Thread 1 (process 13771):
#0  0x081c39fb in ber_put_string (ber=0x9839c00, 
    str=0x79626f74 <Address 0x79626f74 out of bounds>, tag=4294967295)
    at encode.c:396
#1  0x081c488a in ber_printf (ber=0x9839c00, fmt=0x8227d5d "v}N}")
    at encode.c:828
#2  0x08198957 in ldap_build_search_req (ld=0x9827920, 
    base=0xb56051a4 "dc=inf,dc=ed,dc=ac,dc=uk", scope=2, 
    filter=0xb5605234 "(uid=toby)", attrs=0x9831838, attrsonly=0, sctrls=0x0, 
    cctrls=0x0, timelimit=3600, sizelimit=24576, idp=0xb5f05d78)
    at search.c:328
#3  0x081982fa in ldap_search_ext (ld=0x9827920, 
    base=0xb56051a4 "dc=inf,dc=ed,dc=ac,dc=uk", scope=2, 
    filter=0xb5605234 "(uid=toby)", attrs=0x9831838, attrsonly=0, sctrls=0x0, 
    cctrls=0x0, timeout=0xb5f05e28, sizelimit=24576, msgidp=0xb5f05e3c)
    at search.c:100
#4  0x08116466 in ldap_back_search (op=0x9811140, rs=0xb5f07110)
    at search.c:216
#5  0x080eb88e in overlay_op_walk (op=0x9811140, rs=0xb5f07110, 
    which=op_search, oi=0x97a6da8, on=0x0) at backover.c:646
#6  0x080eba96 in over_op_func (op=0x9811140, rs=0xb5f07110, which=op_search)
    at backover.c:698
#7  0x080ebb3a in over_op_search (op=0x9811140, rs=0xb5f07110)
    at backover.c:720
#8  0x08070e83 in fe_op_search (op=0x9811140, rs=0xb5f07110) at search.c:366
#9  0x080707e1 in do_search (op=0x9811140, rs=0xb5f07110) at search.c:217
#10 0x0806d530 in connection_operation (ctx=0xb5f07200, arg_v=0x9811140)
    at connection.c:1084
#11 0x0806da1d in connection_read_thread (ctx=0xb5f07200, argv=0x18)
    at connection.c:1211
#12 0x08192de9 in ldap_int_thread_pool_wrapper (xpool=0x9785880) at tpool.c:663
#13 0x0076046b in start_thread () from /lib/libpthread.so.0
#14 0x006b7dbe in clone () from /lib/libc.so.6
(gdb) 


backtrace 2:

Thread 1 (process 27627):
#0  0x0065305a in free () from /lib/libc.so.6
#1  0x081c69ca in ber_memfree_x (p=0x9c8a1a0, ctx=0x0) at memory.c:152
#2  0x080d4020 in slap_sl_free (ptr=0x9c8a1a0, ctx=0x9c87c40)
    at sl_malloc.c:456
#3  0x080708de in do_search (op=0x9c89d78, rs=0xb5b8d110) at search.c:233
#4  0x0806d530 in connection_operation (ctx=0xb5b8d200, arg_v=0x9c89d78)
    at connection.c:1084
#5  0x0806da1d in connection_read_thread (ctx=0xb5b8d200, argv=0x10)
    at connection.c:1211
#6  0x08192de9 in ldap_int_thread_pool_wrapper (xpool=0x9bfe880) at tpool.c:663
#7  0x0076046b in start_thread () from /lib/libpthread.so.0
#8  0x006b7dbe in clone () from /lib/libc.so.6
(gdb) 


backtrace 3:

Thread 1 (process 10333):
#0  0x080bc4b2 in ad_inlist (desc=0x8efa9c8, attrs=0x8f8c488) at ad.c:586
#1  0x08080641 in fe_aux_operational (op=0x8f8bce0, rs=0xb5b8b110)
    at backend.c:1885
#2  0x08080809 in backend_operational (op=0x8f8bce0, rs=0xb5b8b110)
    at backend.c:1933
#3  0x080829f6 in slap_send_search_entry (op=0x8f8bce0, rs=0xb5b8b110)
    at result.c:778
#4  0x0811684c in ldap_back_search (op=0x8f8bce0, rs=0xb5b8b110)
    at search.c:338
#5  0x080eb88e in overlay_op_walk (op=0x8f8bce0, rs=0xb5b8b110, 
    which=op_search, oi=0x8f21da8, on=0x0) at backover.c:646
#6  0x080eba96 in over_op_func (op=0x8f8bce0, rs=0xb5b8b110, which=op_search)
    at backover.c:698
#7  0x080ebb3a in over_op_search (op=0x8f8bce0, rs=0xb5b8b110)
    at backover.c:720
#8  0x08070e83 in fe_op_search (op=0x8f8bce0, rs=0xb5b8b110) at search.c:366
#9  0x080707e1 in do_search (op=0x8f8bce0, rs=0xb5b8b110) at search.c:217
#10 0x0806d530 in connection_operation (ctx=0xb5b8b200, arg_v=0x8f8bce0)
    at connection.c:1084
#11 0x0806da1d in connection_read_thread (ctx=0xb5b8b200, argv=0x10)
    at connection.c:1211
#12 0x08192de9 in ldap_int_thread_pool_wrapper (xpool=0x8f00880) at tpool.c:663
#13 0x0076046b in start_thread () from /lib/libpthread.so.0
#14 0x006b7dbe in clone () from /lib/libc.so.6
(gdb) 



In an hour of testing (with a positive query) yesterday, nine of the
crashes were with backtrace 3, two were with backtrace 1, and one was
with backtrace 2.

In an hour of testing with a negative query, all of the crashes were
essentially backtrace 2, but with a longer stack:

Thread 1 (process 18684):
#0  0x00220402 in __kernel_vsyscall ()
#1  0x0060fd20 in raise () from /lib/libc.so.6
#2  0x00611631 in abort () from /lib/libc.so.6
#3  0x00647e6b in __libc_message () from /lib/libc.so.6
#4  0x0064fb16 in _int_free () from /lib/libc.so.6
#5  0x00653070 in free () from /lib/libc.so.6
#6  0x081c69ca in ber_memfree_x (p=0x9bf1488, ctx=0x0) at memory.c:152
#7  0x080d4020 in slap_sl_free (ptr=0x9bf1488, ctx=0x9bee420)
    at sl_malloc.c:456
#8  0x080708de in do_search (op=0x9bf1110, rs=0xb5f27110) at search.c:233
#9  0x0806d530 in connection_operation (ctx=0xb5f27200, arg_v=0x9bf1110)
    at connection.c:1084
#10 0x0806da1d in connection_read_thread (ctx=0xb5f27200, argv=0x10)
    at connection.c:1211
#11 0x08192de9 in ldap_int_thread_pool_wrapper (xpool=0x9b65880) at tpool.c:663
#12 0x0076046b in start_thread () from /lib/libpthread.so.0
#13 0x006b7dbe in clone () from /lib/libc.so.6
(gdb) 


Please let me know if there is any additional information I can
provide.

Cheers
Toby Blake
School of Informatics
University of Edinburgh
Prev by Date: Re: (ITS#5661) contextCSN gets corrupted on the stand by mirror
Next by Date: Re: (ITS#5661) contextCSN gets corrupted on the stand by mirror
Index(es):
- Chronological
- Thread