[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: (ITS#6845) sortvals oddities - with more information
- To: openldap-its@OpenLDAP.org
- Subject: Re: (ITS#6845) sortvals oddities - with more information
- From: hyc@symas.com
- Date: Mon, 28 Feb 2011 23:30:16 GMT
- Auto-submitted: auto-generated (OpenLDAP-ITS)
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/