I've been hitting a runtime (as opposed to compile-time) issue with a custom Arnold plugin (VOP shadeop) that calls a CVEX function.
I'm building against a bunch of HtoA/Hou versions, but the issue pops up in all of them, so for this post's sake, I'll pick: HtoA-6.1.3.1 (Arnold-7.1.3.0) and Houdini-19.0.657, using gcc-9 and hcustom's default -std=c++17 in this case (built in CentOS-7 using SCL devtoolset-9).
I'm linking against
-lHoudiniUT -lai
from the Houdini and HtoA installations respectively. The plugin compiles/links without errors and ldd -r
on the resultant .so
tracks no missing symbols or any other dependency issues.The problem happens at runtime, and exactly at the point when
CVEX_ContextT<VEX_32>.run()
is called (already verified that the context is valid, one per thread, and that the function is loaded successfully, i.e: no VEX errors before that call). At this point, the plugin crashes with the following output (calling kick
directly on an .ass
file for this test):... 00:00:00 224MB | starting 20 bucket workers of size 64x64 ... UT_TBBProxy: WARNING: Failed to bind to TBB - TBBPROXY_CreateTaskArena() UT_TBBProxy: WARNING: Failed to bind to TBB - TBBPROXY_DestroyTaskArena() UT_TBBProxy: WARNING: Failed to bind to TBB - TBBPROXY_TaskArenaExecute() UT_TBBProxy: WARNING: Failed to bind to TBB - TBBPROXY_ScalableAllocationCommand() UT_TBBProxy: WARNING: Failed to bind to TBB - TBBPROXY_InitializeTaskArena() kick: symbol lookup error: <houdini19.0.657>/dsolib/libpxr_plug.so: undefined symbol: _ZN3tbb10interface78internal20isolate_within_arenaERNS1_13delegate_baseEl <crash> $ c++filt _ZN3tbb10interface78internal20isolate_within_arenaERNS1_13delegate_baseEl tbb::interface7::internal::isolate_within_arena(tbb::interface7::internal::delegate_base&, long) $
So it seems TBB-related, and taking a closer look at
libHoudiniUT.so
shows that it contains the "Failed to bind to TBB"
string, though the code that issues the warning is not exposed in the HDK headers, but regardless, I believe the "undefined symbol..." error is the root cause from which all those "failure to bind" warnings cascade. Looking into the provenance of the signature
tbb::interface7::internal::isolate_within_arena(tbb::interface7::internal::delegate_base&, long)
, which was demangled by c++filt
above, I end up at the header <tbb/task_group.h>
(in $HDK/include), which only defines it when #if TBB_PREVIEW_ISOLATED_TASK_GROUP && __TBB_TASK_ISOLATION
. Okay, so then I took a look at hcustom
's compile flags and noticed they include -DTBB_PREVIEW_ISOLATED_TASK_GROUP
, so the compile side of that seems to be taken care of (I added both of those in my module and explicitly via $HCUSTOM_CFLAGS
just in case, but no improvement).So the only thing left that I can think of to look at are the 3
tbb
libraries (from ${HFS}/dsolib) that we're linking against (indirectly via -lHoudiniUT
), but when I check for the (demangled) public symbols, I see that the required signature is reported as available:$ nm -g libtbb.so.2 | c++filt | grep -i isolate_within_arena 00000000000220a0 T tbb::interface7::internal::isolate_within_arena(tbb::interface7::internal::delegate_base&, long)
TBB-2019_U9
making sure that TBB_PREVIEW_ISOLATED_TASK_GROUP && __TBB_TASK_ISOLATION
were both defined, then linked against that instead of the HDK-supplied tbb
, but the runtime "undefined symbol..." error persists <sigh>. Running out of ideas here...Does any of this ring any bells for anyone here?
Thanks in advance for any pointers!