[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: (ITS#5927) assertion error when using pcache



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.

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/