#165 HMMusesBDB=1 with useDB4IntCache disabled skips BerkeleyDB initialization — confirmed on 2.8.2(26253)

[Andre Luiz Falcao de Oliveira]

Hello Thomas,

I found an HMM persistence issue on ASSP 2.8.2(26253), traced it to the initialization code, and tested a local patch.

Environment:

• Linux / Perl 5.30.0
• threads::shared 1.6
• BerkeleyDB module 0.64 / Berkeley DB 5.3.28
• HMMusesBDB:=1
• useBerkeleyDB:=1
• useDB4IntCache:= (disabled)
• spamdb:=DB:
• DBdriver:=mysql,mysql_auto_reconnect=1
• RebuildTestMode disabled

Symptoms:

Startup announced that HMMdb was using BerkeleyDB, but immediately reported that the HMM database was empty. No HMMdb.bdb descriptors appeared in lsof.

Rebuilds reported successful HMM population, but HMMdb.bdb remained 12,288 bytes with an old modification timestamp. HMM could work after rebuilding, then became unavailable after restarting.

Cause identified in the original 26253 source:

1. Around line 16038, the internal-hash sharing loop includes HMMdb when useDB4IntCache is disabled.

2. Around line 14921, initPrivatHashes() skips tieToBDB() whenever tied(%{$hash}) is true, without checking the tied object's class.

3. On this system, share(%h) makes tied(%h) return threads::shared::tie. Consequently, BerkeleyDB initialization is skipped, but the “HMMdb is using BerkeleyDB” message is still printed.

4. getDBCount() selects BDB_getRecordCount() because runHMMusesBDB is enabled. Without the BerkeleyDB registration, it returns zero.

5. The rebuild can populate the shared in-memory hash and set haveHMM, without persisting the model to BerkeleyDB.

Minimal reproduction:

perl -Mthreads -Mthreads::shared -e '
my %h;
share(%h);
print ref(tied(%h)) || "(none)", "\n";
'

Output:

threads::shared::tie

Local changes tested:

• Exclude HMMdb from the sharing loop when CanUseBerkeleyDB && runHMMusesBDB.
• Exclude HMMdb from the non-BDB internal-cache initialization/cleanup loop under the same condition. Otherwise, resetIntCacheAtStartup could clear the actual HMM database after fixing its initialization.
• Allow clearDBConPrivat() to release HMMdb for Worker_10001 while retaining its exception for other internal hashes. This worker also calls initPrivatHashes(), despite the existing comment saying it only ties Griplist.

Results after applying the patch:

• lsof showed eight open descriptors for HMMdb.bdb.
• A rebuild published 240,060 HMM sequences.
• HMMdb.bdb grew from 12 KB to approximately 19 MB.
• HMM classified a subsequent SMTP message.
• After a service restart without another rebuild, the new process reopened the populated database and startup no longer reported HMM empty.

The modified code requires --nointchk:=1. Automatic script updates have been disabled locally to preserve the patch pending review.

Could you review the proposed changes and provide an official fix? Checking the actual tied-object class and distinguishing initialization failure from an empty database would also help prevent misleading diagnostics.

I have not established which build introduced this issue, or whether the production branch is affected. The Worker_10001 cleanup change has not been separately tested through worker crash/recovery.

Thank you.

[Thomas Eckardt]

Thank you for reporting the issue and providing the patch.
The patch seems to work well (some tests using other settings is required).
clearDBConPrivat needs to release alls tempDB's for all workers, I simply forgot to delete the code line
return if $WorkerNumber == 10001;

The next release will include the fixes for this issue!

Thomas