If you could try the blender-3.5.0-alpha+master.1beaec46b8e3 available on Buildbot as of +/- 14:50 CET, both on Fedora Linux 37 Intel and macOS Big Sur Intel it is now working again, with thanks to Sergey!

The same happens here too, both on macOS Big Sur Intel as well as on Fedora Linux 37 Workstation, launching from the Terminal produces a blender.crash.txt file with the following content:

Compiled Blender myself, again thanks to and with help from @Ray Molenkamp (LazyDodo) and got the following stack with X11 and Fedora Linux 37 Beta:

Not that I know of, @Victoria De Blois (VictoriaDeBlois), it is that currently support for Wayland is being built into Blender after having none before.

With help from @Ray Molenkamp (LazyDodo) I got the following stack when running under X11:

I just tried on Ubuntu 22.10 with X11 and I get the exact same crash. I also tried the Fedora Linux 37 beta with X11 and then I get the exact same crashes on Fedora as well! Switching back to Wayland opens Blender without those crashes again.

I think I saw elsewhere that you are running an Ubuntu distro (duh, your screendump gives some away), which version would that be...? I could try a Live boot on the machines that I tried it with, and see if it is hardware related...? Normally we would need a Developer to test and verify this issue, but they are, most of them, not all, at the Blender Conference at the moment...

@Everton Schneider (eversimo) I tried the daily build version from yesterday as well as the version from today (Blender Conference 2022 Day!) on Fedora Linux 37 beta (kernel 5.19.17 and Python3.11) and both Blender 3.4.0 Alphas launch without such crashing.

Even with build rB1fbd300adb9a of today, the anomaly still remains, an extra generic icon instead of the (also present) official Blender icon in the Dash. Even tried with deleting all settings from ~/.config/blender

The daily build rBcbe1c1474b16 I downloaded was an extra poked build from several hours after the commit mentioned in T101779, but I will try again tomorrow morning!

That resulted into this:

Here you are:

What version of macOS and what exact version of Blender are you trying to use, @Paul Wolfs (pauluspj) ?

I entered:

Update your system to Apple their macOS 12.2.1, as is available for download, you might have better results then...

Can confirm this with Daily Build 3.1.0 Beta 27d3140b1363 from 2022-02-12, rendering on Fedora 35 Linux...

@Miiro Seppänen (miiroseppanen) At my end Blender 3.1.0 Alpha has become "launchable" again!

Same as https://developer.blender.org/T95039, could be fixed by now, however, wait for tonights Buildbot edition...

I tried this on Blender 3.0.0 release on Fedora 35 Linux and can reproduce the behaviour there as well.

Have you tried to launch Blender from the command line (RUN) with:

And the same problem here, on an Apple MacBook pro from 2012 with macOS Catalina 10.15.7 and that 007 Security update, everything appears fine using Cycles, but as soon as Eevee becomes the renderer of choice, pressing F12 to render any scene, even a blank one, crashes Blender 3.0 Beta right back into the Finder.

People will be asking for more information, what computer, what OS, graphics card, which exact version of Blender...

Hello Sybren,

When I disable the "Text Files" checkmark in the Filter list, the few files starting with a dot will disappear, no longer be shown.

Files none, directories yes

Are you by any chance running your Linux distro with Wayland enabled...? Could you try and see if things are ok when running your system with X11...? You will need to specify that at login time, by clicking the clog gear in the lower right corner...

Just tried with the latest 3.0.0 Alpha 5280d4bf0bf6 running on macOS 10.15.7 (Catalina) and there are no hidden files or dot files visible in the File Browser when trying to open a file, regardless of the "Hide Dot File & Data-Blocks" setting in the Blender Preferences...

And the T87962 toggle can still not be done, the rest I could try and do without Blender crashing.

Did so by adding the following to the ~/.bashrc file:

I think I may have found the cause...

What made me report this problem / bug, even though I know that the GPU in that old crate is not a truely supported one, is that I rendered CPU only, then a GPU should not be involved, right...? 🤔

Using rB4e65b1ef6cda no crash log was written to /tmp, but I did grab this from the Terminal:

With daily build rBae379714e4f1 I had Blender 3.0.0 Alpha crash at the fifth step / bullet already.

Closing this report, reporting it at GNOME and hoping this report does stay inside the system, for others who may run into the same situation...

I just tried Blender 3.0.0 Alpha rB5f5cf21a833f and the problem is still there, switching Blender to "Window Fullscreen" and the mouse cursor in the viewport disappears. The same happens in a webbrowser (Brave / Chrome) too, when watching a YouTube video and then going fullscreen there, again the mouse cursor disappears, making it hard to change settings like resolution of the video.

I can not reproduce this problem on two Macintosh laptops (macOS 10.15.7 and 11.4), only on the Linux box I have access to.

Just for information, I am running the daily builds of Blender 2.93 beta (and before that alpha) on both Fedora 33 and 34, rendering the default cube on CPU only, not having a decent GPU at this moment. Renders as expected.

@Evan Wilson (EAW) That is not what we are seeing at https://builder.blender.org/download/daily/, there the hash code has been d5c3bff6e774 for three days in a row now, with changing archive file sizes for 2.93 beta.

The downloaded archive filesize is different too, not just on the Linux version, the Mac version too.

In T88431#1163528, @Brecht Van Lommel (brecht) wrote:

From the logs, I think it's already there.
https://builder.blender.org/admin/#/builders/10/builds/257/steps/6/logs/stdio

However it seems to not find OpenMP and Jack, which is an issue.

@Pearlcrafts Are you really still on macOS Big Sur 11.0...? Apple has release many a required update for Big Sur already, at the moment of writing they are at 11.3.1 and 11.4 has seen daylight as a Release Candidate, should be out any day now.

Tried that on macOS 10.15.7 and found that you need to press the Tab key an additional four times to get from the RGB values into the Alpha value.

@Julian Eisel (Severin) Why not just remove the active region for this action completely? When the File Browser is active it is already at the top of all other Blender windows and can safely "listen" to a user pressing the Enter or Return keys...

@Julian Eisel (Severin) +1

I have been asking about this many times and versions, it is the same design flaw as T82002. The Enter key indeed only works when the mouse is over the file list, yet we need to click the filename itself, outside the file list, in order change it into the name we want to...

The problem is with Mutter, when following the following test fix, Blender can be toggled back and forth to fullscreen windows with a visible mouse cursor:

The same happens on two machines here, one with Fedora 33 Linux kernel 5.11.11, as well as on a MacBook Pro 13" running macOS 10.15.7, with the 3d7e3d5ad0b4 build from thursday evening as well as with the 0515ff70ec09 build from yesterday evening.

This #e0a1a2f49dab on an Apple MacBook Pro 13" from 2016 (running Big Sur 11.2.3 as well) with an Intel 540, not sure what you mean with Sharp though:

Working fine on an older MacBook Pro 13" with just an Intel HD 4000, running on macOS 10.15.7, as mentioned in https://developer.blender.org/T75832

@Nate (nlate) I just tried Blender 2.93 Alpha 321eef6a0c0f from April 3rd 2021 on an older MacBook Pro 13" with Intel HD 4000 running macOS 10.15.7 and there I can not reproduce the crash, this without a "Load Factory Settings" though...

When there is a default button, that entire dialog / window should respond to pressing the "Enter" or "Return" key, not just when the mouse is in / hovering over a smaller area of that dialog / window.

I can reproduce the bug under Fedora 33 and an Apple (Intel based) Macintosh with macOS Big Sur 11.2.1 too, both rendering on CPU only, with the description given by @Shankar Sivarajan (shankarsivarajan) :

Apple calls their operating system "macOS" these days, not "Mac OS X" anymore... ;)

With the build 3a1d1aaa86d0 from December 17th, 2020, HardOps (00986_MercuryX_33) can be enabled again, as well as BoxCutter (717_11). Delete your Blender Configs directory one more time and then install them.

What happens when you delete (or rename) your Blender Configs directory, a.k.a. start completely fresh, even fresher than a "Load Factory Settings"...? For Windows that would be in:

On an old MacBook Pro running 10.15.6 I can reproduce the problem with 2.91.0 Beta, branch: master, commit date: 2020-11-13 00:36, hash: rB2e08500d047e, Blender will completely crash and disappear, leading to the macOS its "has unexpectedly crashed" message.

Perhaps not a steady white but the color set in the Blender theme preferences...

@Richard Antalik (ISS) The glitch is a constant flickering while rendering, in the statusbar in the upper left, which shows the time rendered, time remaining, memory usage. Those numbers and their explaining meanings are rapidly flickering between white, red and cyan colors, while I personally think they should remain at a steady white...

Could not reproduce this with Blender hash 21cb6f09ffa8 on macOS 10.15.6 and Intel HD Graphics 4000

Seen a similar problem with mesa 20.04, it got fixed with mesa 20.07 and up

In D7893#190695, @William Reynish (billreynish) wrote:

Adding the ability to use bold and italics is nice, but probably we should add this properly using real font variants rather than generated variations, which are almost always a lot worse that bespoke weights.

And if we do that, I think it might be a good time to actually review the UI font we use to begin with - it's quite an old font that has since ben bested by other, better UI fonts.

I can reproduce on Fedora 32, start Blender, Load Factory Settings and select the default cube, hide it with the "h"-key and then pressing the TAB-key, this on Blender 2.83 Beta e5ace51295b9.

With the overnight update of the Fedora 32 Mesa drivers to version 20.0.7 Blender 50ef801a79b5 no longer crashes and also the current nightly build e5ace51295b9 does not crash upon closing the Preference and File Browser windows! Many thanks Clément (and others!) for your attention, time and patience!

Blender 2.90 Alpha f9d0f59bed4d works now, did the patch make it into Blender 2.83 Beta yet? For the buildbot version 50ef801a79b5 still crashes unfortunately...