This only happens in the GNOME environment. I tried Blender in another environment (KDE), and everything worked normally. In fact, the stable version also has this same bug. Both environments share the Wayland system, and I don’t understand why this only happens in GNOME. Does anyone have any idea what is going on here?
1 Like
How did you install Blender? (Flatpak or distro package? What distro?) What graphics card does your system use? What drivers? We need details about the problem, to be able to guess at a solution. (Yes, I’m realizing now that “graphics card” makes me sound 200 years old.)
3 Likes
In fact, regardless of the format in which you install and/or run it, that error will always be there (Flatpak, Appimage, By Command, etc.). I use the Fedora distribution, with an NVIDIA GTX 1650, and the latest driver is 580.82.09.
I explained that when I start Blender and try to go to the preferences tab (or another window within Blender), it gets stuck on a gray box, freezing everything (I mean Blender itself, not the GNOME environment), and to close it I had to use Mission Center to force it to shut down. I don’t understand why, I’ve already reported it to Blender, but it seems they don’t realize it
You’ve tried all those methods, or you’re just guessing? Because, different builds can exhibit different behaviors, especially in an application as complex as Blender.
You’re doing better than I am. On my F42 system, with an underpowered Intel chipset and integrated GPU, both the Fedora package and the Flatpak build of Blender 4.5.2 crash immediately on startup without ever showing any window:
$ /usr/bin/blender
EGL Error (0x3009): EGL_BAD_MATCH: Arguments are inconsistent (for example, a valid context requires buffers not supplied by a valid surface).
EGL Error (0x3009): EGL_BAD_MATCH: Arguments are inconsistent (for example, a valid context requires buffers not supplied by a valid surface).
EGL Error (0x3009): EGL_BAD_MATCH: Arguments are inconsistent (for example, a valid context requires buffers not supplied by a valid surface).
EGL Error (0x3009): EGL_BAD_MATCH: Arguments are inconsistent (for example, a valid context requires buffers not supplied by a valid surface).
Writing: /tmp/blender.crash.txt
[1] 3563275 segmentation fault (core dumped) blender
$ flatpak run org.blender.Blender
EGL Error (0x3009): EGL_BAD_MATCH: Arguments are inconsistent (for example, a valid context requires buffers not supplied by a valid surface).
EGL Error (0x3009): EGL_BAD_MATCH: Arguments are inconsistent (for example, a valid context requires buffers not supplied by a valid surface).
EGL Error (0x3009): EGL_BAD_MATCH: Arguments are inconsistent (for example, a valid context requires buffers not supplied by a valid surface).
EGL Error (0x3009): EGL_BAD_MATCH: Arguments are inconsistent (for example, a valid context requires buffers not supplied by a valid surface).
Writing: /tmp/blender.crash.txt
It’s too bad you’re not getting a crash, since it probably means Blender isn’t writing a /tmp/blender.crash.txt file for you.
(Not that the one I’m getting is much help:)
$ cat /tmp/blender.crash.txt
# Blender 4.5.2, Commit date: 1970-01-01 00:00, Hash unknown
# backtrace
blender(+0xc4ff47) [0x560deba0df47]
blender(+0x3b860f) [0x560deb17660f]
/lib64/libc.so.6(+0x1a070) [0x7f4afa028070]
blender(+0xf0349f) [0x560debcc149f]
blender(+0xea5ded) [0x560debc63ded]
blender(+0xf1e043) [0x560debcdc043]
blender(+0xf2224c) [0x560debce024c]
blender(+0x31f5b8) [0x560deb0dd5b8]
/lib64/libc.so.6(+0x3575) [0x7f4afa011575]
/lib64/libc.so.6(__libc_start_main+0x88) [0x7f4afa011628]
blender(+0x39c995) [0x560deb15a995]
# Python backtrace
I couldn’t say whether it would work under KDE for me, as I don’t have it installed. I can’t explain why you’d see freezing behavior only in GNOME, either, that’s pretty weird.
Blender has a lot of command-line options, you could try running it from a terminal window with either or both of these flags:
blender --factory-startup --debug-gpu-force-workarounds
The first tells it not to load any user settings or extensions, just in case there’s something there causing issues. The second will “Enable workarounds for typical GPU issues and disable all GPU extensions.” There’s also --debug-wm to log any issues with the window manager communication, which is the most likely difference between running under KDE vs. GNOME.
(Interestingly, I can’t even get Blender to not-crash if I run blender -E help, which is supposed to list the available rendering engines. It can’t even get that far. But, my GPU’s total uselessness probably explains that.)
I have the same issue since the update to gnome 49 on arch linux. I tried different installations of blender (arch packages, flatpack, and an installation through steam). All have the same issue. I also have a nvidia GPU (RTX 4080 Super) with driver version 580.82.09.
I tried to find any logs that could point to the problem (journalctl -f, running blender with –debug-wm or –log “ghost.wl.*” --log-level 2 ). But so far I was not able to find any information that seems to be related to an error.
Any help or ideas would be appreciated.
You are most likely running into mutter#4196
Yep, same issue here, is anyone able to look into this? If I had the skills I would help, perhaps I can help with some data collection, let me know!
Here is an image of the freeze effect
As already commented in Every Blender version from version 4.1.0 upward freezes on startup (#4196) · Issues · GNOME / mutter · GitLab, I looked into this and this was caused by a client side issue (not acknowledging the first configure) and the current main branch already had a workaround for such broken clients, because of another client with the same issue. The current main branch is what will become 49.1.
You can work around this by pressing win + right clicking the window and choosing to resize the window.
Thanks for getting back to this @Ser82-png ! Can you elaborate more on how the GNOME window client does not acknowledge the first configure? Will gnome 49.1 be released anytime soon, or would you recommend just downgrading to blender prior to 4.1.0?
Do you know why the resizing hack works, by the way? I’m particularly interested in looking into why this happened as well to potentially trace other app issues to this problem. Thanks again for your response!
