wgpu-py 0.26.0 crash with imgui?

[hmaarrfk]

Describe the bug

On linux + wayland (the only platform i tested on)

$ python examples/imgui_multi_canvas.py 
Unable to find extension: VK_EXT_physical_device_drm
Detected skylake derivative running on mesa i915. Clears to srgb textures will use manual shader clears.
Segmentation fault (core dumped)

causes a segfault.

To Reproduce

conda create --name pygfx python=3.12 pip --channel conda-forge --override-channels
conda activate pygfx
pip install imgui-bundle rendercanvas
pip install -e . -vv

Observed behavior

Segfault.

I'm like 90% sure it happens in the call to

self._device.create_render_pipeline

in
https://github.com/pygfx/wgpu-py/blob/main/wgpu/utils/imgui/imgui_backend.py#L295C33-L295C68

I bisected it to the merge of 27.0.2.0 #741

Screenshots

If applicable, add screenshots to help explain your problem.

Your environment

Details about the environment this issue was observed on, like OS, Python version, wgpu-py version.
You can also include (the relevant sections of) the result of wgpu.diagnostics.print_report().

██ system:

             platform:  Linux-6.17.0-5-generic-x86_64-with-glibc2.42
python_implementation:  CPython
               python:  3.12.12

██ versions:

wgpu:  0.25.0.post2+gcbd97e2

██ wgpu_native_info:

No data

██ object_counts:

                      count  resource_mem

            Adapter:      0
          BindGroup:      0
    BindGroupLayout:      0
             Buffer:      0
      CanvasContext:      0
      CommandBuffer:      0
     CommandEncoder:      0
 ComputePassEncoder:      0
    ComputePipeline:      0
             Device:      0
     PipelineLayout:      0
           QuerySet:      0
              Queue:      0
       RenderBundle:      0
RenderBundleEncoder:      0
  RenderPassEncoder:      0
     RenderPipeline:      0
            Sampler:      0
       ShaderModule:      0
            Texture:      0
        TextureView:      0

              total:      0             0

[hmaarrfk]

The really weird thing, is that if i add some kind of ipdb, or something strange, it will get through things in my application.

[Vipitis]

Sadly enough it works on my machine.

do you always get these warnings?

Unable to find extension: VK_EXT_physical_device_drm
Detected skylake derivative running on mesa i915. Clears to srgb textures will use manual shader clears.

perhaps you have other adapters or backends to tests against available?
My experience is that the wgpu-native debug release doesn't provide any more useful errors either.

Also does it apply to all the imgui examples?
there were two debug releases for wgpu since 27.0.2 but doesn't sound like any crashes were fixed.

(side note, maybe we should put adapter info into the diagnostics report)

[hmaarrfk]

do you always get these warnings?

Unable to find extension: VK_EXT_physical_device_drm
Detected skylake derivative running on mesa i915. Clears to srgb textures will use manual shader clears.

yes. always.

[hmaarrfk]

Also does it apply to all the imgui examples?

yes i just checked on all the examples starting with imgui_

[hmaarrfk]

Sadly enough it works on my machine.

are you on linux or windows?

[Vipitis]

that was with windows.

I wonder what feature is imgui specific that could make it crash... also I wonder if it's changes in the commit or just the wgpu-native library. You might be able to checkout a commit before and just run tools/download_wgpu_native.py --version 27.0.2.0 as not too much has changed.

[hmaarrfk]

you are correct.

• Commit 249a0a2 <-- no crash
• Commit cbd97e2 <-- segfault

Screencast.From.2025-10-27.21-07-05.mp4

[hmaarrfk]

If i revert the changes to wgpu/backends/wgpu_native/_api.py. No segfault.

If i simply make the following diff:

diff --git a/wgpu/backends/wgpu_native/_api.py b/wgpu/backends/wgpu_native/_api.py
index ba63305..7b81377 100644
--- a/wgpu/backends/wgpu_native/_api.py
+++ b/wgpu/backends/wgpu_native/_api.py
@@ -2108,7 +2108,7 @@ class GPUDevice(classes.GPUDevice, GPUObjectBase):
         # H: nextInChain: WGPUChainedStruct *, topology: WGPUPrimitiveTopology, stripIndexFormat: WGPUIndexFormat, frontFace: WGPUFrontFace, cullMode: WGPUCullMode, unclippedDepth: WGPUBool/int
         c_primitive_state = new_struct(
             "WGPUPrimitiveState",
-            nextInChain=next_in_chain,
+            # nextInChain=next_in_chain,
             topology=primitive.get("topology", "triangle-list"),
             stripIndexFormat=primitive.get("strip_index_format", 0),
             frontFace=primitive.get("front_face", "ccw"),

no crash either.

could it be that my tiny intel GPU doesn't have polygon features?

[Vipitis]

Great investigative work!

could it be that my tiny intel GPU doesn't have polygon features?

Can be the case, but the polygon mode feature needs to be requested anyway to work. And the default should just be "fill": https://docs.rs/wgpu/latest/wgpu/struct.PrimitiveState.html
It's most likely a pointer related crash since those chained structs use a pointer - and that will cause crashes if they are pointing to something GC cleans up for example, or accessed later. It took me several days to figure this around around limits and features several updates ago. Some backends are fine if the struts contain additional fields, others simply crash... so that's also a possibility. I believe I left some notes to myself in the PRs or code once I understood the crashes. Worst part is that it also crashes any python debugger and you lose the state (maybe that improved with the 3.13 and 3.14 debugger additions, haven't tried).

Not at my computer right now. But maybe it's possible to set nextInChain=ffi.NULL (hopefully the same as omitting it) when no extras are requested. That's probably a better way than always passing the chained struct.

Can look into that maybe tomorrow or later the week too, it's like the only feature added in the update too 🫠

[hmaarrfk]

Understood. The hint about a gc issue is probably since the bug didn't happen depending on if I added pdb or not.

FYI:

nextInChain=ffi.NULL

this seems to stop the crashes for me.

[Vipitis]

Additionally, this came to mind: Imgui likely passes a dict instead of a struct for primitive state. Which is how we determine if extras are requested or not: #741 (comment)

Likely means we never checked the dict+no extras case... but then again works on some machines.

also here is one of my notes to self: #718 (comment)

[Vipitis]

The hint about a gc issue is probably since the bug didn't happen depending on if I added pdb or not.

my experience has been the opposite, where inspecting the pointer object with the debugger crashed the python process including the attached debugger (debugpy in vscode).

It's probably worth fixing the logic, validating that features are requested on the device (some backends handle this gracefully and fallback to defaults, others apparently not), and writing a test or example so this is covered by CI at least (currently isn't).

[hmaarrfk]

Something like this:

diff --git a/wgpu/backends/wgpu_native/_api.py b/wgpu/backends/wgpu_native/_api.py
index 320d122..5bdfbf4 100644
--- a/wgpu/backends/wgpu_native/_api.py
+++ b/wgpu/backends/wgpu_native/_api.py
@@ -2058,8 +2058,10 @@ class GPUDevice(classes.GPUDevice, GPUObjectBase):
         primitive_extras = {}
         if isinstance(primitive, dict):
             # in case of extras, the struct isn't used but a dict... so we check for it here.
-            primitive_extras["polygon_mode"] = primitive.pop("polygon_mode", "Fill")
-            primitive_extras["conservative"] = primitive.pop("conservative", False)
+            if (polygon_mode := primitive.pop("polygon_mode", None)) is not None:
+                primitive_extras["polygon_mode"] = polygon_mode
+            if (conservative := primitive.pop("conservative", None)) is not None:
+                primitive_extras["conservative"] = conservative
         check_struct("VertexState", vertex)
         check_struct("DepthStencilState", depth_stencil)
         check_struct("MultisampleState", multisample)
@@ -2086,19 +2088,22 @@ class GPUDevice(classes.GPUDevice, GPUObjectBase):
         )
 
         # explanations for extras: https://docs.rs/wgpu/latest/wgpu/struct.PrimitiveState.html
-        polygon_mode = enum_str2int["PolygonMode"].get(
-            primitive_extras.get("polygon_mode"), enum_str2int["PolygonMode"]["Fill"]
-        )
+        if len(primitive_extras) == 0:
+            next_in_chain = ffi.NULL
+        else:
+            polygon_mode = enum_str2int["PolygonMode"].get(
+                primitive_extras.get("polygon_mode"), enum_str2int["PolygonMode"]["Fill"]
+            )
 
-        # H: chain: WGPUChainedStruct, polygonMode: WGPUPolygonMode, conservative: WGPUBool/int
-        c_primitive_state_extras = new_struct_p(
-            "WGPUPrimitiveStateExtras *",
-            # not used: chain
-            polygonMode=polygon_mode,
-            conservative=primitive_extras.get("conservative", False),
-        )
-        c_primitive_state_extras.chain.sType = lib.WGPUSType_PrimitiveStateExtras
-        next_in_chain = ffi.cast("WGPUChainedStruct *", c_primitive_state_extras)
+            # H: chain: WGPUChainedStruct, polygonMode: WGPUPolygonMode, conservative: WGPUBool/int
+            c_primitive_state_extras = new_struct_p(
+                "WGPUPrimitiveStateExtras *",
+                # not used: chain
+                polygonMode=polygon_mode,
+                conservative=primitive_extras.get("conservative", False),
+            )
+            c_primitive_state_extras.chain.sType = lib.WGPUSType_PrimitiveStateExtras
+            next_in_chain = ffi.cast("WGPUChainedStruct const *", c_primitive_state_extras)
 
         # H: nextInChain: WGPUChainedStruct *, topology: WGPUPrimitiveTopology, stripIndexFormat: WGPUIndexFormat, frontFace: WGPUFrontFace, cullMode: WGPUCullMode, unclippedDepth: WGPUBool/int
         c_primitive_state = new_struct(

does stop my crashes.

But do you have a test that actually tests the non null usage?

[almarklein]

It looks like the main problem is that _create_render_pipeline_descriptor creates the struct, but the caller of that function passes that struct to wgpu-native. This means that when the function exits, gc kicks in, and anything that is not 'attached' to the struct (as in having a Python reference, so the gc does not clean it up) will be removed.

I think this is a bug that affects all backends, but in some cases it simply gets lucky and the memory access still works (no segfault, and memory has not yet been overwritten).

There are more pointers in that struct, and there it works fine. IIUC the main problem is the cast of the next_in_chain, so the c_primitive_state_extras is not part of the struct as far as the Python gc is concerned.

A solution could be is to put that object in a list, and return it along with the struct to the caller, so that it survives a little longer; long enough for wgpu-native to 'consume' the struct.