[Date Prev][Date Next] [Chronological] [Thread] [Top]

(ITS#6021) slapo-pcache/back-ldap slapd crashes



Full_Name: Toby Blake
Version: 2.4.15
OS: Scientific Linux 5.2
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (129.215.197.95)


Hi there,

I have been testing slapo-pcache/back-ldap for some time now,
typically in student lab situations (to provide a localhost
proxycaching slapd with back-ldap connecting (via gssapi) to several
remote servers), initially using 2.3.x but I have recently moved to
using the latest 2.4.x versions, as it's clear that's where the
development effort is going.

I'm seeing quite a lot of crashes during my testing, with a few
different backtraces.  I don't know whether you would prefer I
submitted these separately for different backtraces, so I'm opening
this ITS to get the process started...

I have seen no way of reproducing these crashes.

I'm currently using:
- openldap-2.4.15 on scientific linux 5.2
- bdb 4.7.25 with 3 patches
- We build our own RPMs.  I have openldap-2.4.15 with no optimisation
  (-O0) for the purposes of debugging.

The most common backtrace I see is an assertion failure in
memory.c:152.  Here's an example:

Program terminated with signal 6, Aborted.
#0  0x00b8d402 in __kernel_vsyscall ()
(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
#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
#13 0x080f2b02 in overlay_op_walk (op=0xa680e5d8, rs=0xb5ad10e0, 
    which=op_search, oi=0x8fa9208, on=0x0) at backover.c:669
#14 0x080f2d0a in over_op_func (op=0xa680e5d8, rs=0xb5ad10e0, which=op_search)
    at backover.c:721
#15 0x080f2dae in over_op_search (op=0xa680e5d8, rs=0xb5ad10e0)
    at backover.c:743
#16 0x080720d6 in fe_op_search (op=0xa680e5d8, rs=0xb5ad10e0) at search.c:366
#17 0x08071a2c in do_search (op=0xa680e5d8, rs=0xb5ad10e0) at search.c:217
#18 0x0806e705 in connection_operation (ctx=0xb5ad11d0, arg_v=0xa680e5d8)
    at connection.c:1097
#19 0x0806ebdf in connection_read_thread (ctx=0xb5ad11d0, argv=0x13)
    at connection.c:1223
#20 0x0819ecad in ldap_int_thread_pool_wrapper (xpool=0x8f86fa0) at tpool.c:663
#21 0x00b3346b in start_thread () from /lib/libpthread.so.0
#22 0x00a90dbe in clone () from /lib/libc.so.6
(gdb) 

I have seen quite a few of these backtraces, although sometimes coming
through slap_sl_free (and a couple of other places) instead of
ber_bvarray_free_x.

Let me know what further information I can provide.

Many thanks
Toby Blake
School of Informatics
University of Edinburgh