{"record":{"id":"56ffbb37ae973fc3","repo":"zellij-org/zellij","slug":"cannot-acquire-poisoned-lock-for-e","errorCode":null,"errorMessage":"cannot acquire poisoned lock for {e:#?}","messagePattern":"cannot acquire poisoned lock for (.+?)","errorType":"exception","errorClass":"anyhow::Error","httpStatus":null,"severity":"critical","filePath":"zellij-utils/src/errors.rs","lineNumber":976,"sourceCode":"                            msg\n                        ))\n                        .with_context(|| context.to_string())\n                    } else {\n                        Err(anyhow::anyhow!(\"failed to send message to channel\"))\n                            .with_context(|| context.to_string())\n                    }\n                },\n            }\n        }\n    }\n\n    impl<U> ToAnyhow<U> for Result<U, std::sync::PoisonError<U>> {\n        fn to_anyhow(self) -> anyhow::Result<U> {\n            match self {\n                Ok(val) => anyhow::Ok(val),\n                Err(e) => {\n                    if *crate::consts::DEBUG_MODE.get().unwrap_or(&true) {\n                        Err(anyhow::anyhow!(\"cannot acquire poisoned lock for {e:#?}\"))\n                    } else {\n                        Err(anyhow::anyhow!(\"cannot acquire poisoned lock\"))\n                    }\n                },\n            }\n        }\n    }\n}\n","sourceCodeStart":958,"sourceCodeEnd":985,"githubUrl":"https://github.com/zellij-org/zellij/blob/98a0837077492d53dd252ab30bc3e43e41e504f4/zellij-utils/src/errors.rs#L958-L985","documentation":"Debug-mode variant of the ToAnyhow implementation for std::sync::PoisonError in zellij-utils/errors.rs. A Mutex/RwLock became poisoned because some thread panicked while holding it, and now every subsequent .lock() on that lock fails and is converted to this error (including the poison payload in DEBUG_MODE). The lock itself is fine; the poison flag records that a holder bailed out mid-critical-section, so guarded state may be inconsistent.","triggerScenarios":"Any panic (unwrap, index out of bounds, assertion) inside a critical section guarded by the affected Mutex/RwLock, followed by any other thread attempting to lock it and piping the result through .to_anyhow()?.","commonSituations":"A rendering/pane-handling bug panics once while holding a shared lock; every later operation touching that lock then fails with poisoned-lock errors, cascading across threads. Almost always a zellij-internal bug, not user misconfiguration.","solutions":["Find the original panic in the log (the first panic, not the poison errors) — fix or report that; the poison cascade is downstream","Restart the zellij session; poison state cannot be cleared in-process","Upgrade zellij; several panics-under-lock bugs were fixed over releases","As a developer: keep critical sections panic-free (no unwrap/expect under locks) and shrink lock scope so a panic is unlikely inside it"],"exampleFix":"// before\nlet state = shared.lock().to_anyhow()?; // any later thread fails once poisoned\n\n// after: one designated recovery point, deliberate policy\nlet state = match shared.lock() {\n    Ok(g) => g,\n    Err(poisoned) => {\n        log::error!(\"lock poisoned, recovering guard; state may be inconsistent\");\n        poisoned.into_inner()\n    },\n};","handlingStrategy":"fallback","validationCode":null,"typeGuard":null,"tryCatchPattern":"use std::sync::{Mutex, PoisonError};\n\nfn lock_or_recover<T>(m: &Mutex<T>) -> Result<std::sync::MutexGuard<'_, T>, PoisonError<std::sync::MutexGuard<'_, T>>> {\n    // deliberate policy at one designated recovery point: state guarded by this\n    // lock is tolerant to partial writes, so recover the guard instead of failing\n    m.lock().map_err(|p| { log::error!(\"lock poisoned, recovering: {p}\"); p })\n}\n// usage: lock_or_recover(&shared).unwrap_or_else(|p| p.into_inner()).update();","preventionTips":["Never unwrap/expect/index inside a critical section; compute risky values before locking","Keep lock scopes minimal so panics cannot strike while holding the lock","Centralize lock acquisition behind helpers with a single documented poison policy","When you see this error, always fix the FIRST panic in the log — poison is only its shadow"],"tags":["mutex","poison","panic","concurrency","lock"],"backgroundTag":null,"analyzedSha":"98a0837077492d53dd252ab30bc3e43e41e504f4","analyzedAt":"2026-08-16T13:02:01.396Z","schemaVersion":2},"datasetVersion":"2026-08-16T13:17:31.715Z"}