Bug 204920

Summary: memleak in db4
Product: [Fedora] Fedora Reporter: Caolan McNamara <caolanm>
Component: db4Assignee: Jindrich Novy <jnovy>
Status: CLOSED RAWHIDE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: pknirsch
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-09-03 09:38:21 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Caolan McNamara 2006-09-01 12:28:43 UTC
Description of problem:
memleak on db->open

Version-Release number of selected component (if applicable):
db4-4.3.29-6

How reproducible:
Always

Steps to Reproduce:
  #include <db.h>
int main(void)
{
    DB *dbp;
    if (0 == db_create(&dbp, 0, DB_CXX_NO_EXCEPTIONS))
    {
        /*
           args 2 is DB_TXN *, 0 is valid from docs, but appears to cause
           a mem leak
        */
        dbp->open(dbp,0,"/no-exist/but/irrelevent",0,DB_BTREE, DB_RDONLY,0644);
        dbp->close(dbp,0);
    }
    return 0;
}

gcc db4test.c -lpthread -ldb
valgrind --leak-check=full ./a.out

Actual results:
==2837== 132 bytes in 1 blocks are definitely lost in loss record 1 of 1
==2837==    at 0x40203C6: malloc (vg_replace_malloc.c:149)
==2837==    by 0x638260E: __os_malloc (in /lib/libdb-4.3.so)
==2837==    by 0x6382956: __os_calloc (in /lib/libdb-4.3.so)
==2837==    by 0x6390FDB: __xa_get_txn (in /lib/libdb-4.3.so)
==2837==    by 0x6391C5D: (within /lib/libdb-4.3.so)
==2837==    by 0x80484A4: main (in /home/caolan/a.out)


Expected results:
no leak

Additional info:
related to 2nd arg of open

Comment 1 Jindrich Novy 2006-09-03 09:38:21 UTC
Are you sure that usage of DB_CXX_NO_EXCEPTIONS is intentional?

db_create supports only 0 or DB_XA_CREATE flags according to documentation,
luckily DB_CXX_EXCEPTIONS and DB_XA_CREATE are equivalent (==2).

The memleak was caused by broken SET_TXN macro in xa_db.c and occurs only when
db->open()ing with txnid == NULL.

Comment 2 Caolan McNamara 2006-09-03 13:25:00 UTC
Yeah, thanks, that looks dubious alright.

Comment 3 Fedora Update System 2006-09-04 17:15:42 UTC
db4-4.3.29-7.fc5 has been pushed for fc5, which should resolve this issue.  If these problems are still present in this version, then please make note of it in this bug report.