What causes "{}" in gfx-rs/wgpu?

Read the panic text: it is the verbatim Vulkan validation message identifying the offending API call.

{}

Error message

{}

What it means

The Vulkan debug-utils messenger callback panics when the validation layer reports an Error-level, VALIDATION-type message that is not on the CTS waiver list. Instead of continuing with invalid API state, wgpu turns the validation error into an immediate panic so problems surface at the exact call site. The panic text is the raw validation message.

Source

Thrown at wgpu-hal/src/vulkan/instance.rs:179

        // Set canary and continue
        crate::VALIDATION_CANARY.add(message.to_string());
    }

    // We disable this on Apple because there are numerous issues, some of
    // which raise generic errors that we can't match by VUID. See
    // <https://github.com/gfx-rs/wgpu/issues/9184> and
    // <https://github.com/gfx-rs/wgpu/issues/9187>.
    #[cfg(all(
        debug_assertions,
        feature = "internal_error_panic",
        not(target_vendor = "apple")
    ))]
    if level == log::Level::Error
        && message_type.contains(vk::DebugUtilsMessageTypeFlagsEXT::VALIDATION)
        && !cts_error_is_waived(cd.message_id_number)
    {
        use alloc::string::ToString as _;
        panic!("{}", message.to_string());
    }

    vk::FALSE
}

/// Validation errors known to fire when running the CTS.
///
/// These waivers are keyed off the `WGPU_CTS_XTASK` environment variable, which
/// is set in `xtask/src/cts.rs`.
#[cfg(all(
    debug_assertions,
    feature = "internal_error_panic",
    not(target_vendor = "apple")
))]
fn cts_error_is_waived(message_id_number: i32) -> bool {
    use wgpu_sync::Lazy;

    static WGPU_CTS_XTASK: Lazy<bool> = Lazy::new(|| std::env::var_os("WGPU_CTS_XTASK").is_some());

View on GitHub (pinned to 3e11ff59bf)

Solutions

Read the panic text: it is the verbatim Vulkan validation message identifying the offending API call.
Run with validation layers and reproduce to get the call stack of the misused API.
Fix the underlying API misuse in the calling wgpu-hal code (wrong usage flags, invalid bind, sync hazard, etc.).
If the driver is incorrectly reporting a valid operation, verify against the Vulkan spec and update or bypass the layer; a CTS waiver can only be added for known CTS-specific false positives.

Defensive patterns

Strategy: validation

Validate before calling

// Ensure validation layers are on in dev so the panic reproduces with full context:
// VK_INSTANCE_LAYERS=VK_LAYER_KHRONOS_validation VK_VALIDATION_VALIDATE=1
// Also check whether the message id is a known waiver:
// see cts_error_is_waived in wgpu-hal/src/vulkan/instance.rs

Try / catch

// Panic originates in the driver-message callback; use the panic hook for diagnostics.
std::panic::set_hook(Box::new(|info| {
    log::error!("validation panic: {info}");
    // attach driver/GPU info and the validation message id
}));

Prevention

Fix validation messages at Warning level early; Error-level ones will panic.
Run the CTS after backend changes.
Verify suspect behavior against the Vulkan spec, not just layer silence.
Keep validation layers updated to reduce false positives.

When it happens

Trigger: Any Vulkan API call wgpu makes that a validation layer flags as an Error severity validation message, unless the message_id_number matches a known CTS waiver in `cts_error_is_waived`.

Common situations: Developers editing wgpu-hal introducing API misuse; running the CTS on a driver exposing genuine bugs; layer version mismatches flagging previously-legal usage; intentionally triggered during debugging (RUST_BACKTRACE/panic settings).

Related errors

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