- User Since
- Mar 29 2019, 1:07 PM (121 w, 1 d)
Did so by adding the following to the ~/.bashrc file:
I think I may have found the cause...
Thu, Jul 15
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:
Wed, Jul 14
With daily build rBae379714e4f1 I had Blender 3.0.0 Alpha crash at the fifth bullet already.
Wed, Jul 7
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...
Sat, Jul 3
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.
Jun 2 2021
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.
May 27 2021
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.
May 24 2021
@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.
May 23 2021
The downloaded archive filesize is different too, not just on the Linux version, the Mac version too.
May 21 2021
@irfan (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.
May 13 2021
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.
May 12 2021
@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...
May 6 2021
May 5 2021
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...
May 1 2021
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:
Apr 10 2021
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.
Apr 7 2021
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:
Apr 5 2021
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...
Mar 20 2021
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.
Feb 27 2021
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) :
Feb 17 2021
Apple calls their operating system "macOS" these days, not "Mac OS X" anymore... ;)
Jan 7 2021
Jan 6 2021
Dec 21 2020
Dec 17 2020
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.
Dec 16 2020
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:
Dec 12 2020
Nov 17 2020
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.
Nov 1 2020
Oct 23 2020
Perhaps not a steady white but the color set in the Blender theme preferences...
Oct 20 2020
@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...
Oct 18 2020
Sep 20 2020
Aug 26 2020
Could not reproduce this with Blender hash 21cb6f09ffa8 on macOS 10.15.6 and Intel HD Graphics 4000
Aug 5 2020
Jul 6 2020
Seen a similar problem with mesa 20.04, it got fixed with mesa 20.07 and up
Jun 3 2020
May 18 2020
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.
May 17 2020
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!
May 13 2020
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...
May 12 2020
It also happens with:
May 8 2020
Fedora 32 here... Semi rolling release...
May 7 2020
I concur with Eric, still crashing with hash 9605c2616696 here
May 3 2020
Worked fine before I went from Fedora 31 to Fedora 32... And the crashes only occur when closing an extra Blender window, like Preferences or the File Browser, nothing exciting there...
Operating system: Linux-5.6.8-300.fc32.x86_64-x86_64-with-fedora-32-Thirty_Two 64 Bits
Graphics card: AMD JUNIPER (DRM 2.50.0 / 5.6.8-300.fc32.x86_64, LLVM 10.0.0) X.Org 3.3 (Core Profile) Mesa 20.0.5
Continues to crash with version: 2.83 (sub 15), branch: master, commit date: 2020-05-02 11:33, hash: rB1623fdb3bc55
May 1 2020
Additional info: Didn't have this issue under Fedora 31... And Blender 2.79 doesn't have this problem while being under Fedora 32
Problem also exists in the official Blender 2.82a release, on the same system, after having deleted the complete ~/.config/blender directory...
Apr 24 2020
This on several of the machines at my disposal, both on macOS and Linux...
Mar 1 2020
Jan 15 2020
With the current beta 2.82 and macOS 10.15.2 Catalina I have not had the problem yet, no...
Jan 14 2020
I do not think it is a bug but activating Blender its factory-setup does not go far / deep enough, it does not delete preference files. Back then Blender crashed and kept crashing, until I manually deleted the Preferences folder for Blender.
Jan 13 2020
I have been running the 2.82 beta on that same machine now, which has been updated to Ubuntu 19.10 in the mean time. So not an issue at this moment, no.
Jan 2 2020
In the mean time I have updated / upgraded to Fedora 31 and with the current build from December 30th 2019, switching to fullscreen and back presents no problems.
Oct 9 2019
This morning I downloaded the most recent Daily Build, version rB0812949bbc3d and found that it had the exact same problem. I tried launching it using the Terminal with a --factory-setup, still crashed right upon launching.
Oct 1 2019
Sep 25 2019
Sep 24 2019
Jul 23 2019
Here are some of the requested info-files, all created on the same machine, just switching between Fedora 30, where the Window Fullscreen causes a crash upon returning and Ubuntu 19.04, where it works like a charm... :
Jul 12 2019
Unable to reproduce on macOS 10.14.5, MacBook Pro Mid 2012, Intel HD Graphics 4000, works fine with everything accessible.
Jul 9 2019
Jun 27 2019
Is there anything I can do to test that? It is not a machine with a real GPU, just an Intel HD 4000.
The earlier Ubuntu test was on another machine running 18.04.2LTS, but for completeness, I just formatted the machine running Fedora 30 and installed Ubuntu 19.04 on it, Blender its "Toggle Window Fullscreen" performed flawlessly.
Jun 26 2019
I grab Blender 2.80 beta daily and yes, three or four version back it worked fine.
Jun 25 2019
Jun 15 2019
Are your popup menus and drop down menus from the menu bar transparent by any chance...? Then it could be related to UI graphics glitches on macOS with Intel HD 4000...?
Jun 6 2019
This is the exact same problem as T65383, where a "Load Factory Settings" unfortunately doesn't change things. On a cleanly installed macOS machine with just Buildbot daily Blender 2.80 beta's installed.
Jun 2 2019
Here you go:
On Blender 2.80 (sub 72) things were fine, didn't download sub 73, so can't tell when the UI artifacts got introduced. Nothing else changed on the machine except for a newer daily build of Blender.
Then I get this:
Jun 1 2019
Tried the same buildbot version on another machine under Ubuntu 18.04.2 LTS and there the UI artifacts don't appear, just the macOS version (10.14.5)
Mar 30 2019
That would be?