Berkeley DB Reference Guide: Debugging Applications

Common errors

This page outlines some of the most common problems that people encounter and some suggested courses of action.

Symptom:

Core dumps or garbage returns from random Berkeley DB operations.

Possible Cause:

Failure to zero out DBT structure before issuing request.

Fix:

Before using a DBT, you must initialize all its elements to 0 and then set the ones you are using explicitly.

Symptom:

Random crashes and/or database corruption.

Possible Cause:

Running multiple threads, but did not specify DB_THREAD to DB->open or DB_ENV->open.

Fix:

Any time you are sharing a handle across multiple threads, you must specify DB_THREAD when you open that handle.

Symptom:

DB_ENV->open returns EINVAL.

Possible Cause:

The environment home directory is a remote mounted filesystem.

Fix:

Use a locally mounted filesystem instead.

Symptom:

DB->get calls are returning EINVAL.

Possible Cause:

The application is running with threads, but did not specify the DB_DBT_MALLOC, DB_DBT_REALLOC or DB_DBT_USERMEM flags in the DBT structures used in the call.

Fix:

When running with threaded handles (that is, specifying DB_THREAD to DB_ENV->open or DB->open), you must specify one of those flags for all DBT structures in which Berkeley DB is returning data.

Symptom:

Running multiple threads or processes, and the database appears to be getting corrupted.

Possible Cause:

Locking is not enabled.

Fix:

Make sure that you are acquiring locks in your access methods. You must specify DB_INIT_LOCK to your DB_ENV->open call and then pass that environment to DB->open.

Symptom:

Locks are accumulating, or threads and/or processes are deadlocking, even though there is no concurrent access to the database.

Possible Cause:

Failure to close a cursor.

Fix:

Cursors retain locks between calls. Everywhere the application uses a cursor, the cursor should be explicitly closed as soon as possible after it is used.

Symptom:

The system locks up.

Possible Cause:

Application not checking for DB_LOCK_DEADLOCK.

Fix:

Unless you are using the Concurrent Data Store product, whenever you have multiple threads and/or processes and at least one of them is writing, you have the potential for deadlock. As a result, you must test for the DB_LOCK_DEADLOCK return on every Berkeley DB call. In general, updates should take place in a transaction, or you might leave the database in an inconsistent state. Reads may take place outside the context of a transaction under common conditions.

Whenever you get a DB_LOCK_DEADLOCK return, you should do the following:

1. If you are running in a transaction, abort the transaction after first closing any cursors opened in the transaction.

2. If you are not running in a transaction, simply close the cursor that got the DB_LOCK_DEADLOCK (if it was a cursor operation), and retry.

See Recoverability and deadlock avoidance for further information.

Symptom:

An inordinately high number of deadlocks.

Possible Cause:

Read-Modify-Write pattern without using the RMW flag.

Fix:

If you frequently read a piece of data, modify it and then write it, you may be inadvertently causing a large number of deadlocks. Try specifying the DB_RMW flag on your get calls.

Or, if the application is doing a large number of updates in a small database, turning off Btree splits may help (see DB_REVSPLITOFF for more information.)

Symptom:

I run recovery and it exits cleanly, but my database changes are missing.

Possible Cause:

Failure to enable logging and transactions in the database environment; failure to specify DB_ENV handle when creating DB handle; transaction handle not passed to Berkeley DB interface; failure to commit the transaction.

Fix:

Make sure that the environment and database handles are properly created, that the application passes the transaction handle returned by txn_begin to the appropriate Berkeley DB interfaces, and that each transaction is eventually committed.

Symptom:

Recovery fails.

Possible Cause:

A database was updated in a transactional environment, both with and without transactional handles.

Fix:

If any database write operation is done using a transaction handle, every write operation must be done in the context of a transaction.

Symptom:

A database environment locks up, sometimes gradually.

Possible Cause:

A thread of control exited unexpectedly, holding Berkeley DB resources.

Fix:

Whenever a thread of control exits holding Berkeley DB resources, all threads of control must exit the database environment, and recovery must be run.

Symptom:

A database environment locks up, sometimes gradually.

Possible Cause:

Cursors are not being closed before transaction abort.

Fix:

Before an application aborts a transaction, any cursors opened within the context of that transaction must be closed.

Symptom:

Transaction abort or recovery fail, or database corruption occurs.

Possible Cause:

Log files were removed before it was safe.

Fix:

Do not remove any log files from a database environment until Berkeley DB declares it safe.

Copyright Sleepycat Software