Assertion failure in slapd (ITS#190)

[azeltser@safeword.com]

Full_Name: Alex Zeltser
Version: Devel, as of 6/2/99
OS: Win NT, SP 3
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (204.242.227.157)


I just compiled and started testing slapd.exe under WinNT.  Created and
populated the database with some existing data from an LDIF file (< 50 records).
Ran slapd with -d 65535. Ran ldapsearch with appropriate base suffix
specification and objectclass=* to dump all records.  The two chugged along
happily for a few seconds dumping records and producing traces, then got an
assertion failure from slapd.  

slapd had traced out the following info (the last screenful or so):

=> acl_access_allowed: read access to entry
"sccAuthPreferencesId=FIXPWD,ou=Preferences,ou=e.iD"

=> acl_access_allowed: read access to value "any" by ""
<= acl_access_allowed: granted by default (no matching to)
<= send_search_entry
entry_rdwr_runlock: ID: 34
====> cache_return_entry_r( 34 ): created (0)
send_ldap_result 0::
daemon: activity on 1 descriptors
daemon: activity on: 328r
daemon: read activity on 328
connection_get(328): got connid=6
connection_read(328): checking for input on id=6
ber_get_next
ber_get_next: tag 0x30 len 5 contents:
ber_dump: buf 0x116cfb0, ptr 0x116cfb0, end 0x116cfb5
        02 01 03  B 00
ber_get_next
ber_get_next on fd 328 failed errno 10035 (unknown)
        *** got 18270924 of 0 so far
daemon: select: tcps=16 active_threads=1 tvp=NULL
daemon: activity on 1 descriptors
do_unbind
connection_closing: readying conn=6 sd=328 for close.
connection_resched: attempting closing conn=6 sd=328.
connection_close: conn=6 sd=328.
daemon: removing 328
daemon: activity on: 328r
daemon: read activity on 328
Assertion failed: FD_ISSET( rd, &slap_daemon.sd_actives), file
C:\ldap\servers\s
lapd\daemon.c, line 571

I then popped into the MSVC debugger.  The assert was in slapd_daemon_task.  The
local variables values were:

	rd	328
	nfds	64
+	from	{...}
	i	0
-	writefds	{...}
	fd_count	0
+	fd_array	0x0165fd5c
-	zero	{...}
	tv_sec	0
	tv_usec	0
+	tvp	0x00000000
+	client_addr	0x0048094c "127.0.0.1"
+	client_name	0x00000000 ""
-	readfds	{...}
	fd_count	1
-	fd_array	0x0165fe74
	[0]	328
	[1]	240
	[2]	228
	[3]	268
	[4]	264
	[5]	328
	[6]	0
	...
	ns	1
	ptr	0x011462c0
	tcps	16
	inetd	0


ldapsearch terminated without printing any kind of an error message.  I'm not
sure whether or not it had gotten all records.  It looked like it might have.

I've tried several times with the same data and configuration, but have not been
able to reproduce this error since.  Sounds like there may be a race condition
somewhere in the socket access code.  It seemed strange that the traces reported
read activity on the socket after it was presumably closed.  I don't know if
error 10035 (WSAEWOULDBLOCK) was related to this whole issue or not.  Please
feel free to contact me if you have any questions.