Full_Name: Hallvard B Furuseth Version: HEAD, 2.3, 2.4 OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard

back-bdb/add.c has several code paths where the parent entry "p" is not released - it does "goto return_results;" without first doing

if ( p && p != &slap_entry_root ) bdb_unlocked_cache_return_entry_r( &bdb->bi_cache, p ); p = NULL;

The code looks like it expects that to be done below the return_results lablel, since it sets p to NULL before the goto. I don't know how the bdb cache code works though.

Also I imagine the 'if ( !bvmatch( &pdn, &p->e_nname ) )' branch should check that p != &slap_entry_root before releasing p.

Not sure when the parent needs to be freed. By ITS#3671 entries should be released before doing network I/O - but maybe the parent must be held until the slap_graduate_commit_csn()? I don't know what that does.

Is it bdb_cache_add(,,op->ora_e,,,) or the following TXN_COMMIT which makes it necessary to bdb_cache_return_entry_r the entry? HEAD and RE24 only do bdb_cache_return_entry_r( bdb, oe, &lock ); if rs->sr_err == LDAP_SUCCESS at the return_results label, but rs->sr_err can change after the bdb_cache_add(). (A bit hard to read since the entry is referred to as both 'oe', op->ora_e and op->oq_add.rs_e. Not sure what the 'oe' variable is used for anyway.)