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:
Kefu Chai 2018-11-29 11:24:33 -08:00 committed by Facebook Github Bot
parent 8d9b4d9741
commit 7dbee38716
1 changed files with 2 additions and 1 deletions

View File

@ -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;
}