gitui-org/gitui · error
wait err
Error message
wait err
What it means
Inside Notify::wait(), the Condvar's wait() returns Err only when the re-acquired mutex is poisoned - another thread panicked while holding it. Like the sibling 'lock err', this is a downstream symptom of an earlier panic, surfaced on whichever thread happened to be waiting on the condition variable.
Source
Thrown at src/notify_mutex.rs:30
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
- Find the FIRST panic in gitui.log / scrollback and address that.
- Update gitui to a current release.
- For your own code: keep fallible work out of critical sections, or use parking_lot::Condvar which does not poison.
Example fix
// before
while *data != condition {
data = self.data.1.wait(data).expect("wait err");
}
// after: recover the guard from the poison error and keep going
while *data != condition {
data = match self.data.1.wait(data) {
Ok(g) => g,
Err(poisoned) => poisoned.into_inner(),
};
} Defensive patterns
Strategy: fallback
Try / catch
loop {
let guard = match cv.wait(guard) {
Ok(g) => g,
Err(poisoned) => poisoned.into_inner(), // keep waiting on the recovered guard
};
if matches!(&*guard, c if *c == condition) { break; }
} Prevention
- Keep condvar/mutex critical sections minimal and panic-free.
- Prefer parking_lot::Condvar/Mutex pairs, which do not poison.
- When a 'wait err' appears, hunt the first panic in the log, not the waiter.
When it happens
Trigger: A holder thread panicking while the mutex is held (any of gitui's expect()-based panics) while a second thread sits in wait(); common during event-loop shutdown races after an initial panic.
Common situations: Post-panic teardown; older gitui versions with panicking worker threads; local forks that added panics in locked sections.
Related errors
AI-assisted analysis of gitui-org/gitui@2fa693cb6e (2026-08-16).
Data as JSON: /api/errors/1c5817450a74727a.
Report an issue: GitHub.