Saving while shaders are compiling in Eevee causes Blender's window to disappear (but not crash) on Wayland #100437

New Issue

MultisampledNight · 2022-08-16T13:37:37+02:00

MultisampledNight commented

2022-08-16 13:37:37 +02:00

System Information
Operating system: Linux-5.19.1-zen1-1-zen-x86_64-with-glibc2.36 64 Bits
Graphics card: Mesa Intel(R) Iris(R) Plus Graphics (ICL GT2) Intel 4.6 (Core Profile) Mesa 22.1.6
Wayland compositor: Sway 1.7

Blender Version
Broken: version: 3.4.0 Alpha, branch: master, commit date: 2022-08-14 13:19, hash: 39bad22008
Worked: I don't think this problem has been introduced recently
Build command: make CMAKE_CONFIG_ARGS='-DWITH_GHOST_WAYLAND=ON -DOPENGLES_EGL_LIBRARY=/usr/lib/libwayland-egl.so' release

Short description of error
When working on a larger material on a not very powerful machine, compiling shaders can take several seconds. Saving the current file while those shaders compile first causes Blender to not respond to any UI input for several seconds and then disappear, while the process itself seems to be still running (determined through pgrep blender), at least for a few seconds.

Through a bit of timing play, I was able to extract a backtrace through running sleep 4 && kill -SEGV $(pgrep blender) a few times to let Blender segfault right in the moment after saving. This way the coredump ended being catched by systemd and available in coredumpctl, I attached the backtrace and would be happy to provide the coredump to anyone who needs it. I'm not sure how valid it is though, I could have easily mistimed (all other attempts only involved the first few calls until the usleep, this was the only one yielding more).

I believe this is a Wayland-only issue. Not quite sure though, I haven't been able to try on X11.

Exact steps for others to reproduce the error

Open the attached .blend
Add one extra noise texture node to the chain (don't connect it to the shader yet!)
Connect it to the shader and hit Ctrl + S as fast as possible (while the viewport still lists Compiling shaders)
Observe Blender to first hang and then crash

(the example .blend contains a lot of noise textures to simulate a large material)
crash-on-save.blend
backtrace.txt

**System Information** Operating system: Linux-5.19.1-zen1-1-zen-x86_64-with-glibc2.36 64 Bits Graphics card: Mesa Intel(R) Iris(R) Plus Graphics (ICL GT2) Intel 4.6 (Core Profile) Mesa 22.1.6 Wayland compositor: Sway 1.7 **Blender Version** Broken: version: 3.4.0 Alpha, branch: master, commit date: 2022-08-14 13:19, hash: `39bad22008` Worked: I don't think this problem has been introduced recently Build command: `make CMAKE_CONFIG_ARGS='-DWITH_GHOST_WAYLAND=ON -DOPENGLES_EGL_LIBRARY=/usr/lib/libwayland-egl.so' release` **Short description of error** When working on a larger material on a not very powerful machine, compiling shaders can take several seconds. Saving the current file while those shaders compile first causes Blender to not respond to any UI input for several seconds and then disappear, while the process itself seems to be still running (determined through `pgrep blender`), at least for a few seconds. Through a bit of timing play, I was able to extract a backtrace through running `sleep 4 && kill -SEGV $(pgrep blender)` a few times to let Blender segfault right in the moment after saving. This way the coredump ended being catched by systemd and available in `coredumpctl`, I attached the backtrace and would be happy to provide the coredump to anyone who needs it. I'm not sure how valid it is though, I could have easily mistimed (all other attempts only involved the first few calls until the `usleep`, this was the only one yielding more). I believe this is a Wayland-only issue. Not quite sure though, I haven't been able to try on X11. **Exact steps for others to reproduce the error** - Open the attached .blend - Add one extra noise texture node to the chain (don't connect it to the shader yet!) - Connect it to the shader and hit Ctrl + S as fast as possible (while the viewport still lists `Compiling shaders`) - Observe Blender to first hang and then crash (the example .blend contains a lot of noise textures to simulate a large material) [crash-on-save.blend](https://archive.blender.org/developer/F13393573/crash-on-save.blend) [backtrace.txt](https://archive.blender.org/developer/F13393575/backtrace.txt)

MultisampledNight commented

2022-08-16 13:37:37 +02:00

Added subscriber: @multisn8-2

Omar Emara commented

2022-08-16 16:10:10 +02:00

Added subscriber: @OmarEmaraDev

Omar Emara commented

2022-08-16 16:10:10 +02:00

I can't reproduce the crash myself on X11, but I see no evidence of it being a Wayland specific issue.

Richard Antalik commented

2022-08-17 03:36:52 +02:00

Added subscribers: @ideasman42, @iss

Richard Antalik commented

2022-08-17 03:36:52 +02:00

CC @ideasman42

Campbell Barton commented

2022-08-19 15:47:26 +02:00

Managed to redo this but it's quite difficult to reproduce reliably, as this doesn't crash it's also difficult to investigate. Unless some way can be found to make this bug cause a crash instead of closing the window.

Unless we're able to fix this, this bug could be worked around by using solid shading when building shaders is in progress. P3150.

Managed to redo this but it's quite difficult to reproduce reliably, as this doesn't crash it's also difficult to investigate. Unless some way can be found to make this bug cause a crash instead of closing the window. Unless we're able to fix this, this bug could be worked around by using solid shading when building shaders is in progress. [P3150](https://archive.blender.org/developer/P3150.txt).

MultisampledNight commented

2022-08-21 12:36:54 +02:00

After using Blender a bit longer on this not very powerful machine, I found the same symptoms also appearing in other lengthy processes (importing textures, changing material settings such as Screenspace Reflections, the like). So I switched to X11 and tried out the exact same things that have lead to hiding the window on Wayland, but instead of doing that, the UI just froze for a bit and then recovered again.

This makes me think of another thing I had with running the winit examples on Wayland: Windows without explicitly drawn content are also not composited. Maybe Blender's UI thread is somehow held up by doing other tasks, "misses" to send a wl_surface::attach request when it's time for a new frame, the compositor gives a bit of grace time but then just doesn't draw the window anymore, leaving Blender up confused until it recovers again in a whole different state? Just guessing, I don't know how Blender is architectured.

After using Blender a bit longer on this not very powerful machine, I found the same symptoms also appearing in other lengthy processes (importing textures, changing material settings such as Screenspace Reflections, the like). So I switched to X11 and tried out the exact same things that have lead to hiding the window on Wayland, but instead of doing that, the UI just froze for a bit and then recovered again. This makes me think of another thing I had with running the [winit](https:*github.com/rust-windowing/winit) examples on Wayland: Windows without explicitly drawn content are also not composited. Maybe Blender's UI thread is somehow held up by doing other tasks, "misses" to send a [wl_surface::attach](https:*wayland.app/protocols/wayland#wl_surface:request:attach) request when it's time for a new frame, the compositor gives a bit of grace time but then just doesn't draw the window anymore, leaving Blender up confused until it recovers again in a whole different state? Just guessing, I don't know how Blender is architectured.

Campbell Barton commented

2022-08-22 10:50:31 +02:00

@multisn8-2 thanks for looking into this, from your investigation is seems this may be a more general issue with Wayland, nevertheless, would you be able to test Blender built with P3150 applied to check if the workaround is effective?

@multisn8-2 thanks for looking into this, from your investigation is seems this may be a more general issue with Wayland, nevertheless, would you be able to test Blender built with [P3150](https://archive.blender.org/developer/P3150.txt) applied to check if the workaround is effective?

MultisampledNight commented

2022-08-22 12:41:03 +02:00

Unfortunately even with the patch applied and rebuilt, Blender's still disappearing following the instructions from above.

Campbell Barton commented

2022-08-25 08:14:42 +02:00

@multisn8-2 could you confirm that setting the "Save & Load", "File Preview Type" to None doesn't crash?

MultisampledNight commented

2022-08-25 08:47:51 +02:00

@ideasman42 At first it seemed like it solved the issue, but after growing the noise chain longer and longer, the UI doesn't freeze directly, but rather after some time (and doesn't recover anymore, i.e. "crash"). Like some first stage has completed and now the real fun part begins. (thank you though! this should at least help with medium-sized materials)

@ideasman42 At first it seemed like it solved the issue, but after growing the noise chain longer and longer, the UI doesn't freeze *directly*, but rather after some time (and doesn't recover anymore, i.e. "crash"). Like some first stage has completed and now the real fun part begins. (thank you though! this should at least help with medium-sized materials)

Campbell Barton commented

2022-08-25 09:31:32 +02:00

@multisn8-2 does the window vanish when you make the node-chain longer? Or does Blender just hang?

Could you double check this issue happens with other compositors? (gnome-shell for e.g.).

@multisn8-2 does the window vanish when you make the node-chain longer? Or does Blender just hang? Could you double check this issue happens with other compositors? (gnome-shell for e.g.).

Pratik Borhade commented

2022-08-27 08:52:00 +02:00

Changed status from 'Needs Triage' to: 'Needs User Info'

MultisampledNight commented

2022-08-27 13:24:55 +02:00

After making the node chain longer and hitting Ctrl + S, Blender

lists Compiling Shaders, but is still interactable
hangs while displaying the last interactable frame

vanishes

in that order, delay of a few seconds between each one, hang -> vanish being a bit shorter.

I don't have GNOME nor other compositors installed right now, and I think the first time I'm back with a more consistent internet connection will be Sept. 4th (CEST), sorry. Possible that something opens up in-between though.

After making the node chain longer and hitting Ctrl + S, Blender - lists `Compiling Shaders`, but is still interactable - hangs while displaying the last interactable frame # vanishes in that order, delay of a few seconds between each one, hang -> vanish being a bit shorter. I don't have GNOME nor other compositors installed right now, and I think the first time I'm back with a more consistent internet connection will be Sept. 4th (CEST), sorry. Possible that something opens up in-between though.

MultisampledNight commented

2022-09-04 13:11:05 +02:00

Alright, so after trying out gnome-shell, I can partly reproduce this after making the node chain longer and hitting Ctrl + S. Blender then

lists Compiling Shaders, but is still interactable
hangs while displaying the last interactable frame
instead of vanishing, GNOME displays the casual Blender does not respond dialog with two buttons Wait and Force quit (translated, semantic stays the same)
becomes responsive again and GNOME's force quite dialog vanishes

1 -> 2 takes some time, 2 -> 3 -> 4 are all just several seconds, without vanishing/crashing. For now I'll use gnome-shell then. Do note that your patch is still applied.

Alright, so after trying out gnome-shell, I can *partly* reproduce this after making the node chain longer and hitting Ctrl + S. Blender then - lists `Compiling Shaders`, but is still interactable - hangs while displaying the last interactable frame - instead of vanishing, GNOME displays the casual `Blender does not respond` dialog with two buttons `Wait` and `Force quit` (translated, semantic stays the same) - becomes responsive again and GNOME's force quite dialog vanishes 1 -> 2 takes some time, 2 -> 3 -> 4 are all just several seconds, without vanishing/crashing. For now I'll use gnome-shell then. Do note that your patch is still applied.

Campbell Barton commented

2022-09-06 14:46:07 +02:00

While investigating this, I found a similar issue which is simpler to redo, reported as #100855 (GHOST/Wayland: Terminal Ctrl-C closes the window while Python is running).

Campbell Barton commented

2022-09-10 09:03:18 +02:00

@multisn8-2 I attempted to redo this (I now have sway building locally), but can't I ended up investigating a similar issues #100855 which is quite straightforward to redo and may even be the same bug, although it's hard to say.

While the protocol states that windows that don't respond to a ping have behavior defined by the compositor, see: https:*wayland.app/protocols/xdg-shell#xdg_wm_base:event:ping Sway currently should keep the window open, see: https:*github.com/swaywm/sway/issues/1706

There is a limit to how much time it's reasonable to spend investigating bugs we can't properly reproduce, and that may even be bugs in the compositor.

Proposing the following steps:

Check if this problem exists for other compositors (KDE for e.g. not sure if there are other popular & stable compositors).
If this bug is not reproducible in other * compositors then consider this a bug with Blendwer+SWAY that needs further investigation set the status to "Known Issue".

* it probably makes sense to check with compositors that aren't based on wlroots since these may share the same bug, although if river doesn't have this problem (for e.g.) it would be good to know.

@multisn8-2 I attempted to redo this (I now have sway building locally), but can't I ended up investigating a similar issues #100855 which is quite straightforward to redo and may even be the same bug, although it's hard to say. While the protocol states that windows that don't respond to a ping have behavior defined by the compositor, see: https:*wayland.app/protocols/xdg-shell#xdg_wm_base:event:ping Sway currently should keep the window open, see: https:*github.com/swaywm/sway/issues/1706 There is a limit to how much time it's reasonable to spend investigating bugs we can't properly reproduce, and that may even be bugs in the compositor. Proposing the following steps: - Check if this problem exists for other compositors (KDE for e.g. not sure if there are other popular & stable compositors). - If this bug is not reproducible in other `*` compositors then consider this a bug with Blendwer+SWAY that needs further investigation set the status to "Known Issue". `*` it probably makes sense to check with compositors that aren't based on `wlroots` since these may share the same bug, although if river doesn't have this problem (for e.g.) it would be good to know.

MultisampledNight commented

2022-09-10 14:41:33 +02:00

I tested KDE Plasma and weston:

KDE exhibited the same behavior as Sway, although it felt like the gracetime was a bit longer than on Sway. What's worth noting that on another occasion when using the hot corner in the upper left corner which shows all windows in an overview, switching back to Blender sometimes led into the Blender window being greyed out and KDE showing <Not responding> in the window title. I haven't been able to consistently perform this though, so I won't create another report.
weston was unable to launch Blender at all, blender --factory-startup only yielded

GHOST/Wayland: xdg_wm_base@15: error 4: xdg_surface geometry (2256 x 1504) does  not match the configured maximized state (1920 x 1168)

as output. Which might be related to this system having two screens, one of them being HiDPI.

If you feel like it's more of the compositor's choice here for hiding the window if it's just busy doing other tasks, that's completely fine. Feel free to mark this as invalid and I'll take it to the Sway issue tracker then (and probably get no response). Though I'm not sure what's the way to go here.

I tested KDE Plasma and weston: - KDE exhibited the same behavior as Sway, although it felt like the gracetime was a bit longer than on Sway. What's worth noting that on another occasion when using the hot corner in the upper left corner which shows all windows in an overview, switching back to Blender sometimes led into the Blender window being greyed out and KDE showing `<Not responding>` in the window title. I haven't been able to consistently perform this though, so I won't create another report. - weston was unable to launch Blender at all, `blender --factory-startup` only yielded ``` GHOST/Wayland: xdg_wm_base@15: error 4: xdg_surface geometry (2256 x 1504) does not match the configured maximized state (1920 x 1168) ``` as output. Which might be related to this system having two screens, one of them being HiDPI. If you feel like it's more of the compositor's choice here for hiding the window if it's just busy doing other tasks, that's completely fine. Feel free to mark this as invalid and I'll take it to the Sway issue tracker then (and probably get no response). Though I'm not sure what's the way to go here.

Campbell Barton commented

2022-09-12 03:52:02 +02:00

Changed status from 'Needs User Info' to: 'Needs Developer To Reproduce'

Campbell Barton commented

2022-09-12 03:52:02 +02:00

Thanks for checking, if this happens on KDE it seems likely not an issue isolated to SWAY.

Setting this as needing further investigation, if this is a common problem we will likely be able to redo this error or similar errors.

It might be best to investigate & fix #100855 first, since it's much simpler and check if this bug still exists afterwards.

Thanks for checking, if this happens on KDE it seems likely not an issue isolated to SWAY. Setting this as needing further investigation, if this is a common problem we will likely be able to redo this error or similar errors. It might be best to investigate & fix #100855 first, since it's much simpler and check if this bug still exists afterwards.

Campbell Barton commented

2022-11-10 01:41:43 +01:00

Closed as duplicate of #100855

Campbell Barton closed this issue

2022-11-10 01:41:43 +01:00

Campbell Barton commented

2022-11-10 01:42:35 +01:00

On further testing #100855 happens while any operator hangs (unrelated to Python), closing this as a duplicate as the other report is simpler to redo.

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Saving while shaders are compiling in Eevee causes Blender's window to disappear (but not crash) on Wayland #100437

vanishes