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

Re: (ITS#6845) sortvals oddities - with more information



Andrew Elble wrote:
> Howard Chu<hyc@symas.com>  writes:
>
>>> It would seem that attr_merge() (in attr.c) should have something like this:
>>>
>>>           if ( *a == NULL ) {
>>>                   *a = attr_alloc( desc );
>>>                   if (desc->ad_type->sat_flags&   SLAP_AT_SORTED_VAL) {
>>>                     (*a)->a_flags |= SLAP_ATTR_SORTED_VALS;
>>>                   }
>>>           } else {
>>
>> This is now fixed in HEAD in value.c.
>
> Tested, bad behavior still persists. The call path I've observed
> is as follows:
>
> T@5    : | | | | |>bdb_modify_internal
> T@5    : | | | | | |>modify_add_values
> T@5    : | | | | | | |>attr_merge
> T@5    : | | | | | | | |>attr_alloc
>
> ordered_value_add() doesn't seem to be involved (I can provide the
> entire trace if necessary)

Thanks, my mistake. Fixed now in HEAD attr.c (redundant code removed from add.c)

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/