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 -laifrom the Houdini and HtoA installations respectively. The plugin compiles/links without errors and ldd -ron the resultant .sotracks 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 kickdirectly on an .assfile 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.soshows 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++filtabove, 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_CFLAGSjust in case, but no improvement).So the only thing left that I can think of to look at are the 3
tbblibraries (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_U9making sure that TBB_PREVIEW_ISOLATED_TASK_GROUP && __TBB_TASK_ISOLATIONwere 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!
