Fredrik Alstromer wrote:
Some of them end up in segfaults (which is ok, gives you a starting
point to work on, right?). I ended up examining the clones.c, which uses
an xml-parser to define the graph. It segfaults when in the call to
gegl_node_apply/gegl_eval_mgr_apply, as the gegl_node_get_pad returns null.
pad = gegl_node_get_pad (root, pad_name); /* returns NULL */
if (pad->node != root) /* segfault */
root = pad->node;
In an attempt to figure out how the stuff works, I traced through it a
couple of times, and it appears that the last statement in
gegl_xml_parse is part of the problem (the "hacky redirect" comment
being scary enough...) :)
/* hacky redirect */
gegl_node_add_pad (ret, gegl_node_get_pad (pd->root, "output"));
This was indeed the problem, replacing the "output" with "process"
solved the problem for all demos/tests based on xmls. However, it seems
a bit far fetched that this would be just a typo, is there something
else I missed which would correct the situation in a more reliable fashion?
here the gegl_node_get_pad returns NULL as well. The pd->root seems to
correctly defined (the first <node> in the <tree>, I suppose?). Sure
enough this triggers an assertion failed, by the way, which I missed the
first couple of times around (I thought it was just another warning
related to the "unable to set operation threshold" problem). How do
these pads get defined? Any hints on what I missed? :)
Thanks,
/ Fredrik.
_______________________________________________
Gegl-developer@xxxxxxxxxxxxxxxxxxxxxx
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
