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