Fix: Make sure we release the Write-Lock

This was suggested by Marcel Müller, who also debugged this issue and
found that this snippet was the error.

The problem was, that we had the write-lock when starting the hooks. If
the hook runs into an Err() mapping part where the Entry could already
be drop()ed, Rust tries to be smart and drops the object. As we are
still in the creation code of the entry, this paniced as we still hold
the W-Lock and the drop() tryies to call _update() on the entry, which
also tries to W-lock it.

With the new additional scope, the W-lock gets dropped early and we do
not have this problem anymore.

Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
Suggested-by: Marcel Müller <neikos@neikos.email>
Reported-by: Matthias Beyer <mail@beyermatthias.de>
This commit is contained in:
Matthias Beyer 2016-08-01 19:59:43 +02:00
parent 6e988782da
commit 7b5d37a039

View file

@ -390,19 +390,21 @@ impl Store {
.map_err_into(SEK::CreateCallError)
}
let mut hsmap = match self.entries.write() {
Err(_) => return Err(SEK::LockPoisoned.into_error()).map_err_into(SEK::CreateCallError),
Ok(s) => s,
};
{
let mut hsmap = match self.entries.write() {
Err(_) => return Err(SEK::LockPoisoned.into_error()).map_err_into(SEK::CreateCallError),
Ok(s) => s,
};
if hsmap.contains_key(&id) {
return Err(SEK::EntryAlreadyExists.into_error()).map_err_into(SEK::CreateCallError);
if hsmap.contains_key(&id) {
return Err(SEK::EntryAlreadyExists.into_error()).map_err_into(SEK::CreateCallError);
}
hsmap.insert(id.clone(), {
let mut se = StoreEntry::new(id.clone());
se.status = StoreEntryStatus::Borrowed;
se
});
}
hsmap.insert(id.clone(), {
let mut se = StoreEntry::new(id.clone());
se.status = StoreEntryStatus::Borrowed;
se
});
let mut fle = FileLockEntry::new(self, Entry::new(id));
self.execute_hooks_for_mut_file(self.post_create_aspects.clone(), &mut fle)