gfx-rs/wgpu-rs

dropping an Instance with the GL backend bit segfaults when not on the main thread

igowen opened this issue · 4 comments

Description

Spawning a thread that creates a new Instance with the GL backend bit set will segfault when the Instance is dropped.

I found this crash extremely counterintuitive, especially since the GL backend appears to be non-functional on my machine and wgpu chooses Vulkan as the most suitable backend; I was technically asking for the GL backend because i was passing BackendBit::all() to Instance::new().

An unfortunate side effect of this is that Instance cannot be used in tests if the GL backend is requested since (at least by default) tests execute in multiple threads.

Repro steps

minimal repro case:

fn run() {
    let instance = wgpu::Instance::new(wgpu::BackendBit::GL);
}

fn main() {
    let handle = std::thread::spawn(|| {
        run();
    });
    handle.join().unwrap();
}

Expected vs observed behavior
Expected: no segfaults; ideally this would just panic if the instance were created in an unsupported manner.
Observed: segfault

Platform
OS: Linux (NixOS) / Wayland
GPU: Intel
wgpu 0.7.0
backend: GL

i did find #607 while investigating this, but i think that is a different issue (this is not a panic).

kvark commented

Thank you for filing!
If I understand correctly, you aren't blocked, since you can simply not use the ::GL bit for your tests.
However, the crash is surely a bug on our side. I could think of two options:

  1. Make Instance non-Send
  2. Fix the GL backend to check the current thread on drop, and issue an error in the log instead of actually trying to self-destruct
kvark commented

This is actually a duplicate o f gfx-rs/wgpu#246

so it is! i'll go ahead and close this issue, then. thanks!

for the record -

  1. Make Instance non-Send

i don't think this would actually make a difference in this case, since the Instance's entire lifecycle is contained within the secondary thread.