mirror of https://github.com/facebook/rocksdb.git
db/repair: reset Repair::db_lock_ in ctor (#4683)
Summary: there is chance that * the caller tries to repair the db when holding the db_lock, in that case the env implementation might not set the `lock` parameter of Repairer::Run(). * the caller somehow never calls Repairer::Run(). either way, the desctructor of Repair will compare the uninitialized db_lock_ with nullptr, and tries to unlock it. there is good chance that the db_lock_ is not nullptr, then boom. Signed-off-by: Kefu Chai <tchaikov@gmail.com> Pull Request resolved: https://github.com/facebook/rocksdb/pull/4683 Differential Revision: D13260287 Pulled By: riversand963 fbshipit-source-id: 878a119d2e9f10a0fa17ee62cf3fb24b33d49fa5
This commit is contained in:
parent
8d9b4d9741
commit
7dbee38716
|
@ -118,7 +118,8 @@ class Repairer {
|
|||
wc_(db_options_.delayed_write_rate),
|
||||
vset_(dbname_, &immutable_db_options_, env_options_,
|
||||
raw_table_cache_.get(), &wb_, &wc_),
|
||||
next_file_number_(1) {
|
||||
next_file_number_(1),
|
||||
db_lock_(nullptr) {
|
||||
for (const auto& cfd : column_families) {
|
||||
cf_name_to_opts_[cfd.name] = cfd.options;
|
||||
}
|
||||
|
|
Loading…
Reference in New Issue