Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 880671 - media-gfx/blender-3.3.0: Crash on startup, possibly due to mixing LLVM 14 or 15
Summary: media-gfx/blender-3.3.0: Crash on startup, possibly due to mixing LLVM 14 or 15
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Adrian
Depends on:
Reported: 2022-11-10 00:18 UTC by Joshua Goins
Modified: 2023-09-22 00:14 UTC (History)
6 users (show)

See Also:
Package list:
Runtime testing required: ---

output of emerge --info (file_880671.txt,9.14 KB, text/plain)
2022-11-10 00:18 UTC, Joshua Goins
blender 3.3 backtrace (file_880671.txt,2.89 KB, text/plain)
2022-11-10 00:18 UTC, Joshua Goins
blender 3.1.2 backtrace (file_880671.txt,2.75 KB, text/plain)
2022-11-10 00:19 UTC, Joshua Goins
blender-3.3-build-log.txt.xz (blender-3.3-build-log.txt.xz,176.12 KB, application/x-xz)
2022-11-10 00:21 UTC, Joshua Goins
equery u blender output (file_880671.txt,4.51 KB, text/plain)
2022-11-10 00:24 UTC, Joshua Goins
blender 3.3 llvm 15+16 backtrace (file_880671.txt,3.63 KB, text/plain)
2023-07-16 19:21 UTC, zack

Note You need to log in before you can comment on or make changes to this bug.
Description Joshua Goins 2022-11-10 00:18:08 UTC
Created attachment 830243 [details]
output of emerge --info

I wanted to boot up Blender again, only to find out that it crashes on startup. In Blender 3.1 (the current amd64 stable version as of writing), it dumps a backtrace to /tmp/blender.crash.txt which can be found below. For some reason, Blender 3.3 does not report a stacktrace properly, but I was able to glean it from GDB.

Taking a look at the stacktrace, it's stepping between LLVM 14 and 15 and then the DRI driver for my radeonsi is included somewhere. I'll probably compile it with debug symbols soon to see if there's anything useful there. At first, I thought it was mesa bug #6976 ([Bisected][RadeonSI] Blender crashes on startup) but this was fixed 3 months ago, and I have mesa 22.2.3 installed. This is confirmed by the fact that when downloading the official Blender Linux build, it works just fine!

LLVM 15 is at 15.04
LLVM 14 is at 14.06-r2

Oh yeah, and I also attached the blender 3.3 build log, but I haven't tried to glean anything from it yet.
Comment 1 Joshua Goins 2022-11-10 00:18:37 UTC
Created attachment 830245 [details]
blender 3.3 backtrace
Comment 2 Joshua Goins 2022-11-10 00:19:13 UTC
Created attachment 830247 [details]
blender 3.1.2 backtrace
Comment 3 Joshua Goins 2022-11-10 00:21:48 UTC
Created attachment 830249 [details]
Comment 4 Joshua Goins 2022-11-10 00:24:13 UTC
Created attachment 830251 [details]
equery u blender output
Comment 5 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2022-11-10 05:10:16 UTC
It's mixing LLVM 14 and LLVM 15, yeah :(
Comment 6 Sebastian Parborg 2022-11-10 12:38:29 UTC
Sadly I can't really do anything about this.
I've filed a ticket about this last year here:

At one point I was thinking about doing a manual ldd in the install phase to see if multiple llvm versions were linked in and error out if that was the case.
However this does not catch the mesa llvm version.
In addition to that, one could update mesa and the llvm version after the the package has been installed and get crashes that way.

So I'm starting to think that static linking is the only way out of this.
(This is what the official Blender build do)
Comment 7 Sebastian Parborg 2022-11-10 12:41:35 UTC
You should be able to work around this by unmasking a newer version of osl.
It will be built with llvm 15.
Comment 8 Joshua Goins 2022-11-10 13:59:50 UTC
Thank you, I had a suspicion that Blender was statically linking LLVM (it explains why their binaries are like 250+ mb!) I thought I had unmasked osl, but I’ll check again when I can get back to my computer.
Comment 9 Joshua Goins 2022-11-10 15:41:10 UTC
Yes, using osl ~amd64 and then recompiling both blender versions fixed it. Thank you! For some reason, I can only mark this as "RESOLVED" (which isn't really the right option, I thought there was more?), I'll leave that up to your discretion :-)
Comment 10 Sebastian Parborg 2022-11-10 16:35:50 UTC
I think we can leave it open in case someone else with the same issue ends up here.
Comment 11 Franz Brauße 2023-03-28 13:41:44 UTC
It's happening now also with LLVM-15 vs. LLVM-16 (~amd64). As before, blender with USE=-osl fixes it for me.
Comment 12 Lorenzo Bertini 2023-04-27 10:36:00 UTC
Can confirm with LLVM 15 and 16 (~amd64). Using "-osl" makes it finally start, but rendering a benchmark scene produces a segmentation fault with the usual backtrace
#1  0x... in  () at /usr/lib/llvm/16/lib64/
Comment 13 Sebastian Parborg 2023-05-01 15:41:30 UTC
(In reply to Lorenzo Bertini from comment #12)
> Can confirm with LLVM 15 and 16 (~amd64). Using "-osl" makes it finally
> start, but rendering a benchmark scene produces a segmentation fault with
> the usual backtrace
> #1  0x... in  () at /usr/lib/llvm/16/lib64/

Could you perhaps build Blender with debug flags so we can see where it is crashing?
Comment 14 zack 2023-07-16 19:21:50 UTC
Created attachment 865610 [details]
blender 3.3 llvm 15+16 backtrace

This still happens with the current gentoo repository. Blender appears to use both LLVM 15 and LLVM 16 at the same time, and segmentation faults on startup.
Comment 15 zack 2023-07-16 19:47:10 UTC
I have another Gentoo system which does not have LLVM 16 installed yet, and the segmentation fault does not reproduce there. It seems the best/only workaround for this is:

  cat <<EOF> /etc/portage/package.mask/llvm

  emerge --unmerge '>=sys-devel/llvm-16' '>=sys-devel/clang-16' '>sys-devel/llvmgold-16'

  revdep-rebuild # rebuilds mesa in particular

  emerge --depclean

After doing this, blender starts without a Segmentation Fault, and does not crash while rendering.

It would be convenient if the blender and/or osl ebuild were able to entirely prevent the installation of llvm-16 until osl catches up.
Comment 16 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2023-07-17 16:22:23 UTC
commit d6af608ad3b3519f7cbd4e4158afbb7c979d887c
Author: Sebastian Parborg <>
Date:   Sun Jul 2 23:06:55 2023 +0200

    media-gfx/blender: Disable OSL support per default

    Because llvm 16 is now marked stable, there is a very high chance of
    users having Blender sefault on startup because of missmatched llvm

    Signed-off-by: Sebastian Parborg <>
    Signed-off-by: Sam James <>