GNOME Bugzilla – Bug 793936
Deleting a brush brought up the bug report window
Last modified: 2018-05-24 19:15:38 UTC
I deleted a brush when that brush was in the list of brushes selected by a tag and also might have been the active brush. Here's the debug window output: GNU Image Manipulation Program version 2.9.9 git-describe: GIMP_2_9_8-614-g827d747fae C compiler: Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/6.4.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-6.4.0-r1/work/gcc-6.4.0/configure --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/6.4.0 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/6.4.0/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/6.4.0 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/6.4.0/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/6.4.0/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/6.4.0/include/g++-v6 --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/6.4.0/python --enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --disable-nls --enable-checking=release --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 6.4.0-r1 p1.3' --disable-esp --enable-libstdcxx-time --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --disable-multilib --with-multilib-list=m64 --disable-altivec --disable-fixed-point --enable-targets=all --disable-libgcj --enable-libgomp --disable-libmudflap --disable-libssp --disable-libcilkrts --disable-libmpx --enable-vtable-verify --enable-libvtv --enable-lto --without-isl --enable-libsanitizer --enable-default-pie --enable-default-ssp Thread model: posix gcc version 6.4.0 (Gentoo 6.4.0-r1 p1.3) using GEGL version 0.3.29 (compiled against version 0.3.29) using GLib version 2.55.0 (compiled against version 2.55.0) using GdkPixbuf version 2.36.11 (compiled against version 2.36.11) using GTK+ version 2.24.31 (compiled against version 2.24.31) using Pango version 1.40.14 (compiled against version 1.40.14) using Fontconfig version 2.12.4 (compiled against version 2.12.4) using Cairo version 1.14.8 (compiled against version 1.14.8) > GIMP-CRITICAL: gimp_tagged_remove_tag: assertion 'GIMP_IS_TAGGED (tagged)' failed Stack trace: [New LWP 16428] [New LWP 16429] [New LWP 16445] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". 0x00007f267504155c in waitpid () from /lib64/libpthread.so.0
+ Trace 238443
Created attachment 369209 [details] two more bug report pop-ups while removing a tag from a brush
Do you have a pattern to reproduce this error? I tried adding and removing tag when you opened this report (as I indeed saw in the trace that it was relative to deleting a tag) but could not reproduce.
(In reply to Jehan from comment #2) > Do you have a pattern to reproduce this error? I tried adding and removing > tag when you opened this report (as I indeed saw in the trace that it was > relative to deleting a tag) but could not reproduce. The only pattern is that the error occurs when doing a lot of tagging and then deleting some of the newly added tags. For instance, in the last two cases here's what I had done prior to the error: Make marks with all brushes of a particular size (roughly any brush between 100px and 300px), looking for a particular type of mark. Tag the ones that looked promising, using a new tag Select the new tag and go through all the tagged brushes one by one. Then here's where the error pops up: Remove the newly added tags from the brushes that don't really make quite the type of mark I was looking for. Say test five brushes, remove the tag from the fifth brush, test six more, remove the tag from the last-tested brush, and so on. After repeating this process, eventually the error happens. But there doesn't seem to be any way to reliably trigger the error (I tried to trigger the error on purpose, but couldn't). Maybe GIMP and the file system's timing of commiting changes to disk might be colliding? This is on an SSD disk, though I was thinking of moving the installation folder back to a spinning rust disk. If it matters: My brushes are arranged in folders. The seven or so top-level folders are mostly named by size categories, with subfolders according to the source of the brush. So each size-based top-level folder might have subfolders "gg", "gimp", "cazu", "jag", etc. So there are multiple subfolders with the same name, just in different top-level folders. I do this because the folder names become auto-generated tags.
-- 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/1321.