BDB crash question...

Question

This is a follow-up to the issue I posted here: DB_MULTIVERSION question...
This also involves a database that is working fine with MVCC enabled. When we turn MVCC off, we are able to reproduce a particular crash in BDB with our particular database setup and only when the databases are filled with a particular set of data. The data in question is a 700MB database, and I'm not sure what about it is causing the crash, but I have trouble reproducing it if I wipe the databases clean and perform the same actions.
BT:
(gdb) bt
#0 0x00002b50a08687bb in __ham_add_dup () from /usr/local/BerkeleyDB.4.7/lib/libdb_cxx-4.7.so
#1 0x00002b50a085cf1b in __hamc_put () from /usr/local/BerkeleyDB.4.7/lib/libdb_cxx-4.7.so
#2 0x00002b50a08d06e5 in __dbc_put () from /usr/local/BerkeleyDB.4.7/lib/libdb_cxx-4.7.so
#3 0x00002b50a08d10de in __dbc_put () from /usr/local/BerkeleyDB.4.7/lib/libdb_cxx-4.7.so
#4 0x00002b50a08c3cde in __db_put () from /usr/local/BerkeleyDB.4.7/lib/libdb_cxx-4.7.so
#5 0x00002b50a08dae6c in __db_put_pp () from /usr/local/BerkeleyDB.4.7/lib/libdb_cxx-4.7.so
#6 0x00002b50a082895c in Db::put () from /usr/local/BerkeleyDB.4.7/lib/libdb_cxx-4.7.so
CRASH:
hash_dup.c:132 - return (hcp->opd->am_put(hcp->opd, NULL, nval, flags, NULL));
opd is NULL.
INFO:
We are using the hash access method with a custom hashing function. This particular database has two secondaries attached to it, both of which allow duplicates. We open our environment with DB_CREATE | DB_INIT_LOG | DB_INIT_LOCK | DB_INIT_MPOOL | DB_INIT_TXN | DB_THREAD | DB_RECOVER | DB_SYSTEM_MEM | DB_INIT_REP. We are not actively using replication (the code is #ifdef'd out).
What information can I get to you to help us diagnose the cause of this crash? I note that I can re-enable DB_MULTIVERSION and the crash no longer occurs. Thank you very much.

Answer 1

Hi Shishir,
newbdb wrote:
Once it crashed, I was trying to run db_checkpoint before bringing the environment up(with db_recovery) again and db_checkpoint did not come back. Is it because of possible recovery required ?Why would you run db_checkpoint after a crash? There are so many utilities that you can run after a crash (recover, verify, dump, deadlock), but not checkpoint.
If the application or system crashes, the log is reviewed during recovery (from the last checkpoint in case of normal recovery, or from the first log file available in case of catastrophic recovery). Any database changes described in the log that were part of committed transactions and that were never written to the actual database itself are written to the database as part of recovery. Now, if you are going to write a checkpoint after the crash... normal recovery is not going to work. In case there are problems, the checkpoint may not work, as it happens in your case.
Thanks,
Bogdan Coman