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

slapd crasher in HEAD (ITS#2864)



Full_Name: Luke Howard
Version: HEAD
OS: Linux
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (165.228.130.12)


This crasher occurs in HEAD under some circumstances - it does not occur in the
2.2 release engineering branch, which has been very solid. Valgrind only shows
the following error:

==5990== 
==5990== Thread 6:
==5990== Invalid read of size 4
==5990==    at 0x8075644: slap_op_free (operation.c:95)
==5990==    by 0x8068382: connection_operation (connection.c:1137)
==5990==    by 0x80EAAAF: ldap_int_thread_pool_wrapper (tpool.c:467)
==5990==    by 0x403D63EB: thread_wrapper (vg_libpthread.c:671)
==5990==    by 0x4016DA4F: (within /usr/local/lib/valgrind/valgrind.so)
==5990==    Address 0x5AC9F968 is not stack'd, malloc'd or free'd
==5990== 
==5990== Thread 6:
==5990== Invalid free() / delete / delete[]
==5990==    at 0x40167B8B: free (vg_clientfuncs.c:185)
==5990==    by 0x8109BEE: ber_memfree_x (memory.c:153)
==5990==    by 0x8098839: sl_free (sl_malloc.c:202)
==5990==    by 0x8075654: slap_op_free (operation.c:96)
==5990==    by 0x8068382: connection_operation (connection.c:1137)
==5990==    by 0x80EAAAF: ldap_int_thread_pool_wrapper (tpool.c:467)
==5990==    by 0x403D63EB: thread_wrapper (vg_libpthread.c:671)
==5990==    by 0x4016DA4F: (within /usr/local/lib/valgrind/valgrind.so)
==5990==    Address 0x5AC9F968 is not stack'd, malloc'd or free'd

The same back trace from gdb:

(gdb) bt
#0  0x401d7e90 in pthread_mutex_lock () from /lib/libpthread.so.0
#1  0x40253a8b in free () from /lib/libc.so.6
#2  0x08109bef in ber_memfree_x (p=0xbf13e4a4, ctx=0x0) at memory.c:153
#3  0x0809883a in sl_free (ptr=0xbf13e4a4, ctx=0x82a3c90) at sl_malloc.c:202
#4  0x08075655 in slap_op_free (op=0x82a2110) at operation.c:96
#5  0x08068383 in connection_operation (ctx=0xbf1ff964, arg_v=0x82a2110) at
connection.c:1137
#6  0x080eaab0 in ldap_int_thread_pool_wrapper (xpool=0x8174d80) at tpool.c:467
#7  0x401d70ba in pthread_start_thread () from /lib/libpthread.so.0
#8  0x401d7101 in pthread_start_thread_event () from /lib/libpthread.so.0
(gdb) 

We're running a number of SLAPI plugins inside slapd, so there exists the
possibility that something is going wrong inside a plugin - however the fact
that it works reliably under 2.2 rel eng with nothing reported by valgrind seems
to suggest otherwise.

Leading up to the crash was simply an ordinary serach:

=> string_expand: pattern:  (.*),OU=Domain Controllers,DC=off,DC=padl,DC=com
=> string_expand: expanded: (.*),OU=Domain Controllers,DC=off,DC=padl,DC=com
=> regex_matches: string:        cn=luke howard,cn=users,dc=off,dc=padl,dc=com
=> regex_matches: rc: 1 no matches
bdb_dn2entry("cn=administrators,cn=builtin,dc=off,dc=padl,dc=com")
bdb_entry_get: rc=0
=> string_expand: pattern:  (.*),OU=Domain Controllers,DC=off,DC=padl,DC=com
=> string_expand: expanded: (.*),OU=Domain Controllers,DC=off,DC=padl,DC=com
=> regex_matches: string:        cn=luke howard,cn=users,dc=off,dc=padl,dc=com
=> regex_matches: rc: 1 no matches
ber_flush: 72 bytes to sd 43
<= send_search_reference
>>> dnNormalize: <dc=off,dc=padl,dc=com>
=> ldap_bv2dn(dc=off,dc=padl,dc=com,0)
<= ldap_bv2dn(dc=off,dc=padl,dc=com,0)=0
=> ldap_dn2bv(272)
<= ldap_dn2bv(dc=off,dc=padl,dc=com,272)=0
<<< dnNormalize: <dc=off,dc=padl,dc=com>
>>> dnNormalize: <dc=off,dc=padl,dc=com>
=> ldap_bv2dn(dc=off,dc=padl,dc=com,0)
<= ldap_bv2dn(dc=off,dc=padl,dc=com,0)=0
=> ldap_dn2bv(272)
<= ldap_dn2bv(dc=off,dc=padl,dc=com,272)=0
<<< dnNormalize: <dc=off,dc=padl,dc=com>
send_ldap_response: msgid=4 tag=101 err=0
ber_flush: 14 bytes to sd 43

I noticed this bug a while ago, which was why I switched to release engineering
- I could probably try and locate when it was introduced.