[Date Prev][Date Next]
Re: (ITS#5927) assertion error when using pcache
> email@example.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) (22.214.171.124)
>> 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
>> The indexer rightly asserts because pcache handed it an attribute with nothing
>> 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.
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.
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/