openldap 1.2.12 & cn=monitor (ITS#1208)

[pturgyan@umich.edu]

Full_Name: Paul R. Turgyan
Version: 1.2.12
OS: sun 2.6
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (141.213.231.34)


I'm running openldap 1.2.12 on Solaris 2.6, with posix threads,
and when I issue either of the following searches, slapd dies.

ldapsearch -b "cn=monitor" -s base "(objectclass=*)"
ldapsearch -b "cn=config" -s base "(objectclass=*)"

Here is the last couple of lines in the log file with full slapd tracing
enabled:

Jun 19 10:59:56 barkingdog.dir.itd.umich.edu => acl_access_allowed: read access

to entry "CN=MONITOR"
Jun 19 10:59:56 barkingdog.dir.itd.umich.edu slapd[22249]: 
Jun 19 10:59:56 barkingdog.dir.itd.umich.edu => acl_access_allowed: read access

to value "any" by ""
Jun 19 10:59:56 barkingdog.dir.itd.umich.edu slapd[22249]: <=
acl_access_allowed
: granted by default (no matching to)
Jun 19 10:59:56 barkingdog.dir.itd.umich.edu slapd[22249]: conn=0 op=1 ENTRY
dn=
"CN=MONITOR"
Jun 19 10:59:56 barkingdog.dir.itd.umich.edu slapd[22249]: <= send_search_entry
Jun 19 10:59:56 barkingdog.dir.itd.umich.edu slapd[22249]: send_ldap_result 0::
Jun 19 10:59:56 barkingdog.dir.itd.umich.edu slapd[22249]: conn=0 op=1 RESULT
er
r=0 tag=101 nentries=1
Jun 19 10:59:56 barkingdog.dir.itd.umich.edu slapd[22249]: ltrw_wtry: invalid


Here is a stack dump:

#0  0xef553460 in __sigprocmask () from /usr/lib/libthread.so.1
#1  0xef54b02c in _resetsig () from /usr/lib/libthread.so.1
#2  0xef54a8f0 in _sigon () from /usr/lib/libthread.so.1
#3  0xef54d4fc in _thrp_kill () from /usr/lib/libthread.so.1
#4  0xef5ba5d0 in abort () from /usr/lib/libc.so.1
#5  0x43a88 in ldap_pvt_thread_rdwr_wtrylock (rw=0xbcf10) at rdwr.c:185
#6  0x20f88 in entry_free (e=0xbcef8) at entry.c:226
#7  0x2d6e8 in monitor_info (conn=0xc59b0, op=0xbb758, attrs=0x0, attrsonly=0)
    at monitor.c:191
#8  0x1de60 in do_search (conn=0xc59b0, op=0xbb758) at search.c:113
#9  0x1d338 in connection_operation (arg_v=0xc14b0) at connection.c:74


It seems that in both servers/slapd/monitor.c and servers/slapd/configinfo.c
an entry is created but the "reader/writer lock" is not initialized.
At the end of these 2 routines,  the entry is deleted using entry_free.
entry_free calls ldap_pvt_thread_rdwr_wtrylock which doesn't like the
uninitialized threading struct so it aborts.

I think something similar is happening in servers/slapd/back-passwd/search.c,
where an entry is created, and the threading data is not initialized, and then
the
entry cleaned up by entry_free.