gitui-org/gitui · error
get err
Error message
get err
What it means
Notify::get() locks the shared mutex to copy the value out; expect("get err") fires only on poisoning - an earlier panic on a thread that held the lock. All four notify_mutex expects ('lock'/'wait'/'set'/'get' err) are the same failure class: std mutex poisoning after a panic elsewhere in the process.
Source
Thrown at src/notify_mutex.rs:46
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
- Treat as noise until the first panic in the log is fixed; that is the actionable one.
- Update gitui.
- For embedded variants, use unwrap_or_else(|p| p.into_inner()) on lock results or a non-poisoning mutex implementation.
Example fix
// before
*self.data.0.lock().expect("get err")
// after
*self.data.0.lock().unwrap_or_else(|poisoned| poisoned.into_inner()) Defensive patterns
Strategy: fallback
Try / catch
let value = *m.lock().unwrap_or_else(|poisoned| poisoned.into_inner());
Prevention
- Treat lock-poison messages as trailing noise from an earlier panic; fix that one.
- Use non-poisoning mutexes in shared-state code you control.
- Log the original panic location (RUST_BACKTRACE=1) to shorten diagnosis.
When it happens
Trigger: Any reader thread calling get() after a writer or another reader panicked while holding the mutex; typical during the fallout of one of gitui's render panics on a background thread.
Common situations: Secondary crash lines after the real panic; logs where multiple threads report lock failures in sequence.
Related errors
AI-assisted analysis of gitui-org/gitui@2fa693cb6e (2026-08-16).
Data as JSON: /api/errors/f4c1d3a0ae1f1743.
Report an issue: GitHub.