Blender fails to launch after upgrade/update

I just updated Blender to the latest (2.82.a-6) in the repos, and it now fails to launch with:
Illegal instruction (core dumped)

This was done along with a large number of other updates via command line.

I reverted to the previous version (2.82.a-3, which was working fine a few hours ago) and it too will not launch now.

I've removed the package from /var/cache/pacman/pkg and re-installed, but it made no difference.

Just say so if any more info is needed.

1 Like



And then

coredump gdb #####

Where ##### is the process id of the crashed blender.

1 Like

I don't seem to have coredump, but do have coredumpctl. This is what the last PID shows with coredumpdctl info and the PID.
PID: 5189 (blender)
UID: 1000 (kevin)
GID: 1000 (kevin)
Signal: 4 (ILL)
Timestamp: Sun 2020-05-31 15:29:58 EDT (3h 26min ago)
Command Line: blender
Executable: /usr/bin/blender
Control Group: /user.slice/user-1000.slice/session-2.scope
Unit: session-2.scope
Slice: user-1000.slice
Session: 2
Owner UID: 1000 (kevin)
Boot ID: 1354d0409cee48068e4d7b4851a6798a
Machine ID: 9a7db3d6c3784654ba2df9e5eb8af441
Hostname: RenderBox
Storage: /var/lib/systemd/coredump/core.blender.1000.1354d0409cee48068e4d7b4851a6798a.5189.1590953398000000000000.lz4
Message: Process 5189 (blender) of user 1000 dumped core.

            Stack trace of thread 5189:
            #0  0x00007fcd8ff9891d n/a ( + 0x4691d)
            #1  0x00007fcd94a100f2 call_init.part.0 ( + 0x110f2)
            #2  0x00007fcd94a10201 _dl_init ( + 0x11201)
            #3  0x00007fcd94a0113a _dl_start_user ( + 0x213a)

Having the same issue. Blender was working perfectly yesterday and last night I updated with pacman -Syu everything seemed to update fine. Rebooted ok but this morning was unable to start blender. Coredump below.

$ blender
Illegal instruction (core dumped)

I've tried the following commands but get the same output.

$ blender --log-level -1
$ blender-softwaregl
$ blender --factory-startup
$ blender-softwaregl --factory-startup

Weirdly, just checking blender version gets the same ouput.

$ blender --version
Illegal instruction (core dumped)

Additionally, does anyone know how to install Blender debugging symbols and use gdb? This might be needed for a thorough stacktrace. I'm pretty new to debugging.

AMD RX 470 related installs through yay etc:

amd-ucode            20200519.r1641.8ba6fa6-1
amdgpu-core-meta         19.30_934563-1 (Radeon_Software_for_Linux)
amdgpu-pro-core-meta     19.30_934563-1 (Radeon_Software_for_Linux)
amdgpu-pro-libgl         19.30_934563-1 (Radeon_Software_for_Linux)
lib32-amdgpu-pro-libgl   19.30_934563-1 (Radeon_Software_for_Linux)
mhwd-amdgpu         19.1.0-1
xf86-video-amdgpu   19.1.0-2 (xorg-drivers)
opencl-amd    20.10.1048554-1
$ sudo coredumpctl gdb 18439
           PID: 18439 (blender)
           UID: 1000 (mooselimb)
           GID: 1001 (mooselimb)
        Signal: 4 (ILL)
     Timestamp: Mon 2020-06-01 08:10:46 BST (1h 44min ago)
  Command Line: blender -v
    Executable: /usr/bin/blender
 Control Group: /user.slice/user-1000.slice/session-1.scope
          Unit: session-1.scope
         Slice: user-1000.slice
       Session: 1
     Owner UID: 1000 (mooselimb)
       Boot ID: 08ca327ce523429fb2898b042c4e9cdf
    Machine ID: 808d7ddcc5d14acd9e03d05a109e9ea1
      Hostname: mooselimb-kcma-d8
       Storage: /var/lib/systemd/coredump/core.blender.1000.08ca327ce523429fb2898b042c4e9cdf.18439.1590995446000000000000.lz4
       Message: Process 18439 (blender) of user 1000 dumped core.
                Stack trace of thread 18439:
                #0  0x00007f3c5ac5791d n/a ( + 0x4691d)
                #1  0x00007f3c5f6b70f2 call_init.part.0 ( + 0x110f2)
                #2  0x00007f3c5f6b7201 _dl_init ( + 0x11201)
                #3  0x00007f3c5f6a813a _dl_start_user ( + 0x213a)

GNU gdb (GDB) 9.2
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
Find the GDB manual and other documentation resources online at:

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/bin/blender...
(No debugging symbols found in /usr/bin/blender)
[New LWP 18439]
[New LWP 18440]
[New LWP 18442]
[New LWP 18443]
[New LWP 18441]
[New LWP 18444]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/".
Core was generated by `blender -v'.
Program terminated with signal SIGILL, Illegal instruction.
#0  0x00007f3c5ac5791d in ?? () from /usr/lib/
[Current thread is 1 (Thread 0x7f3c4afdd680 (LWP 18439))]
(gdb) bt
#0  0x00007f3c5ac5791d in ?? () from /usr/lib/
#1  0x00007f3c5f6b70f2 in call_init.part () from /lib64/
#2  0x00007f3c5f6b7201 in _dl_init () from /lib64/
#3  0x00007f3c5f6a813a in _dl_start_user () from /lib64/
#4  0x0000000000000002 in ?? ()
#5  0x00007ffcc3f17379 in ?? ()
#6  0x00007ffcc3f17381 in ?? ()
#7  0x0000000000000000 in ?? ()

Any ideas what the problem could be? All help appreciated.

Another thing I've noticed since the update is that pamac is no longer setting a notification in the tray for available AUR package updates. I don't know if that applies to repo updates or not yet, as there don't seem to be any at the moment. But, something in this last major update seems to have gone awry.

I tried to downgrade conky, making sure to avoid it in IgnorePkg. Did a pacman -Syy but nothing appeared in pamac. Even though pacman found the upgrade correctly.

I don't normally use pamac so ymmv.

Ok, Think I've isolated it.
Relevant point in gdb trace

#0  0x00007f64c45c991d in ?? () from /usr/lib/

Which is owned by openimagedenoise, Intel's new denoiser.

Now, I know for sure that my Opteron 4148s don't support it. I checked ages ago, think it was due to missing SSE4.1.

Blender didn't have openimagedenoise as a dependency before but now it does.
So openimagedenoise is trying to use instructions from SSE4.1. Hence "Illegal Instruction".
see SSE4.1 causes crashes on older CPU

@Pikachu, Your Phenom II X4 960T has up to SSE4a. But this is AMD's weird naming scheme and isn't the same as SSE4.x.

Does Blender need openimagedenoise as a dependency? Can't we move it optional depends?


Workaround found!
Looks like I was correct! SSE4.1 instruction set is being forced accidentally from the updated openimagedenoise 1.2.0.

Turns out openimagedenoise 1.1.0 was installed previously.

Downgrading to openimagedenoise 1.1.0 works for me. Without a reboot as well! Be sure to add it to IgnorePkgs.

To Downgrade follow the instruction on the wiki

I installed downgrade and used that. Simplez.

For completeness here's the Arch Bug and they've reported upstream. They're considering a split package but in the meantime downgrading openimagedenoise seems to work.
FS#66779 - [blender] 17:2.82.a-6 fails to open with openimagedenoise 1.2.0

And here's the openimagedenoise bug
SSE4.1 causes crashes on older CPU


That worked for me! I had a feeling it was something to do with openimagedenoise, but I couldn't put my finger on it.

And yeah, I know this is an old processor, but it runs well enough that I haven't been able to convince myself to drop the cash on a new motherboard and processor. As much as I'd love to have a monster setup with a couple of 2080 Ti cards, I can't break through my own cheapness barrier to do it, lol.

1 Like

Glad it worked!
Ha ha, my cpu is older than yours even. I'd love a monster rig too but alas, I'm too flipping poor. We can but dream. I couldn't even finish the new Dohnut lessons lol. The Glass material caused crashes.

I'm thinking of getting good enough at blender to sell some models on blender market. Who knows, I may make my fortune there. At least I'll enjoy doing it, even if I stay poor.

Oh, and don't forget to mark this as solved for others who are searching. Keep blendering.

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.

Forum kindly sponsored by