gfx-rs/wgpu · error

Could not lock instance. This is most-likely a deadlock.

Error message

Could not lock instance. This is most-likely a deadlock.

What it means

Panic in the GLES Instance::raw_display: try_lock on the instance mutex failed, meaning another thread holds it — the code assumes this can only happen on deadlock. The faulty input is concurrent access to the EGL instance internals.

Source

Thrown at wgpu-hal/src/gles/egl.rs:704

#[derive(Clone, Debug)]
struct WindowSystemInterface {
    kind: WindowKind,
}

#[derive(Debug)]
pub struct Instance {
    wsi: WindowSystemInterface,
    flags: wgt::InstanceFlags,
    options: wgt::GlBackendOptions,
    inner: Mutex<Inner>,
}

impl Instance {
    pub fn raw_display(&self) -> khronos_egl::Display {
        self.inner
            .try_lock()
            .expect("Could not lock instance. This is most-likely a deadlock.")
            .egl
            .display
    }

    /// Returns the version of the EGL display.
    pub fn egl_version(&self) -> (i32, i32) {
        self.inner
            .try_lock()
            .expect("Could not lock instance. This is most-likely a deadlock.")
            .version
    }
}

#[cfg(send_sync)]
static_assertions::assert_impl_all!(Instance: Send, Sync);

impl crate::Instance for Instance {
    type A = super::Api;

View on GitHub (pinned to 3e11ff59bf)

Solutions

1. Avoid calling raw_display/egl_version concurrently with operations holding the instance lock
2. Restructure threading so EGL instance access is serialized

When it happens

Trigger: Thrown at wgpu-hal/src/gles/egl.rs:704 when the library encounters an invalid state.

Common situations: See trigger scenarios.

AI-assisted analysis of gfx-rs/wgpu@3e11ff59bf (2026-09-03). Data as JSON: /api/errors/3707a8528d784f9f. Report an issue: GitHub.