head 1.2; access; symbols RPM_4_2_1:1.1.1.5 RPM_4_2:1.1.1.5 RPM_4_1_1:1.1.1.5 RPM_4_1:1.1.1.4 RPM_4_0_5:1.1.1.3 RPM_4_0_4:1.1.1.2 RPM_4_0_3:1.1.1.1 RPM:1.1.1; locks; strict; comment @# @; 1.2 date 2008.01.02.09.55.03; author rse; state dead; branches; next 1.1; commitid z4cpSiAhOCXk5PLs; 1.1 date 2001.07.23.20.45.37; author rse; state Exp; branches 1.1.1.1; next ; 1.1.1.1 date 2001.07.23.20.45.37; author rse; state Exp; branches; next 1.1.1.2; 1.1.1.2 date 2002.01.08.00.30.11; author rse; state Exp; branches; next 1.1.1.3; 1.1.1.3 date 2003.01.18.13.49.02; author rse; state Exp; branches; next 1.1.1.4; 1.1.1.4 date 2001.10.15.03.47.34; author rse; state Exp; branches; next 1.1.1.5; 1.1.1.5 date 2003.01.18.14.04.59; author rse; state Exp; branches; next ; desc @@ 1.2 log @remove the ancient RPM 4.2.1 source tree copy @ text @ Berkeley DB Reference Guide: Common errors

Berkeley DB Reference Guide:
Debugging Applications

 PrevRefNext

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.

PrevRefNext

Copyright Sleepycat Software @ 1.1 log @Initial revision @ text @d1 1 a1 1 @ 1.1.1.1 log @Import: RPM 4.0.3 @ text @@ 1.1.1.2 log @Import: RPM 4.0.4 @ text @d1 1 a1 1 d81 1 a81 1 failure to specify DB_ENV handle when creating DB handle; d86 1 a86 1 DB_ENV->txn_begin to the appropriate Berkeley DB interfaces, and that each @ 1.1.1.3 log @Import: RPM 4.0.5 @ text @d2 1 a2 1 a3 1 d23 1 a23 1

Fix:
Before using a DBT, you must initialize all its elements d35 2 a36 2 DB_DBT_MALLOC, DB_DBT_REALLOC or DB_DBT_USERMEM flags in the DBT structures used in the call. d39 1 a39 1 flags for all DBT structures in which Berkeley DB is returning data. d81 1 a81 1 failure to specify DB_ENV handle when creating DB handle; @ 1.1.1.4 log @Import: RPM 4.1 @ text @d2 1 a2 1 d4 1 d24 1 a24 1

Fix:
Before using a DBT, you must initialize all its elements d36 2 a37 2 DB_DBT_MALLOC, DB_DBT_REALLOC or DB_DBT_USERMEM flags in the DBT structures used in the call. d40 1 a40 1 flags for all DBT structures in which Berkeley DB is returning data. d82 1 a82 1 failure to specify DB_ENV handle when creating DB handle; @ 1.1.1.5 log @Import: RPM 4.1.1 @ text @d2 1 a2 1 a3 1 d23 1 a23 1

Fix:
Before using a DBT, you must initialize all its elements d35 2 a36 2 DB_DBT_MALLOC, DB_DBT_REALLOC or DB_DBT_USERMEM flags in the DBT structures used in the call. d39 1 a39 1 flags for all DBT structures in which Berkeley DB is returning data. d81 1 a81 1 failure to specify DB_ENV handle when creating DB handle; @