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

(ITS#5457) bdb_add() does not always release entries



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.)