"Fatal LevelDB error" when specifying -blockfilterindex=basic twice #17679

My bitcoin.conf:

$ cat ~/.bitcoin/bitcoin.conf 
[regtest]
blockfilterindex=basic

And if I launch bitcoind specifying ..=basic again, like this:

$ ./bitcoind -chain=regtest -blockfilterindex=basic

I get this error (full log below):

EXCEPTION: 15dbwrapper_error       
Fatal LevelDB error: IO error: lock /home/vincas/.bitcoin/regtest/indexes/blockfilter/basic/db/LOCK: already held by process       
bitcoin in AppInit()

Does not reproduce if I use -blockfilterindex=1 twice.

Expected behavior

Should not fatal-away due to redundant command line arguments.

Actual behavior

bitcoind exits with Fatal LevelDB error.

To reproduce

• Debian Sid
• ../configure --with-incompatible-bdb --with-gui=no (incompatile to use Debian's bdb)
• Have bitcoin.conf as noted before.
• Run ./bitcoind -chain=regtest -blockfilterindex=basic

System information

Bitcoin Core v0.19.0.1 and from current master Debian Sid amd64. Same with bitcoind and bitcoin-qt

Full output:

2019-12-05T18:56:30Z Feeding 34499 bytes of environment data into RNG
2019-12-05T18:56:30Z Bitcoin Core version v0.19.99.0-6fff333c9 (release build)
2019-12-05T18:56:30Z Validating signatures for all blocks.
2019-12-05T18:56:30Z Setting nMinimumChainWork=0000000000000000000000000000000000000000000000000000000000000000
2019-12-05T18:56:30Z Using the 'sse4(1way),sse41(4way),avx2(8way)' SHA256 implementation
2019-12-05T18:56:30Z Using RdRand as an additional entropy source
2019-12-05T18:56:30Z Default data directory /home/vincas/.bitcoin
2019-12-05T18:56:30Z Using data directory /home/vincas/.bitcoin/regtest
2019-12-05T18:56:30Z Config file: /home/vincas/.bitcoin/bitcoin.conf
2019-12-05T18:56:30Z Using at most 125 automatic connections (1024 file descriptors available)
2019-12-05T18:56:30Z Using 16 MiB out of 32/2 requested for signature cache, able to store 524288 elements
2019-12-05T18:56:30Z Using 16 MiB out of 32/2 requested for script execution cache, able to store 524288 elements
2019-12-05T18:56:30Z Script verification uses 7 additional threads
2019-12-05T18:56:30Z scheduler thread start
2019-12-05T18:56:30Z HTTP: creating work queue of depth 16
2019-12-05T18:56:30Z No rpcpassword set - using random cookie authentication.
2019-12-05T18:56:30Z Generated RPC authentication cookie /home/vincas/.bitcoin/regtest/.cookie
2019-12-05T18:56:30Z HTTP: starting 4 worker threads
2019-12-05T18:56:30Z Using wallet directory /home/vincas/.bitcoin/regtest/wallets
2019-12-05T18:56:30Z init message: Verifying wallet(s)...
2019-12-05T18:56:30Z Using BerkeleyDB version Berkeley DB 5.3.28: (September  9, 2013)
2019-12-05T18:56:30Z Using wallet /home/vincas/.bitcoin/regtest/wallets
2019-12-05T18:56:30Z BerkeleyEnvironment::Open: LogDir=/home/vincas/.bitcoin/regtest/wallets/database ErrorFile=/home/vincas/.bitcoin/regtest/wallets/db.log
2019-12-05T18:56:30Z init message: Loading banlist...
2019-12-05T18:56:30Z ERROR: DeserializeFileDB: Failed to open file /home/vincas/.bitcoin/regtest/banlist.dat
2019-12-05T18:56:30Z Invalid or missing banlist.dat; recreating
2019-12-05T18:56:30Z Cache configuration:
2019-12-05T18:56:30Z * Using 2.0 MiB for block index database
2019-12-05T18:56:30Z * Using 28.0 MiB for basic block filter index database
2019-12-05T18:56:30Z * Using 28.0 MiB for basic block filter index database
2019-12-05T18:56:30Z * Using 8.0 MiB for chain state database
2019-12-05T18:56:30Z * Using 384.0 MiB for in-memory UTXO set (plus up to 286.1 MiB of unused mempool space)
2019-12-05T18:56:30Z init message: Loading block index...
2019-12-05T18:56:30Z Opening LevelDB in /home/vincas/.bitcoin/regtest/blocks/index
2019-12-05T18:56:30Z Opened LevelDB successfully
2019-12-05T18:56:30Z Using obfuscation key for /home/vincas/.bitcoin/regtest/blocks/index: 0000000000000000
2019-12-05T18:56:30Z LoadBlockIndexDB: last block file = 0
2019-12-05T18:56:30Z LoadBlockIndexDB: last block file info: CBlockFileInfo(blocks=0, size=0, heights=0...0, time=1970-01-01...1970-01-01)
2019-12-05T18:56:30Z Checking all blk files are present...
2019-12-05T18:56:30Z Initializing databases...
2019-12-05T18:56:30Z Pre-allocating up to position 0x1000000 in blk00000.dat
2019-12-05T18:56:30Z Opening LevelDB in /home/vincas/.bitcoin/regtest/chainstate
2019-12-05T18:56:30Z Opened LevelDB successfully
2019-12-05T18:56:30Z Wrote new obfuscate key for /home/vincas/.bitcoin/regtest/chainstate: 531e5e9ac4b7503b
2019-12-05T18:56:30Z Using obfuscation key for /home/vincas/.bitcoin/regtest/chainstate: 531e5e9ac4b7503b
2019-12-05T18:56:30Z init message: Rewinding blocks...
2019-12-05T18:56:30Z  block index              45ms
2019-12-05T18:56:30Z Opening LevelDB in /home/vincas/.bitcoin/regtest/indexes/blockfilter/basic/db
2019-12-05T18:56:30Z Opened LevelDB successfully
2019-12-05T18:56:30Z Using obfuscation key for /home/vincas/.bitcoin/regtest/indexes/blockfilter/basic/db: 0000000000000000
2019-12-05T18:56:30Z Opening LevelDB in /home/vincas/.bitcoin/regtest/indexes/blockfilter/basic/db
2019-12-05T18:56:30Z basic block filter index thread start
2019-12-05T18:56:30Z basic block filter index is enabled
2019-12-05T18:56:30Z basic block filter index thread exit
2019-12-05T18:56:30Z Fatal LevelDB error: IO error: lock /home/vincas/.bitcoin/regtest/indexes/blockfilter/basic/db/LOCK: already held by process
2019-12-05T18:56:30Z You can use -debug=leveldb to get more complete diagnostic messages
2019-12-05T18:56:30Z 

************************
EXCEPTION: 15dbwrapper_error       
Fatal LevelDB error: IO error: lock /home/vincas/.bitcoin/regtest/indexes/blockfilter/basic/db/LOCK: already held by process       
bitcoin in AppInit()       



************************
EXCEPTION: 15dbwrapper_error       
Fatal LevelDB error: IO error: lock /home/vincas/.bitcoin/regtest/indexes/blockfilter/basic/db/LOCK: already held by process       
bitcoin in AppInit()       

2019-12-05T18:56:30Z Shutdown: In progress...
2019-12-05T18:56:30Z scheduler thread interrupt
2019-12-05T18:56:30Z Shutdown: done

I guess this can be fixed by putting the indexes in a set to remove duplicates during init

Hi,

I'd like to offer this commit from my fork as a possible solution to this error.

However, as set's are less performant than their unordered counterparts, maybe they should be used instead. This of course would demand a separate hashing function to be provided. Not sure if really needed in this particular case.

Regards,

However, as set's are less performant than their unordered counterparts

Probably irrelevant for a few items. Both set and unordered_set will be slower than simple non-node based std::vector for such tiny use case. I guess it would be enough to just perform std::sort(), std::unique() and std::vector::erase() after filling from the args. Though std::set does show container intent better...

@brakmic

I'd like to offer this commit from my fork as a possible solution to this error.

Would you mind submitting a PR?