GEGL has started working locally lately, and the time has come that others can join use or more easily help develop GEGL. I have put a tarball containing my GEGL development sandbox with md5 based checksums on PNGSs to detect regressions in tests.

The sandbox contains test cases, small example programs and a set of base ops (png/jpg load, png save, porter duff compositing, math ops, scaling, a box blur and some more.

To use the sandbox you will need recent(?) glib, libpng, libjpg and SDL (for a test case that displays an animation), as well as CVS checkouts of the gegl and babl modules from GNOME CVS.

http://pippin.gimp.org/gegl/gegl-demo.tgz

Hi pippin, I'm sorry to bother you with this, but I'm not sure to understand, is this tarball some kind of derivative of the official GEGL? Or something to continue the experimentations with your so interesting sandboxes? Or is this the last official GEGL release ?

I'm waiting for so long (since the project was announced) that GEGL would be usable that I cannot believe it's true, and that the day has come ! :-) -- Best Regards

Øyvind Kolås writes:

GEGL has started working locally lately, and the time has come that others can join use or more easily help develop GEGL. I have put a tarball containing my GEGL development sandbox with md5 based checksums on PNGSs to detect regressions in tests.

The sandbox contains test cases, small example programs and a set of base ops (png/jpg load, png save, porter duff compositing, math ops, scaling, a box blur and some more.

To use the sandbox you will need recent(?) glib, libpng, libjpg and SDL (for a test case that displays an animation), as well as CVS checkouts of the gegl and babl modules from GNOME CVS.

http://pippin.gimp.org/gegl/gegl-demo.tgz

Where can I obtain a 'ccache'?

executing 'make bin' produces this output:

ccache gcc -I/usr/include/gegl-1.0/gegl -I/usr/include/babl-0.0/babl -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libpng12 -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/SDL -D_REENTRANT -I. -O2 -Wall -g -c -o ops/op_add.o ops/op_add.c make: ccache: Command not found
make: *** [ops/op_add.o] Error 127

.. *googles it* http://ccache.samba.org/

Okay, I know now. You should mention that requirement in the README.

I can compile, but not link.
linking gives loads of undefined reference errors, such as:
:ops/op_add.c:139: undefined reference to `gegl_buffer_pixels' :ops/op_add.c:141: undefined reference to `gegl_buffer_pixels' :ops/op_add.c:154: undefined reference to `gegl_buffer_get_fmt' :ops/op_add.c:167: undefined reference to `gegl_buffer_get_fmt' :ops/op_add.c:170: undefined reference to `gegl_buffer_pixels' :ops/op_add.c:185: undefined reference to `gegl_buffer_set_fmt' :ops/op_add.c:174: undefined reference to `gegl_buffer_pixels' ops/op_box_blur.o: In function `calc_have_rect':ops/op_box_blur.c:203: undefined reference to `gegl_
:ops/op_box_blur.c:207: undefined reference to `gegl_operation_set_have_rect'
ops/op_box_blur.o: In function `calc_need_rect':ops/op_box_blur.c:222: undefined reference to `gegl_
:ops/op_box_blur.c:224: undefined reference to `gegl_operation_set_need_rect'
ops/op_box_blur.o: In function `evaluate':ops/op_box_blur.c:51: undefined reference to `gegl_operati
:ops/op_box_blur.c:61: undefined reference to `gegl_buffer_get_format' :ops/op_box_blur.c:137: undefined reference to `gegl_buffer_get_fmt' :ops/op_box_blur.c:156: undefined reference to `gegl_buffer_set_fmt' :ops/op_box_blur.c:70: undefined reference to `gegl_buffer_get_format' :ops/op_box_blur.c:175: undefined reference to `gegl_buffer_get_fmt' :ops/op_box_blur.c:195: undefined reference to `gegl_buffer_set_fmt' ops/op_composer.o: In function `calc_have_rect':ops/op_composer.c:211: undefined reference to `gegl_
:ops/op_composer.c:212: undefined reference to `gegl_operation_get_have_rect'
:ops/op_composer.c:219: undefined reference to `gegl_operation_set_have_rect'
:ops/op_composer.c:225: undefined reference to `gegl_operation_set_have_rect'

It seems that the required symbols are in libgegl-1.0.a but not in libgegl-1.0.so.
Hardcoding '/usr/lib/libgegl-1.0.a' instead of 'pkg-config --libs gegl' in LDFLAGS fixes the undefined references (if you also add babl to the pkg-config part)

Also, for the 'png' target, 'rm -f' should be used instead of 'rm' -- make errored because there were no pngs to remove.

Still having some problems -- the contents of the PNGs look like this:

babl-extension.c:178 babl_extension_load() dlopen() failed:
/usr/lib/babl-0.0/CIE-Lab.so: invalid mode for dlopen(): Invalid argument
babl-extension.c:178 babl_extension_load() dlopen() failed:
/usr/lib/babl-0.0/gegl-fixups.so: invalid mode for dlopen(): Invalid argument
babl-extension.c:178 babl_extension_load() dlopen() failed:
/usr/lib/babl-0.0/gggl.so: invalid mode for dlopen(): Invalid argument
babl-extension.c:178 babl_extension_load() dlopen() failed:
/usr/lib/babl-0.0/naive-CMYK.so: invalid mode for dlopen(): Invalid argument
babl-format.c:420 babl_format()
babl_format("RaGaBaA float"): not found Using host libthread_db library "/lib/tls/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread 1085512768 (LWP 27666)]
0x40796c1e in waitpid () from /lib/tls/libc.so.6 #0 0x40796c1e in waitpid () from /lib/tls/libc.so.6 #1 0x4073c2c9 in strtold_l () from /lib/tls/libc.so.6 #2 0x406e056d in system () from /lib/tls/libpthread.so.0 #3 0x08069b72 in babl_backtrack () at babl-internal.c:68 #4 0x08069b8b in babl_die () at babl-internal.c:74 #5 0x080690a9 in babl_format (name=0x80718d0 "RaGaBaA float") at babl-format.c:420
#6 0x08053c7b in evaluate (operation=0x8088800, output_prop=0x80736c1 "y") at ops/op_scale.c:99
#7 0x0804ec3d in evaluate (operation=0x8088800, output_prop=0xfffffe00 ) at
ops/op_filter.c:173

during 'make png', I got errors like:

./anim > anim.png

** (process:28086): WARNING **: gegl_node_set_valist:OpNop has no property named: 'x'
make[1]: [anim.png] Error 255 (ignored) ./brightness-and-contrast > brightness-and-contrast.png ./brightness-and-contrast-with-math-ops > brightness-and-contrast-with-math-ops.png ./buffer-test-0 > buffer-test-0.png
make[1]: [buffer-test-0.png] Error 255 (ignored) ./buffer-test-1 > buffer-test-1.png
make[1]: [buffer-test-1.png] Error 255 (ignored) ./introspect > introspect.png

** (process:28108): WARNING **: gegl_node_set_valist:OpNop has no property named: 'x'
./multi-gegl > multi-gegl.png
make[1]: [multi-gegl.png] Error 255 (ignored)

At this point I'm suspecting there is something odd about my libdl.so.

Øyvind Kolås writes:

I rather think the problem is in babl :/ I see now that on one of my systems the line containing the string "dl_handle = dlopen (path, RTLD_NOW)" has RTLD_NOW been replaced with 2.

(by the way, what kind of system are you compiling this on?)

gcc version 4.0.3 20060115 (prerelease) (Debian 4.0.2-7) GNU Make 3.80
binutils 2.16.1
GNU ld version 2.16.91 20051214 Debian GNU/Linux CPU: AMD Duron 800mhz (not that it should matter)

Making that change RTLD_NOW -> 2 causes the png contents to look more like:

babl-db.c:98 babl_db_insert() Eeeeek
Using host libthread_db library "/lib/tls/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread 1085512768 (LWP 30869)]
0x40796c1e in waitpid () from /lib/tls/libc.so.6 #0 0x40796c1e in waitpid () from /lib/tls/libc.so.6 #1 0x4073c2c9 in strtold_l () from /lib/tls/libc.so.6 #2 0x406e056d in system () from /lib/tls/libpthread.so.0 #3 0x40024252 in babl_backtrack () at babl-internal.c:68 #4 0x4002426b in babl_die () at babl-internal.c:74 #5 0x4002b84c in babl_db_insert (db=0x0, item=0x80837b8) at babl-db.c:98 #6 0x40025fdf in babl_type_new (first_arg=0x4002cdde) at babl-type.c:135 #7 0x4001ed65 in init () at CIE-Lab.c:415 #8 0x08065120 in babl_extension_load (path=0x80833c0 "/usr/lib/babl-0.0/CIE-Lab.so")
at babl-extension.c:194
#9 0x080653e8 in babl_extension_init () at babl-extension.c:238 #10 0x080632aa in babl_init () at babl.c:40 #11 0x080571cc in gegl_init (argc=0xbffff910, argv=0xbffff914) at gegl-init.c:38
#12 0x0805694a in main (argc=1, argv=0xbffff984) at add-test.c:8

Which is less obvious, but I think -- It tries to load the CIE-Lab module and crashes during registering the module's associated type(s). I have a pretty recent glib, too (week old CVS checkout). No idea what to do here -- I'm not even entirely sure whether the above is better or worse :)

actually, it seems stupid that making the above change would even have an effect, because..

"
/* The MODE argument to `dlopen' contains one of the following: */ #define RTLD_LAZY 0x00001 /* Lazy function call binding. */ #define RTLD_NOW 0x00002 /* Immediate function call binding. */ #define RTLD_BINDING_MASK 0x3 /* Mask of binding time value. */ #define RTLD_NOLOAD 0x00004 /* Do not load the object. */ #define RTLD_DEEPBIND 0x00008 /* Use deep binding. */ "

..On my system RTLD_NOW is the same as 2. (?)

Øyvind Kolås writes:

OK,. I suspect the dynamic loading of babl extensions doesn't work properly on your machine. I have now modified babl in CVS in such a manner that we can hope GEGL at least runs (albeit slowly) without babl extensions.

Do a CVS update of babl, make install it, and then remove all files from /usr/local/lib/babl-0.0 and see if it is possible to breathe some life into GEGL.

Yep.. as you said, slooow (esp for anim), but works. Nice! introspect is rather interesting. I look forward to coding some of the needed Ops when the system is stable enough in that area. GEGL is a lot closer to the model that feels natural to me for making images.

Btw, on my machine I almost always use --prefix=/usr, so that was /usr/lib/babl-0.0/ -- I'm wondering if there is some dogma unknowingly included that assumes /usr/local. dlopen() usage seems pretty simple; I haven't compared babl's usage with glib's, but normally these things work (ie. Gimp colorselector modules and display filters load OK.)

Then again, for GIMP I have to explicitly specify --enable-shared, so perhaps there *is* something dodgy with my system.

Øyvind Kolås wrote:

GEGL has started working locally lately, and the time has come that others can join use or more easily help develop GEGL. I have put a tarball containing my GEGL development sandbox with md5 based checksums on PNGSs to detect regressions in tests.

The sandbox contains test cases, small example programs and a set of base ops (png/jpg load, png save, porter duff compositing, math ops, scaling, a box blur and some more.

To use the sandbox you will need recent(?) glib, libpng, libjpg and SDL (for a test case that displays an animation), as well as CVS checkouts of the gegl and babl modules from GNOME CVS.

Got all of those, (including the gegl-demo.tar I downloaded this morning) and I was able to compile them, as well as run the "make bin" in gegl-demo. I think compilation went fine (didn't notice any errors come by).

The problems start when I run "make png". This stops with an error because the "@rm" command has too few arguments (no *.png there at all). Do you need a "-" in front of this command to have "make" continue on errors?

If I understand this command correctly, you are trying to delete all the zero-size PNG files that are not *_ref.png? On my system (SuSe 9.0 Linux), this would have to be "-f 5" to the "cut" command; with the "-f 4" it results in a list of all values "0". I don't know if this is system-specific behavior of the "cut" command?

Anyway, I can comment out this whole command. With that, I do get results. This is the output I get:

#@rm `ls *.png -s1 | grep " *0 .*" | cut -f 5 -d ' ' | grep -v "_ref.png"` make[1]: Entering directory `/data/src/gegl/gegl-demo' ./add-test > add-test.png
make[1]: [add-test.png] Error 139 (ignored) ./anim > anim.png

** (process:22391): WARNING **: gegl_node_set_valist:OpNop has no property named: 'x'
make[1]: [anim.png] Error 139 (ignored) ./brightness-and-contrast-with-math-ops > brightness-and-contrast-with-math-ops.png make[1]: [brightness-and-contrast-with-math-ops.png] Error 139 (ignored) ./brightness-and-contrast > brightness-and-contrast.png make[1]: [brightness-and-contrast.png] Error 139 (ignored) ./buffer-test-0 > buffer-test-0.png
make[1]: [buffer-test-0.png] Error 139 (ignored) ./buffer-test-1 > buffer-test-1.png
make[1]: [buffer-test-1.png] Error 139 (ignored) ./introspect > introspect.png

** (process:22402): WARNING **: gegl_node_set_valist:OpNop has no property named: 'x'
./multi-gegl > multi-gegl.png
make[1]: [multi-gegl.png] Error 139 (ignored) ./scaling > scaling.png
make[1]: [scaling.png] Error 139 (ignored) make[1]: Leaving directory `/data/src/gegl/gegl-demo'

It seems the "Error 139" actually is a Segmentation fault. However, in spite of that, the only two for which I get a zero-byte output file are anim.png and multi-gegl.png. The others: 503808 add-test.png
389120 brightness-and-contrast-with-math-ops.png 278528 brightness-and-contrast.png 4096 buffer-test-0.png
4096 buffer-test-1.png
4744 introspect.png
172032 scaling.png
seem to come out correctly.

Is this a positive outcome? I hope it provides you with some useful feedback.

Eric

http://pippin.gimp.org/gegl/gegl-demo.tgz

/Øyvind K.

Øyvind Kolås wrote:

This is indeed a mostly positive outcome, but I wonder where it segfaults (after the most important things have happened as they should). Could you do a backtrace with gdb?

I did, after hard-coding the output filename so I didn't get all that stuff on standard out and didn't have to deal with redirecting. The result:

#0 0x4002bbb7 in void_tile () from /opt/gimp-2.3.4/lib/libgegl-1.0.so.2 #1 0x4002bc5e in message () from /opt/gimp-2.3.4/lib/libgegl-1.0.so.2 #2 0x4002c12e in gegl_tile_store_message () from /opt/gimp-2.3.4/lib/libgegl-1.0.so.2 #3 0x4002c30d in message () from /opt/gimp-2.3.4/lib/libgegl-1.0.so.2 #4 0x4002c12e in gegl_tile_store_message () from /opt/gimp-2.3.4/lib/libgegl-1.0.so.2 #5 0x4002a6c8 in message () from /opt/gimp-2.3.4/lib/libgegl-1.0.so.2 #6 0x4002c12e in gegl_tile_store_message () from /opt/gimp-2.3.4/lib/libgegl-1.0.so.2 #7 0x4002ca4d in message () from /opt/gimp-2.3.4/lib/libgegl-1.0.so.2 #8 0x4002c12e in gegl_tile_store_message () from /opt/gimp-2.3.4/lib/libgegl-1.0.so.2 #9 0x4002901b in message () from /opt/gimp-2.3.4/lib/libgegl-1.0.so.2 #10 0x4002c12e in gegl_tile_store_message () from /opt/gimp-2.3.4/lib/libgegl-1.0.so.2 #11 0x4002ca4d in message () from /opt/gimp-2.3.4/lib/libgegl-1.0.so.2 #12 0x4002c12e in gegl_tile_store_message () from /opt/gimp-2.3.4/lib/libgegl-1.0.so.2 #13 0x4002a6c8 in message () from /opt/gimp-2.3.4/lib/libgegl-1.0.so.2 #14 0x4002c12e in gegl_tile_store_message () from /opt/gimp-2.3.4/lib/libgegl-1.0.so.2 #15 0x4002901b in message () from /opt/gimp-2.3.4/lib/libgegl-1.0.so.2 #16 0x4002c12e in gegl_tile_store_message () from /opt/gimp-2.3.4/lib/libgegl-1.0.so.2 #17 0x4002ca4d in message () from /opt/gimp-2.3.4/lib/libgegl-1.0.so.2 #18 0x4002c12e in gegl_tile_store_message () from /opt/gimp-2.3.4/lib/libgegl-1.0.so.2 #19 0x40028143 in gegl_buffer_void () from /opt/gimp-2.3.4/lib/libgegl-1.0.so.2 #20 0x40026fea in gegl_buffer_dispose () from /opt/gimp-2.3.4/lib/libgegl-1.0.so.2 #21 0x405c7ec5 in g_object_unref ()
from /opt/gimp-2.3.4/lib/libgobject-2.0.so.0 #22 0x4002c20e in dispose () from /opt/gimp-2.3.4/lib/libgegl-1.0.so.2 #23 0x4002c89e in dispose () from /opt/gimp-2.3.4/lib/libgegl-1.0.so.2 #24 0x40027011 in gegl_buffer_dispose () from /opt/gimp-2.3.4/lib/libgegl-1.0.so.2 #25 0x405c7ec5 in g_object_unref ()
from /opt/gimp-2.3.4/lib/libgobject-2.0.so.0 #26 0x0804c45a in finalize (object=0x8065ca0) at ops/op_composer.c:120 #27 0x405c7fa3 in g_object_unref ()
from /opt/gimp-2.3.4/lib/libgobject-2.0.so.0 #28 0x40020225 in finalize () from /opt/gimp-2.3.4/lib/libgegl-1.0.so.2 #29 0x405c7fa3 in g_object_unref ()
from /opt/gimp-2.3.4/lib/libgobject-2.0.so.0 #30 0x4001f9c6 in gegl_graph_remove_child () from /opt/gimp-2.3.4/lib/libgegl-1.0.so.2 #31 0x4001f76b in gegl_graph_remove_children () from /opt/gimp-2.3.4/lib/libgegl-1.0.so.2 #32 0x4001f5a7 in finalize () from /opt/gimp-2.3.4/lib/libgegl-1.0.so.2 #33 0x405c7fa3 in g_object_unref ()
from /opt/gimp-2.3.4/lib/libgobject-2.0.so.0 #34 0x0805491d in main (argc=1, argv=0xbffff904) at add-test.c:43

Seems to be somewhere in the cleanup...

I looked into more detail into the problem with the anim.c. The error message that I get is:

** (process:22391): WARNING **: gegl_node_set_valist:OpNop has no property named: 'x'

When I remove the "x" and "y" properties from OpNop ("no operation"?), I again get a segfault, with the following backtrace:

#0 0x4002bbb7 in void_tile () from /opt/gimp-2.3.4/lib/libgegl-1.0.so.2 #1 0x4002bc5e in message () from /opt/gimp-2.3.4/lib/libgegl-1.0.so.2 #2 0x4002c12e in gegl_tile_store_message () from /opt/gimp-2.3.4/lib/libgegl-1.0.so.2 #3 0x4002c30d in message () from /opt/gimp-2.3.4/lib/libgegl-1.0.so.2 #4 0x4002c12e in gegl_tile_store_message () from /opt/gimp-2.3.4/lib/libgegl-1.0.so.2 #5 0x4002a6c8 in message () from /opt/gimp-2.3.4/lib/libgegl-1.0.so.2 #6 0x4002c12e in gegl_tile_store_message () from /opt/gimp-2.3.4/lib/libgegl-1.0.so.2 #7 0x4002ca4d in message () from /opt/gimp-2.3.4/lib/libgegl-1.0.so.2 #8 0x4002c12e in gegl_tile_store_message () from /opt/gimp-2.3.4/lib/libgegl-1.0.so.2 #9 0x4002901b in message () from /opt/gimp-2.3.4/lib/libgegl-1.0.so.2 #10 0x4002c12e in gegl_tile_store_message () from /opt/gimp-2.3.4/lib/libgegl-1.0.so.2 #11 0x4002ca4d in message () from /opt/gimp-2.3.4/lib/libgegl-1.0.so.2 #12 0x4002c12e in gegl_tile_store_message () from /opt/gimp-2.3.4/lib/libgegl-1.0.so.2 #13 0x4002a6c8 in message () from /opt/gimp-2.3.4/lib/libgegl-1.0.so.2 #14 0x4002c12e in gegl_tile_store_message () from /opt/gimp-2.3.4/lib/libgegl-1.0.so.2 #15 0x4002901b in message () from /opt/gimp-2.3.4/lib/libgegl-1.0.so.2 #16 0x4002c12e in gegl_tile_store_message () from /opt/gimp-2.3.4/lib/libgegl-1.0.so.2 #17 0x4002ca4d in message () from /opt/gimp-2.3.4/lib/libgegl-1.0.so.2 #18 0x4002c12e in gegl_tile_store_message () from /opt/gimp-2.3.4/lib/libgegl-1.0.so.2 #19 0x40028143 in gegl_buffer_void () from /opt/gimp-2.3.4/lib/libgegl-1.0.so.2 #20 0x40026fea in gegl_buffer_dispose () from /opt/gimp-2.3.4/lib/libgegl-1.0.so.2 #21 0x405c7ec5 in g_object_unref ()
from /opt/gimp-2.3.4/lib/libgobject-2.0.so.0 #22 0x4002c20e in dispose () from /opt/gimp-2.3.4/lib/libgegl-1.0.so.2 #23 0x4002c89e in dispose () from /opt/gimp-2.3.4/lib/libgegl-1.0.so.2 #24 0x40027011 in gegl_buffer_dispose () from /opt/gimp-2.3.4/lib/libgegl-1.0.so.2 #25 0x405c7ec5 in g_object_unref ()
from /opt/gimp-2.3.4/lib/libgobject-2.0.so.0 #26 0x0804bb22 in evaluate (operation=0x8067a10, output_prop=0x806794c "") at ops/op_box_blur.c:79
#27 0x0804df1d in evaluate (operation=0x8067a10, output_prop=0x8066420 "output") at ops/op_filter.c:173 #28 0x400237cc in gegl_operation_evaluate () from /opt/gimp-2.3.4/lib/libgegl-1.0.so.2 #29 0x4001f32f in visit_pad () from /opt/gimp-2.3.4/lib/libgegl-1.0.so.2 #30 0x400265ad in gegl_visitor_visit_pad () from /opt/gimp-2.3.4/lib/libgegl-1.0.so.2 #31 0x40024e1f in visitable_accept () from /opt/gimp-2.3.4/lib/libgegl-1.0.so.2 #32 0x40025750 in gegl_visitable_accept () from /opt/gimp-2.3.4/lib/libgegl-1.0.so.2 #33 0x40026112 in dfs_traverse () from /opt/gimp-2.3.4/lib/libgegl-1.0.so.2 #34 0x400260d3 in dfs_traverse () from /opt/gimp-2.3.4/lib/libgegl-1.0.so.2 #35 0x400260d3 in dfs_traverse () from /opt/gimp-2.3.4/lib/libgegl-1.0.so.2 #36 0x400260d3 in dfs_traverse () from /opt/gimp-2.3.4/lib/libgegl-1.0.so.2 #37 0x400260d3 in dfs_traverse () from /opt/gimp-2.3.4/lib/libgegl-1.0.so.2 #38 0x400260d3 in dfs_traverse () from /opt/gimp-2.3.4/lib/libgegl-1.0.so.2 #39 0x400260d3 in dfs_traverse () from /opt/gimp-2.3.4/lib/libgegl-1.0.so.2 #40 0x40025fa1 in gegl_visitor_dfs_traverse () from /opt/gimp-2.3.4/lib/libgegl-1.0.so.2 #41 0x4001f1a3 in gegl_eval_mgr_apply () from /opt/gimp-2.3.4/lib/libgegl-1.0.so.2 #42 0x400213ab in gegl_node_apply_roi () from /opt/gimp-2.3.4/lib/libgegl-1.0.so.2 #43 0x08054b18 in main (argc=1, argv=0xbffff8e4) at anim.c:87

I do not know why anim and multi-gegl crashes completely though, they are the tests needing the most memory, but apart from that they shouldn't be much more special than the other tests.

Well, it seems at least anim is intended to be interactive. That may be some kind of an installation issue on my side.

I hope this helps. If I don't have time to spend on this tonight, I should be able to do some more experimenting tomorrow.

Eric

Eric Grivel wrote:

Øyvind Kolås wrote:

This is indeed a mostly positive outcome, but I wonder where it segfaults (after the most important things have happened as they should). Could you do a backtrace with gdb?

I did, after hard-coding the output filename so I didn't get all that stuff on standard out and didn't have to deal with redirecting. The result:

#0 0x4002bbb7 in void_tile () from /opt/gimp-2.3.4/lib/libgegl-1.0.so.2

Looked a little bit closer. It turns out that the tile parameter passed to void_tile() is NULL, which causes the segmentation violation when trying to access tile->data. If I add a NULL check at the top of the void_tile function:
if (tile == NULL) {
return TRUE;
}
then add-test runs successfully. Adding a counter tells me that the void_tile function is called 72 times in add_test with a NULL tile parameter.

I don't know if any of this information is useful, but I'm just providing it on the off chance it gives you a hint of what's going on.

I looked into more detail into the problem with the anim.c. The error message that I get is:

** (process:22391): WARNING **: gegl_node_set_valist:OpNop has no property named: 'x'

When I remove the "x" and "y" properties from OpNop ("no operation"?), I again get a segfault, with the following backtrace:

#0 0x4002bbb7 in void_tile () from /opt/gimp-2.3.4/lib/libgegl-1.0.so.2

This seems to be the same problem as the one above. With the NULL check in place, ANIM runs (very slowly). In this case, void_tile is called 3109 times with a NULL tile parameter.

The multi-gegl test doesn't run at all. Running it in gdb gives:

Starting program: /data/src/gegl/gegl-demo/multi-gegl [New Thread 16384 (LWP 20034)]

Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 20034)] 0x00000000 in ?? ()

and backtrace gives: #0 0x00000000 in ?? ()

This seems to be a different problem.

Eric

Øyvind Kolås wrote:

Try to update from CVS now, I moved the "voiding of buffers" to the finalize instead of the dispose handler. (if void_tile still gets NULL tiles now it needs to be looked further into.)

Yes, this works. I now only have a segfault in multi-gegl; I will try and figure out what that is about.

In "introspect", I get a warning: ** (process:15214): WARNING **: gegl_node_set_valist:OpNop has no property named: 'x'

Did you fix that in a new version of gegl-demo already? It doesn't stop the program from working but obviously the "OpNop" isn't getting the right parameters.

Eric

Eric Grivel wrote:

Øyvind Kolås wrote:

Try to update from CVS now, I moved the "voiding of buffers" to the finalize instead of the dispose handler. (if void_tile still gets NULL tiles now it needs to be looked further into.)

Yes, this works. I now only have a segfault in multi-gegl; I will try and figure out what that is about.

That error goes away if I remove the call to gtk_init() in multi-gegl.c; the program then seems to work file without it???

Possibly something with my gtk support, although I thought I verified I had all the versions of the libraries you listed.

Eric

Eric Grivel wrote:

That error goes away if I remove the call to gtk_init() in multi-gegl.c; the program then seems to work file without it???

I also experienced a crash in gtk_init(), although I was able to get a backtrace. It seemed to be a bad interaction between SDL and gtk. I was using SDL 1.2.10, and downgrading it alleviated the crash.

Philip

Philip Lafleur wrote:

Eric Grivel wrote:

That error goes away if I remove the call to gtk_init() in multi-gegl.c; the program then seems to work file without it???

I also experienced a crash in gtk_init(), although I was able to get a backtrace. It seemed to be a bad interaction between SDL and gtk. I was using SDL 1.2.10, and downgrading it alleviated the crash.

Interesting. I downloaded SDL 1.2.9, installed and re-compiled, and it didn't crash anymore. I looked at the SDL site and found a number of mentions of this in their newsgroup, so I guess it's a known issue.

Thanks for the info; I'll stick with SDL 1.2.9 for now.

Eric

Øyvind Kolås wrote:

GEGL has started working locally lately, and the time has come that others can join use or more easily help develop GEGL. I have put a tarball containing my GEGL development sandbox with md5 based checksums on PNGSs to detect regressions in tests.

The sandbox contains test cases, small example programs and a set of base ops (png/jpg load, png save, porter duff compositing, math ops, scaling, a box blur and some more.

To use the sandbox you will need recent(?) glib, libpng, libjpg and SDL (for a test case that displays an animation), as well as CVS checkouts of the gegl and babl modules from GNOME CVS.

http://pippin.gimp.org/gegl/gegl-demo.tgz

/Øyvind K.

Awesome! I've synched the gegl-source several times in repeated attempts to be able to "put a rocket" under gegl as someone phrased it a while back. However, every time I was unable to get enough of an overview to actually look deeper. This was just what I needed. :)

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"));

here the gegl_node_get_pad returns NULL as well. The pd->root seems to correctly defined (the first in the , 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.

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 in the , 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.