Howard Chu <[email protected]> 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) >> Further pursuing the issue, I started to focus on the index deletion >> code that was changed as a part of ITS#5183. Specifically, the >> portion of code within bdb_modify_internal() (in back-bdb/modify.c) >> that is commented: >> >> /* Move deleted values to end of array */ >> >> This code modifies save_attrs, which is actually apparently a pointer >> to memory that resides within the cache. If a deadlock occurs, these >> changes are not reverted, thereby corrupting the entry in the cache. I >> replaced this code with the pre-ITS#5183 code and I am no longer able >> to 'break' the object and insert duplicate member/memberUids. > > This is now fixed in HEAD. Looks good, thanks. -- Andrew W. Elble [email protected] Infrastructure Engineer, Communications Technical Lead Rochester Institute of Technology PGP: BFAD 8461 4CCF DC95 DA2C B0EB 965B 082E 863E C912 CONFIDENTIALITY NOTE: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and destroy any copies of this information.
