Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 204920 - memleak in db4
memleak in db4
Product: Fedora
Classification: Fedora
Component: db4 (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jindrich Novy
Depends On:
  Show dependency treegraph
Reported: 2006-09-01 08:28 EDT by Caolan McNamara
Modified: 2013-07-02 19:17 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-09-03 05:38:21 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
OpenOffice.org 69213 None None None Never

  None (edit)
Description Caolan McNamara 2006-09-01 08:28:43 EDT
Description of problem:
memleak on db->open

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

How reproducible:

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);
    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 05:38:21 EDT
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 09:25:00 EDT
Yeah, thanks, that looks dubious alright.
Comment 3 Fedora Update System 2006-09-04 13:15:42 EDT
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.