coredump when destructor of BlobDBImpl called

[yebangyu]

version of rocksdb: latest, master branch

how to reproduce:

int main() {
rocksdb::blob_db::BlobDB* db = nullptr;
auto status = rocksdb::blob_db::BlobDB::Open(db_options, db_opt, db_path,
column_families,&handles,&db);
assert(status.ok() && db);
for (int i = 0; i < 10000 ;++i) {db -> Put(random_string(), "world");}
delete db;
}

we run the program above about 1000000 times and it does cause 4 cores which have the same backtrace

the implementation of ~BlobDBImpl is :

BlobDBImpl::~BlobDBImpl() {
// CancelAllBackgroundWork(db_, true);
Status s attribute((unused)) = Close();
assert(s.ok());
}
Status BlobDBImpl::Close() {
// ...
delete db_;
//...
}

yeah , delete db_ no matter what it is , what happened and what is happening.

while ,it may cause data race . let's see:

std::pair<bool, int64_t> BlobDBImpl::EvictExpiredFiles(bool aborted) {
//...
SequenceNumber seq = GetLatestSequenceNumber();
// ...
}

GetLatestSequenceNumber may access invalid memory which is destroyed by ~BlobDBImpl

So, IMHO, yeah, yeah, it is up to users to make sure that there are no reads and writes when we delete db, while , the impl of ~BlobDBImpl needs to sync with the background threads in order to quit gracefully

[siying]

#5005