Hello,
I am on the Fedora 38 KDE version, and Blender refuses to boot. This is happening with both the Flathub and the default Fedora-repository versions.
I receive a crash report for either package, and in both of them, the stated reason is:
blender killed by SIGSEGV
Is this a common problem? Does anyone know how to fix this? Or should I just wait for a fix to be introduced with an update?
Thank you in advance.
i updated my Blender just today and tested on F38 Gnome it works fine. Quick Google on SIGSEGV tells
in computing, a segmentation fault or access violation is a fault, or failure condition, raised by hardware with memory protection, notifying an operating system the software has attempted to access a restricted area of memory. On standard x86 computers, this is a form of general protection fault.
at this point my knowledge is not enough to move forward, but more details you can provide more easier to sorting the issue
How much memory does your system have? Maybe you ran out of memory.
You can check the system journal with journalctl for clues, also the output of dmesg.
Try running sudo journalctl -f in one terminal then start blender.
Do you see errors?
Hello again,
First, I tried switching to a different version of Fedora, so I installed the emerging immutable spin “Kinoite”, now f39, still KDE. I installed Flathub Blender 4.0.0.
Blender still refuses to boot, but I’m not receiving a crash-alert in the bottom right corner now on Kinoite as I had previously.
So I finally decided to take this seriously and ran sudo journalctl -f in a terminal before trying again, as you said.
I recieved these errors:
[🡕] Process 14834 (blender) of user 1000 dumped core.
Module /app/blender/lib/libboost_serialization.so.1.80.0 without build-id.
Module /app/blender/lib/libboost_serialization.so.1.80.0
Module /app/blender/lib/libboost_locale.so.1.80.0 without build-id.
Module /app/blender/lib/libboost_locale.so.1.80.0
Module /app/blender/lib/libboost_wave.so.1.80.0 without build-id.
Module /app/blender/lib/libboost_wave.so.1.80.0
Module /app/blender/lib/libboost_regex.so.1.80.0 without build-id.
Module /app/blender/lib/libboost_regex.so.1.80.0
Module /app/blender/lib/libboost_chrono.so.1.80.0 without build-id.
Module /app/blender/lib/libboost_chrono.so.1.80.0
Module /app/blender/lib/libboost_system.so.1.80.0 without build-id.
Module /app/blender/lib/libcycles_kernel_oneapi_aot.so without build-id.
Module /app/blender/lib/libcycles_kernel_oneapi_aot.so
Module /app/blender/lib/libboost_iostreams.so.1.80.0 without build-id.
Module /app/blender/lib/libboost_iostreams.so.1.80.0
Module /app/blender/lib/libboost_date_time.so.1.80.0 without build-id.
Module /app/blender/lib/libboost_filesystem.so.1.80.0 without build-id.
Module /app/blender/lib/libboost_filesystem.so.1.80.0
Module /app/blender/lib/libboost_python310.so.1.80.0 without build-id.
Module /app/blender/lib/libboost_python310.so.1.80.0
Module /app/blender/lib/libembree4.so.4 without build-id.
Module /app/blender/lib/libembree4.so.4
Module /app/blender/lib/libboost_thread.so.1.80.0 without build-id.
Module /app/blender/lib/libboost_thread.so.1.80.0
Module /app/blender/lib/libtbb.so.2 without build-id.
Module /app/blender/lib/libtbb.so.2
Stack trace of thread 2:
#0 0x00007f92f51293cb n/a (/usr/lib/x86_64-linux-gnu/libwayland-client.so.0.22.0 + 0x93cb)
#1 0x00007f92df9e2aa9 n/a (/usr/lib/x86_64-linux-gnu/GL/default/lib/libEGL_mesa.so.0.0.0 + 0x2aaa9)
#2 0x00007f92df9e32c2 n/a (/usr/lib/x86_64-linux-gnu/GL/default/lib/libEGL_mesa.so.0.0.0 + 0x2b2c2)
#3 0x00007f92df9d75aa n/a (/usr/lib/x86_64-linux-gnu/GL/default/lib/libEGL_mesa.so.0.0.0 + 0x1f5aa)
#4 0x00007f92df9cb735 n/a (/usr/lib/x86_64-linux-gnu/GL/default/lib/libEGL_mesa.so.0.0.0 + 0x13735)
#5 0x00000000027d04a3 n/a (/app/blender/blender + 0x23d04a3)
ELF object binary architecture: AMD x86-64
As expected, I am really out of my depth here. If anyone knows what’s going on, or how to solve this, I would be extremely grateful.
User Marko Jokinen above cited a SIGSEGV article that mentioned it may be related to an issue caused by “memory-protected hardware”. The memory-type on this system is DDR5, which does have a newer kind of ECC built-in, or “on-die” as it’s called. Perhaps the issue lies there?
Its not ECC that is referred to, ECC fixes bit errors in RAM modules transparently.
I expect what is being referred to is changes in the kernel to ensure memory is not corrupted by buggy code.
But I suspect its a simple code bug or library incompatibility.
Have you tested blender install from fedora repos?
I know its not 4.0.0 version, but it will give you a data point.
Have you tested blender install from fedora repos?
I know its not 4.0.0 version, but it will give you a data point.
Unfortunately, Kinoite prevents me from easily installing the other packages. I regret acting so hastily and switching versions…
I know there is a way to allow the normal packages, but I’ll have to look into it and report back.
Thank you for your help so far, I’ll see if I can get more error codes.
FYI the blender maintainer is trying to package blender 4 but there are issues compiling it for arm that are holding up the work.
I decided to check the error code again, and learned I can run a debugger to find out more information. This was with GNU gdb.
Here the last bit of the dump, which includes the part at the bottom that I think is most important:
Downloading executable for /usr/lib/x86_64-linux-gnu/libutil.so.1
warning: Can't open file /usr/lib/x86_64-linux-gnu/libutil.so.1 during file-backed mapping note processing
warning: Can't open file /usr/lib/locale/en_US.utf8/LC_MEASUREMENT during file-backed mapping note processing
warning: Can't open file /usr/lib/locale/en_US.utf8/LC_IDENTIFICATION during file-backed mapping note processing
Downloading executable for /usr/lib/x86_64-linux-gnu/spa-0.2/support/libspa-journal.so
warning: Can't open file /usr/lib/x86_64-linux-gnu/spa-0.2/support/libspa-journal.so during file-backed mapping note processing
warning: Can't open file /app/blender/lib/libtbb.so.2 during file-backed mapping note processing
Downloading executable for /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
warning: Can't open file /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 during file-backed mapping note processing
[New LWP 2]
[New LWP 7]
[New LWP 8]
[New LWP 4]
[New LWP 11]
[New LWP 10]
[New LWP 14]
[New LWP 3]
[New LWP 12]
[New LWP 15]
[New LWP 9]
[New LWP 5]
[New LWP 13]
[New LWP 6]
[New LWP 40]
[New LWP 41]
[New LWP 42]
[New LWP 43]
[New LWP 48]
[New LWP 44]
[New LWP 55]
[New LWP 16]
[New LWP 46]
[New LWP 58]
[New LWP 45]
[New LWP 36]
[New LWP 39]
[New LWP 17]
[New LWP 50]
[New LWP 57]
[New LWP 51]
[New LWP 49]
[New LWP 56]
[New LWP 47]
[New LWP 52]
[New LWP 19]
[New LWP 18]
[New LWP 53]
[New LWP 20]
[New LWP 54]
[New LWP 21]
[New LWP 22]
[New LWP 23]
[New LWP 24]
[New LWP 25]
[New LWP 26]
[New LWP 27]
[New LWP 28]
[New LWP 29]
[New LWP 30]
[New LWP 31]
[New LWP 32]
[New LWP 33]
[New LWP 35]
[New LWP 34]
Missing separate debuginfo for the main executable file.
The debuginfo package for this file is probably broken.
warning: Section `.reg-xstate/2' in core file too small.
Downloading separate debug info for system-supplied DSO at 0x7ffd083e1000
Core was generated by `./blender'.
Program terminated with signal SIGSEGV, Segmentation fault.
warning: Section `.reg-xstate/2' in core file too small.
#0 0x00007f878dc9e3cb in ?? ()
[Current thread is 1 (LWP 2)]
(gdb)
The "warning"s at the beginning of this paste seem to be unimportant, I received a bunch of them in the dump and I think it might just be an issue with the debugger.
However, judging by the:
warning: Section
.reg-xstate/2' in core file too small. Downloading separate debug info for system-supplied DSO at 0x7ffd083e1000 Core was generated by./blender’.
Program terminated with signal SIGSEGV, Segmentation fault.
part at the very end, could it be that a file is simply too small? How can I set this to the appropriate size, and stop SIGSEGV from killing Blender?
That, on the face of it, is a problem with the way that blender was compiled and linked. I am assuming its an ELF section that is being referred to.
Which version of blender are you using and from where did you get it?
I installed blender RPM for Fedora 39 and then started blender.
It starts with no issue.
$ rpm -q blender
blender-4.0.1-2.fc39.x86_64
It was still with the Flathub version, f39, as that is still the easiest way to get it installed on Kinoite for me…
I did end up finding a fix, and that was to simply switch to X11 in the Log In menu rather than Wayland. I swear I tried this before, around when I first made this post for f38 / KDE Plasma spin. So I just didn’t think to try it again on my new install until now.
I’m still not sure what was causing the original problem, but I hope it somehow gets fixed before Fedora decides to remove X11 as was proposed for f40.
Thank you very much for trying to help out here Barry!
I believe this is the first time you mentioned kinoite. When using any of the immutable versions of fedora it is really important we know which version you are running. For example, dnf works on the rpm versions but rpm-ostree is used on the immutable versions. This is a major differing factor.
I added the kinoite tag for you.
I appreciate the tag, I didn’t know how to do that myself.
I mentioned switching to Kinoite earlier in the chain with this post, but I can understand it being easy to miss since I only briefly mentioned it. I was hoping that changing versions would have somehow solved my problem, but sadly it persisted…
I’m glad the X11 trick worked in any case, and thank you for the clarifications.