Blackmagic Forum

It looks like some part of Resolve requires the tbb project, and now it seems to be renamed to onetbb and some api changed:

https://github.com/oneapi-src/oneTBB
https://oneapi-src.github.io/oneTBB/mai ... Guide.html

And after upgrading my Arch Linux (tbb -> onetbb), if I start Resolve Studio, I got the following output, then Resolve just exits:

Code: Select all

ActCCMessage Already in Table: Code= c005, Mode= 13, Level=  1, CmdKey= -1, Option= 0
ActCCMessage Already in Table: Code= c006, Mode= 13, Level=  1, CmdKey= -1, Option= 0
ActCCMessage Already in Table: Code= c007, Mode= 13, Level=  1, CmdKey= -1, Option= 0
ActCCMessage Already in Table: Code= 2282, Mode=  0, Level=  0, CmdKey= 8, Option= 0
PnlMsgActionStringAdapter Already in Table: Code= 615e, Mode=  0, Level=  0, CmdKey= -1, Option= 0
log4cxx: No appender could be found for logger (BtCommon).
log4cxx: Please initialize the log4cxx system properly.


So if some library using by Resolve requires tbb, please consider upgrade it to fix this problem. Installing the old tbb on system could be a workaround, but there are many projects using the new onetbb so it is not an actuall solution.

There's nothing in that exit text you posted that indicates the issue is tbb related.

How did you determine that was the issue?

Dwaine Maggart wrote:There's nothing in that exit text you posted that indicates the issue is tbb related.

How did you determine that was the issue?

It's simple: Remove blender, then replace package onetbb with tbb2020 from AUR (which should be the old tbb), Resolve starts and shows its GUI. So the difference is tbb2020 and onetbb

I paste the output because Resolve only gives me such output and then quit, it may or may not be helpful, but I just paste all info I could gather here.

If Resolve starts fine, I have the following output, so it looks like it cannot start thread (which sounds related to tbb (threading building blocks):

Code: Select all

% /opt/resolve/bin/resolve
ActCCMessage Already in Table: Code= c005, Mode= 13, Level=  1, CmdKey= -1, Option= 0
ActCCMessage Already in Table: Code= c006, Mode= 13, Level=  1, CmdKey= -1, Option= 0
ActCCMessage Already in Table: Code= c007, Mode= 13, Level=  1, CmdKey= -1, Option= 0
ActCCMessage Already in Table: Code= 2282, Mode=  0, Level=  0, CmdKey= 8, Option= 0
PnlMsgActionStringAdapter Already in Table: Code= 615e, Mode=  0, Level=  0, CmdKey= -1, Option= 0
log4cxx: No appender could be found for logger (BtCommon).
log4cxx: Please initialize the log4cxx system properly.
18.1.4.0009 Linux/Clang x86_64
Main thread starts: 4BEA86C0
[0x7fec4bea86c0] | Undefined            | INFO  | 2023-03-23 08:44:10,294 | --------------------------------------------------------------------------------
[0x7fec4bea86c0] | Undefined            | INFO  | 2023-03-23 08:44:10,294 | Loaded log config from /home/alynx/.local/share/DaVinciResolve/configs/log-conf.xml
[0x7fec4bea86c0] | Undefined            | INFO  | 2023-03-23 08:44:10,294 | --------------------------------------------------------------------------------
Resolve communication is open and waiting..
Accepted new client


I can positively confirm this is related to the newer tbb/oneapi libraries. When I try to launch resolve, it hangs at this point:

Code: Select all

[0x7ff0e180e6c0] | Main                 | INFO  | 2023-03-23 10:20:10,706 | Running DaVinci Resolve Studio v18.1.3.0008 (Linux/Clang x86_64)
[0x7ff0e180e6c0] | Main                 | INFO  | 2023-03-23 10:20:10,706 | BMD_BUILD_UUID f844f74a-4673-4b5d-ab39-4a0041796dbe
[0x7ff0e180e6c0] | Main                 | INFO  | 2023-03-23 10:20:10,706 | BMD_GIT_COMMIT a312479fae641d54896fa6c21b341a3dedf446b5
[0x7ff0e180e6c0] | GPUDetect            | INFO  | 2023-03-23 10:20:10,706 | Starting GPUDetect 1.2_3-a1


If I attach to the resolve process with GDB and do a backtrace, I see this:

Code: Select all

#0  0x00007ff3d3aa3ab1 in ?? () from /usr/lib/libc.so.6
#1  0x00007ff3d284f4a3 in clGetExtensionFunctionAddress () from /opt/intel/oneapi/compiler/2023.0.0/linux/lib/libOpenCL.so
#2  0x00007ff3d284e6e7 in ?? () from /opt/intel/oneapi/compiler/2023.0.0/linux/lib/libOpenCL.so
#3  0x00007ff3d2852bd9 in ?? () from /opt/intel/oneapi/compiler/2023.0.0/linux/lib/libOpenCL.so
#4  0x00007ff3d3aa3b17 in ?? () from /usr/lib/libc.so.6
#5  0x00007ff3d284f4a3 in clGetExtensionFunctionAddress () from /opt/intel/oneapi/compiler/2023.0.0/linux/lib/libOpenCL.so
#6  0x00007ff3d1a02fc4 in ?? () from /opt/cuda/lib64/libOpenCL.so.1
#7  0x00007ff3d3aa3b17 in ?? () from /usr/lib/libc.so.6
#8  0x00007ff3d1a048df in clGetPlatformIDs () from /opt/cuda/lib64/libOpenCL.so.1
#9  0x00007ff3df99c627 in ?? () from /opt/resolve/bin/../libs/libgpudetect.so
#10 0x00007ff3df99161f in ?? () from /opt/resolve/bin/../libs/libgpudetect.so
#11 0x00007ff3df9a5094 in ?? () from /opt/resolve/bin/../libs/libgpudetect.so
#12 0x00007ff3df943afd in ?? () from /opt/resolve/bin/../libs/libgpudetect.so
#13 0x00007ff3df9435c4 in ?? () from /opt/resolve/bin/../libs/libgpudetect.so
#14 0x0000000002396e68 in ?? ()
#15 0x0000000002391c3d in ?? ()
#16 0x00007ff3d3a3c790 in ?? () from /usr/lib/libc.so.6
#17 0x00007ff3d3a3c84a in __libc_start_main () from /usr/lib/libc.so.6
#18 0x00000000023909cb in ?? ()


If I force uninstall everything related to tbb/oneapi and install the old tbb2020, in resolve works fine.

I am using an RTX 3070 GPU - in case that is relevant information.

Upon further investigation, it seems that resolve (libgpudetect.so) is loading /opt/intel/oneapi/compiler/2023.0.0/linux/lib/libOpenCL.so and hanging. If I (temporarily) remove that, Resolve can start up properly.

I also tried removing that path from ld.so as follows:
- remove intel-oneapi-* from /etc/ld.so.conf.d
- run ldconfig
- confirm it's no longer in the cache by checking "ldconfig -p" output

Even having remove it from the LD cache, Resolve still tries to load it. I'm not sure why Resolve is doing that, since LD isn't even aware that file exists anymore. Perhaps some custom search behavior coded into libgpudetect.so? Is there some way to prevent Resolve from trying to load it?

Darrell Enns wrote:Upon further investigation, it seems that resolve (libgpudetect.so) is loading /opt/intel/oneapi/compiler/2023.0.0/linux/lib/libOpenCL.so and hanging. If I (temporarily) remove that, Resolve can start up properly.

I also tried removing that path from ld.so as follows:
- remove intel-oneapi-* from /etc/ld.so.conf.d
- run ldconfig
- confirm it's no longer in the cache by checking "ldconfig -p" output

Even having remove it from the LD cache, Resolve still tries to load it. I'm not sure why Resolve is doing that, since LD isn't even aware that file exists anymore. Perhaps some custom search behavior coded into libgpudetect.so? Is there some way to prevent Resolve from trying to load it?

Well, I don't have those intel opencl libs, if you also have blender, it might because some package split and you have a not used intel opencl implement, you could uninstall all such one api packages together blender, and install blender again. However, that should not related to Resolve, as you can see my output even not enter loading opencl steps.

I had the same issue with resolve on linux. I removed the intel-oneapi-tbb package and that fixed the problem, however I cannot use any other package that requires intel-oneapi-tbb as a dependency because it breaks resolve.

Can someone from Blackmagic explain why libgpudetect tries to load /opt/intel/oneapi/compiler/2023.0.0/linux/lib/libOpenCL.so? Is there some custom opencl library search behaviour built in to libgpudetect? Is there a way to prevent it from trying to load opencl from that location? Or can libgpudetect please be fixed to not crash/hang when it finds an incompatible opencl?

Any updates here? I just did a system upgrading and it seems onetbb is depended by other package besides blender (which means I cannot simply remove it and use tbb2020), so the problem needs to be solved on Resolve side.

I bring some good news, my resolve now works fine with onetbb, I don't know why, but I guess it is related to some package splitting. People who still fails on loading Intel's OpenCL may should try to remove all intel-one-api related package and re-install package depending on it.

People who still fails on loading Intel's OpenCL may should try to remove all intel-one-api related package and re-install package depending on it.

That workaround is not always viable. The problem is that Resolve (libgpudetect) hangs while trying to load /opt/intel/oneapi/compiler/2023.0.0/linux/lib/libOpenCL.so. This library is part of intel-oneapi-compiler-shared-opencl-cpu. If you don't have anything that requires this, removing it is an option. However, other packages may require it. One example of a package that requires it is PyTorch.

I think we need Blackmagic to address the behavior of libgpudetect. It's not clear why it tries to load that particular library, or if there's a way to prevent it from doing so. Libgpudetect does not seem to be following the standard LD library loading behaviour. I'm guessing it has some custom library search logic in it.

Today my Resolve got crash soon after opening a project for some minutes, I tried gdb and get the following backtrace:

Code: Select all

Thread 71 "GUI Thread" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fff44f796c0 (LWP 17533)]
0x00007fffed8adc5e in __GI___libc_free (mem=0x100000001) at malloc.c:3344
Downloading source file /usr/src/debug/glibc/glibc/malloc/malloc.c
3344      if (chunk_is_mmapped (p))                       /* release mmapped memory. */                                                                                                                                                                       
(gdb) bt
#0  0x00007fffed8adc5e in __GI___libc_free (mem=0x100000001) at malloc.c:3344
#1  0x00007ffff400113e in free (object=0x100000001) at ../../src/tbbmalloc/proxy.cpp:125
#2  0x00000000093253ef in ?? ()
#3  0x0000000009324b79 in ?? ()
#4  0x0000000009324fae in ?? ()
#5  0x00000000093239e9 in ?? ()
#6  0x00000000023c08c3 in ?? ()
#7  0x00000000023c0b0a in ?? ()
#8  0x00000000023f19d8 in ?? ()
#9  0x00000000023f18d7 in ?? ()
#10 0x0000000004609c7e in ?? ()
#11 0x00007fffed89d44b in start_thread (arg=<optimized out>) at pthread_create.c:444
#12 0x00007fffed920e40 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81


Looks like it is related to onetbb, I think blackmagic should do something about it?

AlynxZhou wrote:Today my Resolve got crash soon after opening a project for some minutes, I tried gdb and get the following backtrace:

Code: Select all

Thread 71 "GUI Thread" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fff44f796c0 (LWP 17533)]
0x00007fffed8adc5e in __GI___libc_free (mem=0x100000001) at malloc.c:3344
Downloading source file /usr/src/debug/glibc/glibc/malloc/malloc.c
3344      if (chunk_is_mmapped (p))                       /* release mmapped memory. */                                                                                                                                                                       
(gdb) bt
#0  0x00007fffed8adc5e in __GI___libc_free (mem=0x100000001) at malloc.c:3344
#1  0x00007ffff400113e in free (object=0x100000001) at ../../src/tbbmalloc/proxy.cpp:125
#2  0x00000000093253ef in ?? ()
#3  0x0000000009324b79 in ?? ()
#4  0x0000000009324fae in ?? ()
#5  0x00000000093239e9 in ?? ()
#6  0x00000000023c08c3 in ?? ()
#7  0x00000000023c0b0a in ?? ()
#8  0x00000000023f19d8 in ?? ()
#9  0x00000000023f18d7 in ?? ()
#10 0x0000000004609c7e in ?? ()
#11 0x00007fffed89d44b in start_thread (arg=<optimized out>) at pthread_create.c:444
#12 0x00007fffed920e40 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81


Looks like it is related to onetbb, I think blackmagic should do something about it?

Well, I uninstalled onetbb and installed tbb2020, it still crashes, so maybe that is not the reason...

IS there any update on this error that has been causing me to no longer be able to use DR Studio?
Some Blackmagic feedback for a fix would be really appreciated

Code: Select all

ActCCMessage Already in Table: Code= c005, Mode= 13, Level=  1, CmdKey= -1, Option= 0
ActCCMessage Already in Table: Code= c006, Mode= 13, Level=  1, CmdKey= -1, Option= 0
ActCCMessage Already in Table: Code= c007, Mode= 13, Level=  1, CmdKey= -1, Option= 0
ActCCMessage Already in Table: Code= 2282, Mode=  0, Level=  0, CmdKey= 8, Option= 0
PnlMsgActionStringAdapter Already in Table: Code= 615e, Mode=  0, Level=  0, CmdKey= -1, Option= 0
18.6.4.0006 Linux/Clang x86_64
Main thread starts: F9230100
log4cxx: setFile(./logs/rollinglog.txt,true) call failed.
log4cxx: IO Exception : status code = 30
0x7f52f9230100 | Undefined            | INFO  | 2024-02-19 14:18:30,050 | --------------------------------------------------------------------------------
log4cxx: No output stream or file set for the appender named [RollLogAppender].
0x7f52f9230100 | Undefined            | INFO  | 2024-02-19 14:18:30,050 | Loaded log config from /home/martin/.local/share/DaVinciResolve/configs/log-conf.xml
0x7f52f9230100 | Undefined            | INFO  | 2024-02-19 14:18:30,051 | --------------------------------------------------------------------------------

What Linux distro are you using?

Please provide a Resolve diagnostics log, which you can generate using the DaVinci Resolve Capture Logs app (has a gear icon).

Hi and thanks for your reply.
I'm using nixos distro.

I've attached some log files that hopefully will help (sorry but I can't find a the DaVinci Resolve Capture Logs app at this time). This hardware was used on macOS hackintosh a few weeks ago so trying to understand why DR isn't working.
This machine has bith an Intel iGPU and a Radeon 580, just an FYI

Dwaine Maggart wrote:What Linux distro are you using?

Please provide a Resolve diagnostics log, which you can generate using the DaVinci Resolve Capture Logs app (has a gear icon).

Not nearly as helpful as an actual Resolve diagnostics log.

But it does show Resolve does not detect any GPU. Which would not be surprising for an AMD GPU in Linux. That will require installing an actual AMD Linux GPU driver. Whether that's possible on your distro, I have no idea. Perhaps someone else using that distro will comment.

Just getting back to this now.
My issue was some conflict with ROCM v6 and my RX580. I changed anything rocm related to version 5.x and I now have Davinci Resolve rocking again.
So so happy

aussiemartin wrote:Hi and thanks for your reply.
I'm using nixos distro.

I've attached some log files that hopefully will help (sorry but I can't find a the DaVinci Resolve Capture Logs app at this time). This hardware was used on macOS hackintosh a few weeks ago so trying to understand why DR isn't working.
This machine has bith an Intel iGPU and a Radeon 580, just an FYI

Dwaine Maggart wrote:What Linux distro are you using?

Please provide a Resolve diagnostics log, which you can generate using the DaVinci Resolve Capture Logs app (has a gear icon).