Open keithchew opened 1 week ago
I can confirm that the above did not solve the root cause of the crash. I reviewed the code a bit more, and here is likely the correct fix in keysCommandCore() in db.cpp:
aeAcquireLock();
std::unique_lock<decltype(cIn->lock)> lock(cIn->lock); <---- ADD THIS
addReplyProto(cIn, c->buf, c->bufpos);
...
lock.unlock(); <---- ADD THIS
aeReleaseLock();
The above will ensure the
c->lock.fOwnLock()
condition is satisfied. Will continue testing to make sure all is stable.
After reviewing the code a bit more on locks, I have tidied up the above a little:
AeLocker ae;
std::unique_lock<decltype(cIn->lock)> lock(cIn->lock, std::defer_lock);
bool fAsync = !FCorrectThread(cIn);
if (!fAsync) {
lock.lock();
ae.arm(c);
} else {
aeAcquireLock();
}
...
if (!fAsync) {
ae.disarm();
lock.unlock();
} else {
aeReleaseLock();
}
Based on my testing, so far the keys command is solid and no crashes or deadlocks...
Testing on async_flash branch, but this bug has been around before that:
Looking at the code, it looks like the assert check should be done after the fast exit checks? ie:
This will not fix the crash if the fast exit checks pass, so will try it on my local first and see if the crash happens again.