Issue 5665 - slapd crashing with slapo-pcache when using attrset "*"
Summary: slapd crashing with slapo-pcache when using attrset "*"
Status: VERIFIED FIXED
Alias: None
Product: OpenLDAP
Classification: Unclassified
Component: slapd (show other issues)
Version: 2.4.11
Hardware: All All
: --- normal
Target Milestone: ---
Assignee: OpenLDAP project
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-08-22 09:44 UTC by toby@inf.ed.ac.uk
Modified: 2014-08-01 21:04 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description toby@inf.ed.ac.uk 2008-08-22 09:44:25 UTC
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

Comment 1 ando@openldap.org 2008-08-23 09:08:54 UTC
changed notes
changed state Open to Test
moved from Incoming to Software Bugs
Comment 2 ando@openldap.org 2008-08-23 09:09:41 UTC
Should be fixed in HEAD; please test.


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
-----------------------------------

Comment 3 toby@inf.ed.ac.uk 2008-08-25 08:54:55 UTC
Hi there, I've patched pcache.c and it seems fine.  I'll put it  
through some more testing and confirm.

Cheers
Toby


-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

Comment 4 Quanah Gibson-Mount 2008-09-03 17:47:26 UTC
changed notes
changed state Test to Release
Comment 5 toby@inf.ed.ac.uk 2008-09-09 14:00:57 UTC
Hi again,

I haven't been able to reproduce the problem since patching, so I
consider it fixed....

Many thanks
Toby

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

Comment 6 ando@openldap.org 2008-10-15 15:57:20 UTC
changed notes
changed state Release to Closed
Comment 7 OpenLDAP project 2014-08-01 21:04:16 UTC
fixed in HEAD
fixed in RE24