[HDK] CVEX Woes With HtoA

   1982   1   0
User Avatar
Member
941 posts
Joined: 7月 2005
Offline
Hi all,

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)
Just in case, and grasping at straws at this point, I built my own 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!
Edited by Mario Marengo - 2022年9月11日 08:21:02
Mario Marengo
Senior Developer at Folks VFX [folksvfx.com] in Toronto, Canada.
User Avatar
Member
941 posts
Joined: 7月 2005
Offline
-- SOLVED --

There was a "placement new" operation in the code which used an Arnold allocator. This interfered with Houdini's own allocation strategy and is explicitly warned against in the HDK docs:

TFM
Custom Allocators
Houdini is built with special custom allocator libraries that override the default allocation routines (eg. malloc, free, etc.). As such any code you build or link into HDK plugins cannot use their own such libraries such as tbbmalloc_proxy. If you do, then conflicts and crashes can occur as a result.

Serves me right for being lazy and copy-pasting someone else's code!
Edited by Mario Marengo - 2022年9月11日 13:38:03
Mario Marengo
Senior Developer at Folks VFX [folksvfx.com] in Toronto, Canada.
  • Quick Links