(ITS#5494) slapd crashed when accessed by multiple threads

[adejong@debian.org]

Full_Name: Arthur de Jong
Version: 2.4.7
OS: Debian unstable
URL: http://arthurenhella.demon.nl/nss-ldapd/adejong-slapd-crash.log
Submission from: (NULL) (83.160.165.27)


This has also been submitted as a Debian bug:
http://bugs.debian.org/479237

My test slapd consistently crashes when doing multiple simultaneous
requests in different threads. Each thread has it's own LDAP *ld
connection to the LDAP server which is supposed to be supported [1]. In
any case this shouldn't crash the LDAP server.

[1] http://www.openldap.org/lists/openldap-software/200606/msg00252.html

This problem arises in my test suite for nss-ldapd. Source can be
checked out at http://arthurenhella.demon.nl/svn/nss-ldapd/ (svn) and
the test file is (test/test_myldap.c). It uses a wrapper module (myldap)
around calls to OpenLDAP to simplify memory management. The function
that triggers the crash is test_threads().

I have captured the crash in gdb:

# gdb /usr/sbin/slapd
GNU gdb 6.8-debian
[...]
This GDB was configured as "i486-linux-gnu"...
(gdb) r -d 1 -h ldap:/// ldaps:/// ldapi:/// -g openldap -u openldap -f
/etc/ldap/slapd.conf
Starting program: /usr/sbin/slapd -d 1 -h ldap:/// ldaps:/// ldapi:/// -g
openldap -u openldap -f /etc/ldap/slapd.conf
[Thread debugging using libthread_db enabled]
[New Thread 0xb7b3a930 (LWP 1542)]
@(#) $OpenLDAP: slapd 2.4.7 (Apr 16 2008 08:13:31) $
        @minerva.hungry.com:/home/pere/src/debiancvs/initscripts-ng-svn/trunk/src/insserv/openldap2.3-2.4.7/debian/build/servers/slapd
ldap_pvt_gethostbyname_a: host=sorbet, r=0
daemon_init: listen on ldap:///
daemon_init: 1 listeners to open...
[...]
<= send_search_entry: conn 2 exit.
entry_decode: "cn=Zaka Eddins+uid=zeddins,ou=lotsofpeople,dc=test,dc=tld"
<= entry_decode(cn=Zaka Eddins+uid=zeddins,ou=lotsofpeople,dc=test,dc=tld)
=> send_search_entry: conn 2 dn="cn=Zaka
Eddins+uid=zeddins,ou=lotsofpeople,dc=test,dc=tld"
ber_flush2: 107 bytes to sd 18
<= send_search_entry: conn 2 exit.
entry_decode: "uid=wvakil,ou=lotsofpeople,dc=test,dc=tld"
<= entry_decode(uid=wvakil,ou=lotsofpeople,dc=test,dc=tld)
=> send_search_entry: conn 2 dn="uid=wvakil,ou=lotsofpeople,dc=test,dc=tld"
ber_flush2: 90 bytes to sd 18
<= send_search_entry: conn 2 exit.
entry_decode: "uid=zmeeker,ou=lotsofpeople,dc=test,dc=tld"
<= entry_decode(uid=zmeeker,ou=lotsofpeople,dc=test,dc=tld)
=> send_search_entry: conn 2 dn="uid=zmeeker,ou=lotsofpeople,dc=test,dc=tld"
ber_flush2: 92 bytes to sd 18
<= send_search_entry: conn 2 exit.
bdb_search: 1104 scope not okay

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb5f18b90 (LWP 5017)]
0xb7cef160 in pthread_mutex_lock () from /lib/libpthread.so.0
(gdb) bt
#0  0xb7cef160 in pthread_mutex_lock () from /lib/libpthread.so.0
#1  0xb7f4351d in ldap_pvt_thread_mutex_lock () from
/usr/lib/libldap_r-2.4.so.2
#2  0xb783883d in bdb_cache_return_entry_rw (bdb=0x81ea358, e=0x820922c, rw=0,
lock=0xb5f16fd4)
    at /home/pere/src/debiancvs/initscripts-ng-svn/trunk/src/insserv/openldap2.3-2.4.7/servers/slapd/back-bdb/cache.c:256
#3  0xb782ce12 in bdb_search (op=0x8299b10, rs=0xb5f18168)
    at /home/pere/src/debiancvs/initscripts-ng-svn/trunk/src/insserv/openldap2.3-2.4.7/servers/slapd/back-bdb/search.c:909
#4  0x08077d13 in fe_op_search (op=0x8299b10, rs=0xb5f18168)
    at /home/pere/src/debiancvs/initscripts-ng-svn/trunk/src/insserv/openldap2.3-2.4.7/servers/slapd/search.c:368
#5  0x0807853c in do_search (op=0x8299b10, rs=0xb5f18168)
    at /home/pere/src/debiancvs/initscripts-ng-svn/trunk/src/insserv/openldap2.3-2.4.7/servers/slapd/search.c:217
#6  0x080757c6 in connection_operation (ctx=0xb5f18248, arg_v=0x8299b10)
    at /home/pere/src/debiancvs/initscripts-ng-svn/trunk/src/insserv/openldap2.3-2.4.7/servers/slapd/connection.c:1083
#7  0x08075ed6 in connection_read_thread (ctx=0xb5f18248, argv=0x13)
    at /home/pere/src/debiancvs/initscripts-ng-svn/trunk/src/insserv/openldap2.3-2.4.7/servers/slapd/connection.c:1210
#8  0xb7f42a44 in ?? () from /usr/lib/libldap_r-2.4.so.2
#9  0xb5f18248 in ?? ()
#10 0x00000013 in ?? ()
#11 0x00000000 in ?? ()

A more detailed backtrace is available at the url specified below.