gitui-org/gitui · error
lock err
Error message
lock err
What it means
Notify<T> wraps a std::sync::Mutex; wait() does lock().expect("lock err"). A std Mutex lock only fails when the mutex is poisoned - some thread panicked while holding it. So this message is always a secondary symptom: the real failure is an earlier panic elsewhere (often one of gitui's render/path panics) that fired while the lock was held.
Source
Thrown at src/notify_mutex.rs:28
}
impl<T> NotifiableMutex<T>
where
T: Send + Sync,
{
///
pub fn new(start_value: T) -> Self {
Self {
data: Arc::new((Mutex::new(start_value), Condvar::new())),
}
}
///
pub fn wait(&self, condition: T)
where
T: PartialEq + Copy,
{
let mut data = self.data.0.lock().expect("lock err");
while *data != condition {
data = self.data.1.wait(data).expect("wait err");
}
drop(data);
}
///
pub fn set_and_notify(&self, value: T) {
*self.data.0.lock().expect("set err") = value;
self.data.1.notify_one();
}
///
pub fn get(&self) -> T
where
T: Copy,
{
*self.data.0.lock().expect("get err")View on GitHub (pinned to 2fa693cb6e)
Solutions
- Look UP the log (cache gitui.log) or terminal scrollback for the first panic - fix or report that one; 'lock err' is never the root cause.
- Update gitui - thread and panic handling improved across releases.
- If embedding a notify-mutex of this shape, recover with lock().unwrap_or_else(|e| e.into_inner()) or use parking_lot, whose mutexes do not poison.
Example fix
// before
let mut data = self.data.0.lock().expect("lock err");
// after: tolerate poisoning, keep the (consistent-enough) inner value
let mut data = self.data.0.lock().unwrap_or_else(|poisoned| poisoned.into_inner()); Defensive patterns
Strategy: fallback
Try / catch
// std-only recovery from a poisoned lock
let guard = match m.lock() {
Ok(g) => g,
Err(poisoned) => poisoned.into_inner(), // fall back to the inner value
}; Prevention
- Never panic while holding a shared mutex - move fallible work outside the critical section.
- Use parking_lot::Mutex (no poisoning) for notify-style primitives.
- Read the earlier panic in the log - 'lock err' is never the root cause.
When it happens
Trigger: Any panic in gitui while a worker thread holds the Notify's mutex (e.g. a status-tree or get-status panic between set_and_notify calls), followed by another thread calling wait().
Common situations: Shutdown races after a primary panic; flaky worker threads in older gitui versions; concurrency bugs introduced by local modifications.
Related errors
AI-assisted analysis of gitui-org/gitui@2fa693cb6e (2026-08-16).
Data as JSON: /api/errors/8ea614d4f270de82.
Report an issue: GitHub.