Citadel database error 81bc0163 (Citadel 4.3)

Question

I’m not sure how my database was corrupted (I suspect a NaN)
but the result is that when displaying a certain period of time, either from
within the LabView DSC module or with the Measurement and Automation Explorer (MAX),
the LabView DSC (or MAX) crashes by exiting without notice. If you attempt to
archive the data, you get the error 81bc0163 and archiving is aborted. How to
solve:
1. Make a complete copy of the database directory (with the
.thd and other files). You will need the dates on which the .thd files were
created, and the Citadel database engine wants to repack these files and thus
change the dates (Citadel will sometimes use ‘holes’ in existing files to store
new data, but it generally creates files and stores data sequentially.)
2. Using MAX, open your copied Citadel database and create a
new view to it. Include the 1st 20 traces. Plot these traces (select
them and then click on the Display tab) for the entire duration (this can take
a while). If MAX does not crash, plot the next 20 traces, until MAX crashes. The
goal is to find which trace cause MAX to crash. (If you can plot all traces for
all times, you don’t have the problem I encountered.)
3. Now create a view that includes the 20 twenty traces that
caused the crash and Display it for various periods of time . Select an end
date, and then choose the Display tab. If MAX crashes, then repeat with a
different end date, util you can isolate the date and time of the faulty
record. Be sure to use a very narrow Display time to get good resolution. A
binary search of time periods is the most efficient, unless you already have
some clue about the problem date.
4. Once you have identified the date and time of the date
that causes the crash, exit MAX and then delete the .thd file whose creation
date is just prior to the chars date and time.
5. Restart MAX and open the view of your copied data base.
BE PATIENT, it can take many, many minutes for the Citadel database to deal
with the deleted .thd file, but it appears that the Citadel database is robust
enough to recreate its indices.
6. Create a second  new view of the copied database (this resets
the time from the beginning of creation to the distant future), select the
critical 20 traces, and click on the Display tab to make sure the database can
now be viewed without crashing. If, not repeat the process with yet another
copie database.
7. Now, rename the copied and the original folders so that the
fixed database replaces the original. Verify that the ‘new original’ is OK by
running MAX and crating a view of the 20 traces and displaying them for all
times.

Answer 1

I forgot to include the full stack trace:
java.lang.UnsatisfiedLinkError: /nfsmounts/risc14/cmsd/gdfr/dbxml/dbxml-2.2.13/install/lib/libdb_java-4.3.so: /nfsmounts/risc14/cmsd/gdfr/dbxml/dbxml-2.2.13/install/lib/libdb_java-4.3.so: cannot open shared object file: No such file or directory
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1751)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1676)
at java.lang.Runtime.loadLibrary0(Runtime.java:822)
at java.lang.System.loadLibrary(System.java:992)
at com.sleepycat.db.internal.db_javaJNI.<clinit>(db_javaJNI.java:48)
at com.sleepycat.db.internal.DbEnv.<init>(DbEnv.java:200)
at com.sleepycat.db.EnvironmentConfig.createEnvironment(EnvironmentConfig.java:738)
at com.sleepycat.db.EnvironmentConfig.openEnvironment(EnvironmentConfig.java:691)
at com.sleepycat.db.Environment.<init>(Environment.java:30)
at org.oclc.da.gdfr.registryprototype.pvt.CollectionDbXml.createDefaultManager(CollectionDbXml.java:361)
at org.oclc.da.gdfr.registryprototype.pvt.test.CollectionDbXmlTest.setUp(CollectionDbXmlTest.java:324)
at org.oclc.da.gdfr.registryprototype.pvt.test.AllTests.main(AllTests.java:22)
I'm also installing the DB with this tar:
dbxml-2.2.13.tar.gz