media-gfx/blender-2.91 works. Portage force-updated it to 2.93 (the 2.91 does not exists anymore). 2.93 is faulty and segfaults: Thread 18 "blender-2.:sh3" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffb5ffb640 (LWP 11892)] 0x00007fffe942642f in AddNodeIDCustom(llvm::FoldingSetNodeID&, llvm::SDNode const*) () from /usr/lib/llvm/12/lib64/libLLVM-12.so (gdb) bt #0 0x00007fffe942642f in AddNodeIDCustom(llvm::FoldingSetNodeID&, llvm::SDNode const*) () at /usr/lib/llvm/12/lib64/libLLVM-12.so #1 0x00007fffc7208891 in llvm::FoldingSetBase::GetOrInsertNode(llvm::FoldingSetBase::Node*, llvm::FoldingSetBase::FoldingSetInfo const&) () at /usr/lib/llvm/11/lib64/libLLVM-11.so #2 0x00007fffc7ac74c6 in llvm::SelectionDAG::AddModifiedNodeToCSEMaps(llvm::SDNode*) () at /usr/lib/llvm/11/lib64/libLLVM-11.so #3 0x00007fffc7ac737e in llvm::SelectionDAG::ReplaceAllUsesWith(llvm::SDNode*, llvm::SDNode*) () at /usr/lib/llvm/11/lib64/libLLVM-11.so #4 0x00007fffc7939260 in llvm::SelectionDAG::Combine(llvm::CombineLevel, llvm::AAResults*, llvm::CodeGenOpt::Level) () at /usr/lib/llvm/11/lib64/libLLVM-11.so #5 0x00007fffc7ae1d59 in llvm::SelectionDAGISel::CodeGenAndEmitDAG() () at /usr/lib/llvm/11/lib64/libLLVM-11.so #6 0x00007fffc7ae5103 in llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) () at /usr/lib/llvm/11/lib64/libLLVM-11.so #7 0x00007fffc7ae7f56 in llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) () at /usr/lib/llvm/11/lib64/libLLVM-11.so #8 0x00007fffc8e3b72b in (anonymous namespace)::AMDGPUDAGToDAGISel::runOnMachineFunction(llvm::MachineFunction&) () at /usr/lib/llvm/11/lib64/libLLVM-11.so #9 0x00007fffc763b8a9 in llvm::MachineFunctionPass::runOnFunction(llvm::Function&) [clone .part.0] () at /usr/lib/llvm/11/lib64/libLLVM-11.so #10 0x00007fffc73fc674 in llvm::FPPassManager::runOnFunction(llvm::Function&) () at /usr/lib/llvm/11/lib64/libLLVM-11.so #11 0x00007fffc85f27d0 in (anonymous namespace)::CGPassManager::runOnModule(llvm::Module&) () at /usr/lib/llvm/11/lib64/libLLVM-11.so #12 0x00007fffc73fc0fb in llvm::legacy::PassManagerImpl::run(llvm::Module&) () at /usr/lib/llvm/11/lib64/libLLVM-11.so #13 0x00007fffcb275e45 in ac_compile_module_to_elf () at /usr/lib64/dri/radeonsi_dri.so #14 0x00007fffcb19d1c7 in si_compile_llvm () at /usr/lib64/dri/radeonsi_dri.so #15 0x00007fffcb19f5cc in si_llvm_compile_shader () at /usr/lib64/dri/radeonsi_dri.so #16 0x00007fffcb19bd30 in si_compile_shader () at /usr/lib64/dri/radeonsi_dri.so #17 0x00007fffcb201b12 in si_init_shader_selector_async () at /usr/lib64/dri/radeonsi_dri.so #18 0x00007fffca9d7e66 in util_queue_thread_func () at /usr/lib64/dri/radeonsi_dri.so #19 0x00007fffca9d782f in impl_thrd_routine () at /usr/lib64/dri/radeonsi_dri.so #20 0x00007ffff7f4ad0e in start_thread () at /lib64/libpthread.so.0 #21 0x00007fffefb6fc3f in clone () at /lib64/libc.so.6 Please bring back the 2.91 ebuild as fallback otherwise people are stuck since blender 2.9 blend files are incompatible with 2.8 (downgrade impossible).
I'm concerned about how LLVM 11 *and* 12 show up there...
This is now a new issue for the newer ebuild. The issue here is that you have probably built OSL and mesa with different llvm versions. So when blender tries to load OSL and use mesa to render graphics, it pulls in two different llvm versions. I don't know if there is any easy way to guard against this. To solve it you can simply make sure that mesa and the blender dependency libs are built with the same llvm version.
Miss typed. This is NOT a new issue for the newer ebuild.
How can I solve this issue? Or rather said, how is it possible to get such a situation to happen?
I did an "equery d llvm". media-gfx/blender does show up but not media-libs/osl . Is the osl ebuild defective?
(In reply to Plüss Roland from comment #5) > I did an "equery d llvm". media-gfx/blender does show up but not > media-libs/osl . Is the osl ebuild defective? My mistake. I looked wrongly. media-gfx/blender is also not listed. I'm confused where this comes from.
I've rebuild OSL. The same segfault happens so this does not seem to be the reason.
I've now also rebuild mesa. The segfault is the same. Any other ideas?
You are probably running mesa stable, right? (mesa < 21.1.1) Those versions are limited to llvm 11 and below.
I've also tried the AppImage version from blender.org (official LTS version). This one does not segfault. Both version thus run on the same MESA but show different results. I would conclude from this that MESA is not the problem here but something else.
The official LTS version is statically linked (so the OSL library is baked into the blender binary). This makes it so that only one shared llvm library is loaded (as then only mesa pulls in the shared llvm library on your system). I've ran into this issue myself and I am telling you how to fix it. If you are not willing to follow my suggestions, then there is not much to do here.
You said (and I quote): > To solve it you can simply make sure that mesa and the blender dependency > libs are built with the same llvm version. I rebuild blender, mesa and osl. So I followed your advice but it did not help. Any other ideas what I can try? Something I do miss here that is obvious to you but not me?
I explained that if you are using mesa < 21.1.1, then it will only build with llvm 11. If you have both llvm 11 and 12 installed on your system, then packages that supports a higher llvm version, will build with that (like osl). I'm guessing that you are using an older mesa version so no matter how many times you rebuild, it will always use llvm 11 as that is the maximum version those older versions support.
I'm using nothing special there, regular portage. emerge -pv shows media-libs/mesa-21.0.3::gentoo . https://packages.gentoo.org/packages/media-libs/mesa shows this is correct. 21.0.3 is supported. All above are testing. So you suggest I should unmask a testing Mesa for this? Is this safe?
Yes, just use the testing versions of mesa. You are already using the testing versions of blender and its libraries.
With unmasking media-libs/mesa-21.1.1 it works. Not sure if it is related to this workaround but use flags like "embree" are not working. Ebuild builds but embree backend is not available. Also I noticed this ebuild does no more install "blender" binary only "blendr-2.93" binary which breaks system shortcuts. Maybe this is supposed to be handled using "eselect" in the future?
I'm having essentially the same problem with blender 2.93.2-r1 and mesa 21.3.0_rc3. When Blender segfaults, it's with LLVM-13 and 12 instead of 12 and 11: I'm on all testing packages, though, and I've tried rebuilding packages with no luck. [Switching to Thread 0x7fffc847a640 (LWP 29364)] 0x00007fffe76f5f00 in llvm::MachinePointerInfo::getAddrSpace() const () from /usr/lib/llvm/12/lib64/libLLVM-12.so (gdb) bt #0 0x00007fffe76f5f00 in llvm::MachinePointerInfo::getAddrSpace() const () at /usr/lib/llvm/12/lib64/libLLVM-12.so #1 0x00007fffe7aed99f in () at /usr/lib/llvm/12/lib64/libLLVM-12.so #2 0x00007fffe7af244f in () at /usr/lib/llvm/12/lib64/libLLVM-12.so #3 0x00007fffca794048 in llvm::FoldingSetBase::GrowBucketCount(unsigned int, llvm::FoldingSetBase::FoldingSetInfo const&) () at /usr/lib/llvm/13/lib64/libLLVM-13.so #4 0x00007fffca793efd in llvm::FoldingSetBase::InsertNode(llvm::FoldingSetBase::Node*, void*, llvm::FoldingSetBase::FoldingSetInfo const&) () at /usr/lib/llvm/13/lib64/libLLVM-13.so #5 0x00007fffcb067a85 in llvm::SelectionDAG::getNode(unsigned int, llvm::SDLoc const&, llvm::EVT, llvm::SDValue, llvm::SDValue, llvm::SDValue, llvm::SDNodeFlags) () at /usr/lib/llvm/13/lib64/libLLVM-13.so #6 0x00007fffcafdd938 in llvm::RegsForValue::getCopyToRegs(llvm::SDValue, llvm::SelectionDAG&, llvm::SDLoc const&, llvm::SDValue&, llvm::SDValue*, llvm::Value const*, llvm::ISD::NodeType) const () at /usr/lib/llvm/13/lib64/libLLVM-13.so #7 0x00007fffcaffdcf6 in llvm::SelectionDAGBuilder::CopyValueToVirtualRegister(llvm::Value const*, unsigned int) () at /usr/lib/llvm/13/lib64/libLLVM-13.so #8 0x00007fffcb028bdb in llvm::SelectionDAGBuilder::visit(llvm::Instruction const&) () at /usr/lib/llvm/13/lib64/libLLVM-13.so #9 0x00007fffcb07e52e in llvm::SelectionDAGISel::SelectBasicBlock(llvm::ilist_iterator<llvm::ilist_detail::node_options<llvm::Instruction, false, false, void>, false, true>, llvm::ilist_iterator<llvm::ilist_detail::node_options<llvm::Instruction, false, false, void>, false, true>, bool&) () at /usr/lib/llvm/13/lib64/libLLVM-13.so #10 0x00007fffcb07fd64 in llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) () at /usr/lib/llvm/13/lib64/libLLVM-13.so #11 0x00007fffcb081cc2 in llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) () at /usr/lib/llvm/13/lib64/libLLVM-13.so #12 0x00007fffcabda570 in () at /usr/lib/llvm/13/lib64/libLLVM-13.so #13 0x00007fffca98b532 in llvm::FPPassManager::runOnFunction(llvm::Function&) () at /usr/lib/llvm/13/lib64/libLLVM-13.so #14 0x00007fffcbbdd99a in () at /usr/lib/llvm/13/lib64/libLLVM-13.so #15 0x00007fffca98bee3 in llvm::legacy::PassManagerImpl::run(llvm::Module&) () at /usr/lib/llvm/13/lib64/libLLVM-13.so #16 0x00007fffced83c56 in () at /usr/lib64/dri/radeonsi_dri.so #17 0x00007fffcece3d82 in () at /usr/lib64/dri/radeonsi_dri.so #18 0x00007fffcece618f in () at /usr/lib64/dri/radeonsi_dri.so #19 0x00007fffcece2743 in () at /usr/lib64/dri/radeonsi_dri.so #20 0x00007fffced06fb6 in () at /usr/lib64/dri/radeonsi_dri.so #21 0x00007fffce5060da in () at /usr/lib64/dri/radeonsi_dri.so #22 0x00007fffce505c67 in () at /usr/lib64/dri/radeonsi_dri.so #23 0x00007fffee0fb007 in () at /lib64/libc.so.6 #24 0x00007fffee17f2cc in () at /lib64/libc.so.6
The issue is that we can't mix LLVM version between libraries that are linked to blender. In this case it is OSL and Mesa that is using different LLVM versions and that is what is causing it to crash. I've filled out an request to handle this here: https://bugs.gentoo.org/821955 However it seems like the plan is to simply unslot llvm so issues like these simply doesn't happen (because there would only be one llvm version installed at a time). Until then, you have three options: 1. Use the official builds from the blender website 2. Build blender without OSL support (-osl useflag) 3. Make sure that Mesa and OSL is using the same llvm version. (The easiest way to do that is to mask and unmerge llvm 13 and rebuild mesa)
Ah, I'd seen some of that in the previous comments, but it was hard to pull the signal out of the noise. Thank you for laying the options out so clearly. I've disabled the osl use flag (as I have no need for it at the moment) and everything is working again. In the future, I might try to mask to a single LLVM version, but with more and more software these days depending on LLVM (and likely depending on different versions), that might be a difficulty, given how fast LLVM progresses. Thank you very much for your help.
I'm wondering if we should drop keywords on OSL 12. It's not had updates in a while, doesn't support LLVM 13 (while OSL 11 does!), and it's a dev version.
(In reply to Sam James from comment #20) > I'm wondering if we should drop keywords on OSL 12. It's not had updates in > a while, doesn't support LLVM 13 (while OSL 11 does!), and it's a dev > version. I guess we could mask or remove the OSL 12, yes. The official blender builds from the master branch uses OSL 1.11.14.1 currently. So us going back to OSL 11 shouldn't be any problem.
(In reply to Sebastian Parborg from comment #21) > (In reply to Sam James from comment #20) > > I'm wondering if we should drop keywords on OSL 12. It's not had updates in > > a while, doesn't support LLVM 13 (while OSL 11 does!), and it's a dev > > version. > > I guess we could mask or remove the OSL 12, yes. > > The official blender builds from the master branch uses OSL 1.11.14.1 > currently. > So us going back to OSL 11 shouldn't be any problem. Let's mask it for now. Thanks for the quick reply!
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=a68700df5aa5648ae9fa2ccab37fee9906fb1a89 commit a68700df5aa5648ae9fa2ccab37fee9906fb1a89 Author: Sam James <sam@gentoo.org> AuthorDate: 2021-12-01 16:28:57 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2021-12-01 16:28:57 +0000 profiles: mask OSL 12 Doesn't support LLVM 13 yet and it's a development release. OSL 11 is actually *newer* (getting more frequente releases). Bug: https://bugs.gentoo.org/797298 Signed-off-by: Sam James <sam@gentoo.org> profiles/package.mask | 6 ++++++ 1 file changed, 6 insertions(+)
(In reply to Sam James from comment #22) > Let's mask it for now. Thanks for the quick reply! Thanks for the proposal and the quick fix! ^^
The problem is back. After the latest world update blender 2.93 segfaults again: Thread 29 "blender-2.:sh1" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fff91e296c0 (LWP 6842)] 0x00007fffe51eae20 in llvm::MachinePointerInfo::getAddrSpace() const () from /usr/lib/llvm/14/lib64/libLLVM-14.so (gdb) bt #0 0x00007fffe51eae20 in llvm::MachinePointerInfo::getAddrSpace() const () at /usr/lib/llvm/14/lib64/libLLVM-14.so #1 0x00007fffe5639717 in AddNodeIDCustom(llvm::FoldingSetNodeID&, llvm::SDNode const*) () at /usr/lib/llvm/14/lib64/libLLVM-14.so #2 0x00007fffe5639a5c in llvm::FoldingSet<llvm::SDNode>::NodeEquals(llvm::FoldingSetBase const*, llvm::FoldingSetBase::Node*, llvm::FoldingSetNodeID const&, unsigned int, llvm::FoldingSetNodeID&) () at /usr/lib/llvm/14/lib64/libLLVM-14.so #3 0x00007fffb1a08034 in llvm::FoldingSetBase::FindNodeOrInsertPos(llvm::FoldingSetNodeID const&, void*&, llvm::FoldingSetBase::FoldingSetInfo const&) () at /usr/lib/llvm/15/lib64/libLLVM-15.so #4 0x00007fffb232b981 in llvm::SelectionDAG::FindNodeOrInsertPos(llvm::FoldingSetNodeID const&, llvm::SDLoc const&, void*&) () at /usr/lib/llvm/15/lib64/libLLVM-15.so #5 0x00007fffb234b001 in llvm::SelectionDAG::getNode(unsigned int, llvm::SDLoc const&, llvm::EVT) () at /usr/lib/llvm/15/lib64/libLLVM-15.so #6 0x00007fffb2162caf in llvm::SelectionDAG::getUNDEF(llvm::EVT) () at /usr/lib/llvm/15/lib64/libLLVM-15.so #7 0x00007fffb22f9c6e in llvm::SelectionDAGBuilder::getValueImpl(llvm::Value const*) () at /usr/lib/llvm/15/lib64/libLLVM-15.so #8 0x00007fffb22ff36e in llvm::SelectionDAGBuilder::getValue(llvm::Value const*) () at /usr/lib/llvm/15/lib64/libLLVM-15.so #9 0x00007fffb22fa21d in llvm::SelectionDAGBuilder::getValueImpl(llvm::Value const*) () at /usr/lib/llvm/15/lib64/libLLVM-15.so #10 0x00007fffb22ff36e in llvm::SelectionDAGBuilder::getValue(llvm::Value const*) () at /usr/lib/llvm/15/lib64/libLLVM-15.so #11 0x00007fffb23139dc in llvm::SelectionDAGBuilder::visitInsertElement(llvm::User const&) () at /usr/lib/llvm/15/lib64/libLLVM-15.so #12 0x00007fffb23269ba in llvm::SelectionDAGBuilder::visit(llvm::Instruction const&) () at /usr/lib/llvm/15/lib64/libLLVM-15.so #13 0x00007fffb2389996 in llvm::SelectionDAGISel::SelectBasicBlock(llvm::ilist_iterator<llvm::ilist_detail::node_options<llvm::Instruction, false, false, void>, false, true>, llvm::ilist_iterator<llvm::ilist_detail::node_options<llvm::Instruction, false, false, void>, false, true>, bool&) () at /usr/lib/llvm/15/lib64/libLLVM-15.so #14 0x00007fffb238b3dd in llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) () at /usr/lib/llvm/15/lib64/libLLVM-15.so #15 0x00007fffb238ce82 in llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) () at /usr/lib/llvm/15/lib64/libLLVM-15.so #16 0x00007fffb1e8dde2 in llvm::MachineFunctionPass::runOnFunction(llvm::Function&) () at /usr/lib/llvm/15/lib64/libLLVM-15.so #17 0x00007fffb1c21376 in llvm::FPPassManager::runOnFunction(llvm::Function&) () at /usr/lib/llvm/15/lib64/libLLVM-15.so #18 0x00007fffb2fbf50f in (anonymous namespace)::CGPassManager::runOnModule(llvm::Module&) () at /usr/lib/llvm/15/lib64/libLLVM-15.so #19 0x00007fffb1c21c14 in llvm::legacy::PassManagerImpl::run(llvm::Module&) () at /usr/lib/llvm/15/lib64/libLLVM-15.so #20 0x00007fffbf6f1b15 in ac_compile_module_to_elf () at /usr/lib64/dri/radeonsi_dri.so #21 0x00007fffbf641879 in si_compile_llvm () at /usr/lib64/dri/radeonsi_dri.so #22 0x00007fffbf644230 in si_llvm_compile_shader () at /usr/lib64/dri/radeonsi_dri.so #23 0x00007fffbf63e36e in si_compile_shader () at /usr/lib64/dri/radeonsi_dri.so #24 0x00007fffbf66539c in si_init_shader_selector_async(void*, void*, int) () at /usr/lib64/dri/radeonsi_dri.so #25 0x00007fffbee9e6cb in util_queue_thread_func () at /usr/lib64/dri/radeonsi_dri.so #26 0x00007fffbeee673f in impl_thrd_routine () at /usr/lib64/dri/radeonsi_dri.so #27 0x00007fffee3d6e8a in start_thread () at /lib64/libc.so.6 #28 0x00007fffee4569cc in clone3 () at /lib64/libc.so.6
(In reply to Plüss Roland from comment #25) > The problem is back. After the latest world update blender 2.93 segfaults > again: > > Thread 29 "blender-2.:sh1" received signal SIGSEGV, Segmentation fault. > [Switching to Thread 0x7fff91e296c0 (LWP 6842)] > 0x00007fffe51eae20 in llvm::MachinePointerInfo::getAddrSpace() const () from > /usr/lib/llvm/14/lib64/libLLVM-14.so > (gdb) bt > #0 0x00007fffe51eae20 in llvm::MachinePointerInfo::getAddrSpace() const () > at /usr/lib/llvm/14/lib64/libLLVM-14.so > #1 0x00007fffe5639717 in AddNodeIDCustom(llvm::FoldingSetNodeID&, > llvm::SDNode const*) () at /usr/lib/llvm/14/lib64/libLLVM-14.so > #2 0x00007fffe5639a5c in > llvm::FoldingSet<llvm::SDNode>::NodeEquals(llvm::FoldingSetBase const*, > llvm::FoldingSetBase::Node*, llvm::FoldingSetNodeID const&, unsigned int, > llvm::FoldingSetNodeID&) () at /usr/lib/llvm/14/lib64/libLLVM-14.so > #3 0x00007fffb1a08034 in > llvm::FoldingSetBase::FindNodeOrInsertPos(llvm::FoldingSetNodeID const&, > void*&, llvm::FoldingSetBase::FoldingSetInfo const&) () > at /usr/lib/llvm/15/lib64/libLLVM-15.so > #4 0x00007fffb232b981 in > llvm::SelectionDAG::FindNodeOrInsertPos(llvm::FoldingSetNodeID const&, > llvm::SDLoc const&, void*&) () > at /usr/lib/llvm/15/lib64/libLLVM-15.so > #5 0x00007fffb234b001 in llvm::SelectionDAG::getNode(unsigned int, > llvm::SDLoc const&, llvm::EVT) () at /usr/lib/llvm/15/lib64/libLLVM-15.so > #6 0x00007fffb2162caf in llvm::SelectionDAG::getUNDEF(llvm::EVT) () at > /usr/lib/llvm/15/lib64/libLLVM-15.so > #7 0x00007fffb22f9c6e in > llvm::SelectionDAGBuilder::getValueImpl(llvm::Value const*) () at > /usr/lib/llvm/15/lib64/libLLVM-15.so > #8 0x00007fffb22ff36e in llvm::SelectionDAGBuilder::getValue(llvm::Value > const*) () at /usr/lib/llvm/15/lib64/libLLVM-15.so > #9 0x00007fffb22fa21d in > llvm::SelectionDAGBuilder::getValueImpl(llvm::Value const*) () at > /usr/lib/llvm/15/lib64/libLLVM-15.so > #10 0x00007fffb22ff36e in llvm::SelectionDAGBuilder::getValue(llvm::Value > const*) () at /usr/lib/llvm/15/lib64/libLLVM-15.so > #11 0x00007fffb23139dc in > llvm::SelectionDAGBuilder::visitInsertElement(llvm::User const&) () at > /usr/lib/llvm/15/lib64/libLLVM-15.so > #12 0x00007fffb23269ba in llvm::SelectionDAGBuilder::visit(llvm::Instruction > const&) () at /usr/lib/llvm/15/lib64/libLLVM-15.so > #13 0x00007fffb2389996 in > llvm::SelectionDAGISel::SelectBasicBlock(llvm::ilist_iterator<llvm:: > ilist_detail::node_options<llvm::Instruction, false, false, void>, false, > true>, > llvm::ilist_iterator<llvm::ilist_detail::node_options<llvm::Instruction, > false, false, void>, false, true>, bool&) () at > /usr/lib/llvm/15/lib64/libLLVM-15.so > #14 0x00007fffb238b3dd in > llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) () at > /usr/lib/llvm/15/lib64/libLLVM-15.so > #15 0x00007fffb238ce82 in > llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) () at > /usr/lib/llvm/15/lib64/libLLVM-15.so > #16 0x00007fffb1e8dde2 in > llvm::MachineFunctionPass::runOnFunction(llvm::Function&) () at > /usr/lib/llvm/15/lib64/libLLVM-15.so > #17 0x00007fffb1c21376 in > llvm::FPPassManager::runOnFunction(llvm::Function&) () at > /usr/lib/llvm/15/lib64/libLLVM-15.so > #18 0x00007fffb2fbf50f in (anonymous > namespace)::CGPassManager::runOnModule(llvm::Module&) () at > /usr/lib/llvm/15/lib64/libLLVM-15.so > #19 0x00007fffb1c21c14 in llvm::legacy::PassManagerImpl::run(llvm::Module&) > () at /usr/lib/llvm/15/lib64/libLLVM-15.so > #20 0x00007fffbf6f1b15 in ac_compile_module_to_elf () at > /usr/lib64/dri/radeonsi_dri.so > #21 0x00007fffbf641879 in si_compile_llvm () at > /usr/lib64/dri/radeonsi_dri.so > #22 0x00007fffbf644230 in si_llvm_compile_shader () at > /usr/lib64/dri/radeonsi_dri.so > #23 0x00007fffbf63e36e in si_compile_shader () at > /usr/lib64/dri/radeonsi_dri.so > #24 0x00007fffbf66539c in si_init_shader_selector_async(void*, void*, int) > () at /usr/lib64/dri/radeonsi_dri.so > #25 0x00007fffbee9e6cb in util_queue_thread_func () at > /usr/lib64/dri/radeonsi_dri.so > #26 0x00007fffbeee673f in impl_thrd_routine () at > /usr/lib64/dri/radeonsi_dri.so > #27 0x00007fffee3d6e8a in start_thread () at /lib64/libc.so.6 > #28 0x00007fffee4569cc in clone3 () at /lib64/libc.so.6 Please run lldtree on /usr/bin/blender-2.93.
I don't have the program lldtree. Which ebuild contains it?
sorry, lddtree! (pax-utils)
I see... you mean "lddtree". Here it is: https://pastebin.com/ermpMrrZ
Looking at the output of lddtree I noticed libosl pulls in llvm:14 . This seems to be an ebuild bug since media-libs/osl and llvm are both the latest stable builds and llvm is 15 while osl forces llvm 14. This seems to cause the crash of blender. I worked around the problem now by emerging blender with USE=-osl . Although this works the real solution has to be fixing osl to not require llvm:14 while llvm itself updates to 15.
(In reply to Plüss Roland from comment #30) > Looking at the output of lddtree I noticed libosl pulls in llvm:14 . This > seems to be an ebuild bug since media-libs/osl and llvm are both the latest > stable builds and llvm is 15 while osl forces llvm 14. This seems to cause > the crash of blender. > > I worked around the problem now by emerging blender with USE=-osl . Although > this works the real solution has to be fixing osl to not require llvm:14 > while llvm itself updates to 15. I've filed a stable bug for osl. Solving the dependencies however is far harder (see bug 821955).
I think we should close this in favor of https://bugs.gentoo.org/880671 as that one is more to the point than this ticket.
