GNOME Bugzilla – Bug 793371
GEGL's CRITICAL errors when closing a Cage transform polygon outside the image
Last modified: 2018-05-24 19:08:00 UTC
I'm not sure if there is already a bug report for this since Massimo talked about it in bug 792787, comment 22: > when closing a Cage transform polygon that is completely > outside the image rectangle, on the console there is a stream of > (gimp-2.9:1082): GEGL-CRITICAL **: 12:38:14.584: gegl_buffer_get: assertion 'GEGL_IS_BUFFER (buffer)' failed It's reproducible every time with these steps. We are talking potentially million of such CRITICALs so it is better to reproduce with a small polygon to get less. I have improved the debugging dialog to be more efficient, but it still freeze the whole GUI for a minute or 2 when the flow of errors is that huge. Anyway now I have backtraces of the errors: GNU Image Manipulation Program version 2.9.9 git-describe: GIMP_2_9_8-516-g5d200c2c4b C compiler: Using built-in specs. COLLECT_GCC=/usr/bin/gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/7/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-redhat-linux Configured with: ../configure --enable-bootstrap --enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --enable-checking=release --enable-multilib --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-gcc-major-version-only --with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --with-isl --enable-libmpx --enable-offload-targets=nvptx-none --without-cuda-driver --enable-gnu-indirect-function --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux Thread model: posix gcc version 7.2.1 20170915 (Red Hat 7.2.1-2) (GCC) using GEGL version 0.3.29 (compiled against version 0.3.29) using GLib version 2.54.3 (compiled against version 2.54.3) using GdkPixbuf version 2.36.11 (compiled against version 2.36.11) using GTK+ version 2.24.32 (compiled against version 2.24.32) using Pango version 1.40.13 (compiled against version 1.40.13) using Fontconfig version 2.12.6 (compiled against version 2.12.6) using Cairo version 1.15.10 (compiled against version 1.15.10) > GEGL-Error: gegl_buffer_get: assertion 'GEGL_IS_BUFFER (buffer)' failed Stack trace: [New LWP 24495] [New LWP 24496] [New LWP 24676] [New LWP 24678] [New LWP 24688] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". 0x00007f9a0187d3a7 in waitpid () from /lib64/libpthread.so.0
+ Trace 238387
> GEGL-Error: gegl_buffer_get: assertion 'GEGL_IS_BUFFER (buffer)' failed > GEGL-Error: gegl_buffer_get: assertion 'GEGL_IS_BUFFER (buffer)' failed > GEGL-Error: gegl_buffer_get: assertion 'GEGL_IS_BUFFER (buffer)' failed > GEGL-Error: gegl_buffer_get: assertion 'GEGL_IS_BUFFER (buffer)' failed
Not a blocker since it is an edge case (making a useless cage outside of the image), but still making it a 2.10 milestone, because such a flow of CRITICAL is not a nice thing.
I saw some outdated #ifdef in the problematic code so I cleaned a bit to up-to-date code. The bug is still there. See commits 2956cde6cfb8024bc0a313e652a7a49f493e1294 and ec14e1006e3dc47b4c6e245fef50285d48b5e955. I don't paste a new trace, which is nearly the same except that the criticals now happen on g_return_val_if_fail() inside gimp_cage_transform_compute_destination() just before the call to gegl_buffer_sample() instead of in gegl_buffer_get() which was there just before the cleaning. According to GEGL code, gegl-operation-composer.c: > /* A composer with a NULL aux, can still be valid, the > * subclass has to handle it. > */ So it seems this is expected in GEGL code and therefore likely a bug in GIMP. Basically the third parameter (aux_buf) of gimp_operation_cage_transform_process() can be NULL and this has to be handled accordingly.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gimp/issues/1302.