Db- verify of standalone database file

Question

I need help with database verification for a 4.5.20 CDS application running on VxWorks.
I create an environment, and create ~30 databases within that environment, which all exist within one single file. I recently discovered that since I create a set of database file handles at startup, which are shared between several VxWorks tasks, that I need to specify the DB_THREAD flag to both the environment open, and database open calls. This works great and our concurrency problems were eliminated.
The environment is configured with the following flags:
(DB_INIT_CDB | DB_INIT_MPOOL | DB_CREATE | DB_SYSTEM_MEM | DB_THREAD)
However, now my database verifcation is no longer working correctly.
Here is my original code, where I create the verification database handle within the database environment which I later open the databases within:
if ((ret = db_create(&dbp_verify, dbenv_starchoice, 0)) != 0)
{goto err;}
if ((ret = dbp_verify->verify(dbp_verify, DB_STARCHOICE_FILENAME, NULL, NULL, 0)) != 0)
if ((ret = db_destroy()) != 0)
{goto err;}
Until I set the DB_THREAD flag for the environment and databases, this code worked just fine. However, with DB_THREAD flag set the db->verify routine NEVER returns.
So, I modified the code so that I create the dbp_verify database handle outside of the database environment by setting the second parameter of db_create to NULL. Now when the verification runs I get the following error:
S_iosLib_DRIVER_GLUT
I suspect that this is because it has no way to know where to create the temporary files needed for the verify, where previously it used the "temp" directory I specified when configuring the database environment.
Can anyone tell me how to correctly configure the database handle I use for the verifcation, so that I can verify it as a standalone? Or, tell me why when the environment is configured with DB_THREAD the verification never returns??
Thanks!

Answer 1

I have used two different Berkeley builds. For the first one, db->verify had not returned after having let my box run overnight. When I did a task trace in the morning on the task that had called db->verify, I got the following:
0x80053670 vxTaskEntry +0x14 : Neptune::OsTask::entryHelper(Neptune::OsTask*) (
0x830f6a34 Neptune::OsTask::entryHelper(Neptune::OsTask*)+0x80 : Neptune::OsHelp
erTask::entry() ()
0x830f4a10 Neptune::OsHelperTask::entry()+0x40 : OpenTVTask::entry() ()
0x83defba8 OpenTVTask::entry()+0x80 : o_db_vsk_init ()
0x83e3df08 o_db_vsk_init+0x14c: db_startup ()
0x83e1bfac db_startup +0x44 : db_database_init ()
0x83e1a1a0 db_database_init+0x94 : 0x83a28a18 ()
0x83a28a40 __db_verify_pp+0x20 : __db_verify_internal ()
0x83a28b40 __db_verify_internal+0xf4 : 0x83a28ca8 ()
0x83a28f48 __db_verify_internal+0x4fc: 0x83a299fc ()
0x83a29b18 __db_verify_internal+0x10cc: 0x83a2a7bc ()
0x83a2a9b8 __db_vrfy_meta+0x6c0: __bam_vrfy_structure ()
0x839fdf38 __bam_vrfy_structure+0x1a0: __bam_vrfy_subtree ()
0x839fe918 __bam_vrfy_subtree+0x870: __bam_vrfy_subtree ()
0x839fe320 __bam_vrfy_subtree+0x278: __db_vrfy_ovfl_structure ()
0x83a2d9c4 __db_vrfy_ovfl_structure+0x138: __db_vrfy_pgset_inc ()
0x83a2cde4 __db_vrfy_pgset_inc+0xc4 : __db_put ()
0x83a058d0 __db_put +0x40 : __db_cursor ()
0x83a13360 __db_cursor +0x124: __lock_get ()
0x83a59c98 __lock_get +0xa0 : __lock_get_internal ()
0x83a5a84c __lock_get_internal+0xb5c: __db_tas_mutex_lock ()
0x83a7b5d8 __db_tas_mutex_lock+0x114: 0x83a7d994 ()
0x83a7da50 __os_sleep +0xb0 : select ()
0x80110ef0 select +0x578: semTake ()
0x801996b4 semTake +0x160: semBTake ()
value = 0 = 0x0
Then we discovered there was a known bug in VxWorks due to the use of select(), which is used by os_sleep(). So, one of our developers modified os_sleep() based on both Wind River's and Oracle's recommendations so that os_sleep() does not use select.
When I used this new build, db->verify still does not return, but when I do a stack trace on the task I don't get anything. tt simply returns value = 0 = 0x0. It is like the task just stopped running though it's status is READY, not PEND.
Does this information help?