I originally opened this bug on the Redhat bugzilla, but I was instructed to take this upstream. Just so everyone's on the same page, I'm going to copy-paste the report from RH.
User-Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:41.0) Gecko/20100101 Firefox/41.0
Apologies if I've mischaracterised anything above, I'm going off of my uninformed analysis of the attached backtrace from GDB.
Attempting to use Blender in any meaningful way results in the UI hanging. strace clued me into the blocking futex call and gdb seems to point the finger at libOpenCL.so.
Oddly enough, clinfo works as it should
Steps to Reproduce:
1. Open Blender
2. Open system tab of preferences panel, switch to the Cycles renderer etc
UI freeze, application hang
Application doesn't hang
rpm -q fedora-release
rpm -q blender
rpm -q ocl-icd
Created attachment 121583 [details]
Blender GDB backtrace
Fabian Deutsch <email@example.com>
The backtrace shows that clover is used.
Component: ocl-icd → mesa
I've tried with a variety of different configurations to check whether this bug might be setup-specific. I normally use two GPUs from mixed vendors, but I tried using a single GTX570, HD6870, HD6950, 9800GT and just the plain Intel HD4000 but still this bug persists
Fabian Deutsch <firstname.lastname@example.org>
I strongly suspect that it's an issue if clover/mesa's opencl tracker, please file a bug in upstream or retry with the latest release from rawhide.
Status: NEW → CLOSED
Can you also provide backtraces for any concurrently running threads? I suspect that reverting commit d5b1731178378b3d828c74368f6bfe85edc10618 may fix the deadlock, any chance you could try?
In the specific case of blender, there are 31 hung up threads with around 9 each waiting on
__lll_lock_wait () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135
pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
do_futex_wait () at ../sysdeps/unix/sysv/linux/futex-internal.h:205
The remaining threads are waiting on poll () at ../sysdeps/unix/syscall-template.S:84 with the last being the one I provided a backtrace for. Is there any one you're interested in particular? After sampling some of the backtraces they seem to be unrelated, either blender-specific or just mainloops for udev and pulseaudio waiting for events, but if please let me know if there's any backtraces you'd like
(In reply to bob from comment #7)
> In the specific case of blender, there are 31 hung up threads with around 9
> each waiting on
> __lll_lock_wait () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135
> pthread_cond_wait@@GLIBC_2.3.2 () at
> do_futex_wait () at ../sysdeps/unix/sysv/linux/futex-internal.h:205
> The remaining threads are waiting on poll () at
> ../sysdeps/unix/syscall-template.S:84 with the last being the one I provided
> a backtrace for. Is there any one you're interested in particular? After
> sampling some of the backtraces they seem to be unrelated, either
> blender-specific or just mainloops for udev and pulseaudio waiting for
> events, but if please let me know if there's any backtraces you'd like
Is there any other hung thread showing mesa function calls in the stack trace? That would be particularly interesting. In any case the more backtraces you can provide the better :)
Created attachment 121851 [details]
Complete Blender backtraces
Sorry, I completely forgot you asked for those. Enjoy ;)
Created attachment 121852 [details]
Complete Blender backtraces with ocl-icd debuginfos
Thanks. Could you check if this workaround from an earlier bug report helps?
I wasn't successful in getting mesa to compile with `--enable-opencl`, but something odd has happened today: I had to reinstall Fedora because gdm exploded, and now no such lockup occurs.
➜ ~ rpm -q mesa-libOpenCL
Closing per comment #13.