Bug 204920 - memleak in db4
Summary: memleak in db4
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: db4
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jindrich Novy
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-09-01 12:28 UTC by Caolan McNamara
Modified: 2013-07-02 23:17 UTC (History)
1 user (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2006-09-03 09:38:21 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
OpenOffice.org 69213 0 None None None Never

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.


Note You need to log in before you can comment on or make changes to this bug.