----- "Howard Chu" hyc@symas.com wrote:
ando@sys-net.it wrote:
mhardin@symas.com wrote:
Full_Name: Matthew Hardin Version: 2.4.13 OS: Red Hat Enterprise Linux 4 i686 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (74.38.114.185)
Hi All,
We have an LDAP server that is proxying for Active Directory.
Periodically slapd
throws an assertion:
slapd: [....]/ldap24/servers/slapd/schema_init.c:524:
octetStringIndexer:
Assertion `i> 0' failed. /etc/init.d/solserver: line 192: 6620 Aborted
(core dumped)
"$EXEC_DIR/$PROC" $ARGS -h "$HOST_LIST" $EXTRA_SLAPD_ARGS
Howard Chu's examination of the core file showed that the remote AD
server
returned a member attribute with no values. This is only legal in
LDAP when a
client sets the attrsonly flag in its search request, and that flag
was not set
here.
The indexer rightly asserts because pcache handed it an attribute
with nothing
to index.
I'm not sure what the correct thing to do might be here, but it
should not take
down the slapd.
The entry should not be cached, IMHO.
Perhaps. But then the entire query cannot be cached, because its result set would be known to be incomplete.
Of course, I meant the whole query.
There's something more going on here, because the query in question was searching for (&(objectclass=posixgroup)(memberUid=foo)(member=foo-DN)). There was no memberUid at all in the returned entry, so it must have matched on member, so the member attr should not have been empty.
AD is flaky enough already, but it's possible that back-meta may have dropped the attr values during rewriting, etc.
It is perfectly legitimate for back-meta to return attrs with no values, AFAIK; only, the a_vals should contain the address of slap_dummy_bv...
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando@sys-net.it -----------------------------------