Berkeley DB Family

Hello,

I am receiving a SIGSEGV which generates the following stack trace intermittently while using the C API (5.1.29):

[1] __memp_fput(0x80b81e0, 0x0, 0x0, 0x0), at 0xfee8f1a6
[2] __bam_get_root(0x80af008, 0x3, 0x1, 0x582, 0xf3915294, 0xf3915254, 0xfed9b651, 0xfedb793d), at 0xfedb7846
[3] __bam_search(0x80af008, 0x0, 0xf39154c0, 0x582, 0x1, 0x0, 0xf391539c, 0xfeda6e8e), at 0xfedb79cb
[4] __bamc_search(0x80af008, 0x0, 0xf39154c0, 0x1a, 0xf391539c, 0xfeed56f8, 0xf39153c8, 0xfeda3a02), at 0xfeda7628
[5] __bamc_get(0x80af008, 0xf39154c0, 0xf39154a0, 0x1a, 0xf391542c, 0xf3915424, 0x0, 0xfee3aa16), at 0xfeda3b4e
[6] __dbc_iget(0x80c2b58, 0xf39154c0, 0xf39154a0, 0x201a), at 0xfee3ae0a
[7] __dbc_get(0x80c2b58, 0xf39154c0, 0xf39154a0, 0x201a), at 0xfee3a9e9
[8] __db_del(0x80b99d8, 0x0, 0x80a2468, 0xf3915590, 0x0, 0x80a2468, 0x0, 0x0), at 0xfee38dec
[9] __db_del_pp(0x80b99d8, 0x80a2468, 0xf3915590, 0x0, 0x0, 0x0), at 0xfee46a5d
=>[10] iBDBDelete(tpFD = 0xf3916450, vpNativeRecord = 0xf391564c, iNativeSize = 41, vpConvertedRecord = (nil), iSyncFunction = (nil)), line 850 in "ISAM_bdb.c"
[11] iProcessSyncRecords(tpControl = 0x80adf90, tpThreadSocketInfo = 0xf3915918, tpSyncFiles = 0xf3916450, tpDataFD = 0xf3915f40), line 385 in "bdbToMaster.c"
[12] iSyncData(tpControl = 0x80adf90, tpThreadSocketInfo = 0xf3915918, tpSyncFiles = 0xf3916450, tpDataFD = 0xf3915f40), line 206 in "bdbToMaster.c"
[13] vpFileHandler(vpPtr = 0x80adf90), line 131 in "bdbToMaster.c"
[14] thrsetup(0xfdbaca00), at 0xfecf7e76
[15] lwpstart(0x0, 0x80826e8, 0x8083a68, 0xf5f4f66c, 0xf8541d18, 0x0), at 0xfecf8160

In looking at the code, it would appear that __bam_get_root does not find the root node. It then calls __memp_fput with a null pointer which is trouble.

The environment is opened with the following flags: DB_CREATE, DB_INIT_MPOOL, DB_THREAD, DB_INIT_LOCK, DB_INIT_LOG, DB_INIT_TXN, DB_REGISTER, and DB_RECOVER.

Various environment tuning parameters are set as follows:
tpDBEnv->set_cachesize(tpDBEnv, 0, 100 * 1024 * 1024, 0);
tpDBEnv->set_tx_max(tpDBEnv, 40000);
tpDBEnv->set_lk_partitions(tpDBEnv, 1);
tpDBEnv->set_flags(tpDBEnv, DB_DIRECT, 1);
tpDBEnv->set_flags(tpDBEnv, DB_TXN_WRITE_NOSYNC, 1);
tpDBEnv->set_lk_detect(tpDBEnv, DB_LOCK_RANDOM);

The databases (DB_BTREE) are opened with the following flags: DB_READ_UNCOMMITTED and DB_MULTIVERSION.

Unfortunately, I do not have a small code sample that can generate this result. It is probably worth mentioning that this does not happen when the code is linked against 4.7.25 and that similar results occur with 5.2.36.

Any help is appreciated. Thank you.

Duane McCully