Closed tkarabela closed 1 year ago
It looks like a lifetime issue - storing GeometryComponentFieldContext
in variables in the node_geo_exec()
function seems to fix the crash. I was also getting AddressSanitizer warnings about use-after-out-of-scope, that might have been the same issue.
Hard to debug since on Windows it runs fine. :/ The field manipulation is still not 100% clear to me, there seemd to be multiple ways of doing teh same thing at the time of writing this, and since then I merged 2 versions updates of Blender's master so some things might have changed without me keeping track of it.
Another example is the creation of nodes with a variable number of parameters: I had to introduce this new feature in the node system beyong using it for OpenMfx nodes, though it was on the course of being implemented independently on the master branch... Might trigger some surprises eventually ^^
PS: Did not receive your email, can you tell me the first 3 letters of the domain name as a hint?
I've sent you an e-mail to your domain exppad.com - if there's any trouble, just write me and I'll reply to you - my e-mail is in my profile.
Regarding this bug:
I'll try it with a newer GCC on Ubuntu 22.04. I thought I would try with GCC on Windows, too, but Blender only has precompiled dependencies for MSVC, so I won't bother for now ^^;
I've looked into it a bit more and what happens in the Mfx code is this:
GeometryComponentFieldContext
grabs a const reference to the GeometryComponent
(the GeometryComponent
is an l-value here, so this is fine)FieldEvaluator
grabs a const reference to the GeometryComponentFieldContext
(which is currently r-value, not given its own variable).evaluate()
on the FieldEvaluator
it wants to access the GeometryComponent
reference through the GeometryComponentFieldContext
reference, but the GeometryComponentFieldContext
is out of scope at this point since it only exists as an r-value used when constructing the FieldEvaluator
.(If it was using pointers instead of references, I could see why dereferencing a pointer from a temporary struct would be problematic. With const references, I'm not really sure what the rules are...)
I've grepped through the current source code and it looks that everywhere the "context" is given its own variable before passing it to the "evaluator", eg:
...so I would suggest doing the same - it shouldn't hurt anything :)
After #81 was fixed, I've compiled a debug build from version
adc0e195d31fc2b676959831c46d87ef7039ea65
and I'm able to create the OpenMfx node. Continuing with instructions from https://openmfx.org/QuickStart/using-openmfx.html#as-a-geometry-node, I select the "Explode" effect and connect input/output. However, when connecting the "normal" input:I get SIGSEGV that happens inside the
cornerEvaluator.evaluate();
call:It's not obvious to me what the segmentation fault is about - from GDB it looks that it's dereferencing
0x10
(could be NULL + small offset?):Parameters to the
context.get_varray_for_input(field_input, mask, scope);
look fine, though:Edit: It looks that the
context
is wrong and the segmentation fault is from vtable jump (?)