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.