GNOME Bugzilla – Bug 794752
Gimp 2 10 crashes during startup
Last modified: 2018-04-01 12:34:30 UTC
GNU Image Manipulation Program version 2.10.0-RC1 git-describe: GIMP_2_10_0_RC1-4-g0fe50c76f8 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.3.1 20180303 (Red Hat 7.3.1-5) (GCC) using GEGL version 0.3.31 (compiled against version 0.3.31) 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) > fatal error: Aborted Stack trace: [New LWP 11352] [New LWP 11353] [New LWP 11358] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". 0x00007f120f0e8d68 in __libc_read (fd=14, buf=buf@entry=0x7fffaade77d0, nbytes=nbytes@entry=256) at ../sysdeps/unix/sysv/linux/read.c:26 26 return SYSCALL_CANCEL (read, fd, buf, nbytes);
+ Trace 238520
Created attachment 370228 [details] a multithread bt from gdb
Hello, Did you build GIMP yourself? And libmypaint/mypaint-brushes as well? Did you force the mypaint-brushes v2 somehow to work with our configuration script? I can see you use mypaint-brushes v2 which are *NOT* compatible with GIMP (and not even released, nor is libmypaint). See bug 785087, which is the same issue that you have (and was fixed by versionning libmypaint and mypaint-brushes), and the still opened upstream bug: https://github.com/mypaint/libmypaint/issues/101 For the record, there is a reason we versionned libmypaint and mypaint-brushes, and if the configuration fails, it usually means you are not using the right version of the dependency (not that you should tweak the configure script). If you didn't tweak the configuration script to build GIMP, could you please upload your `config.log` because then there is a bug somewhere in our script.
I was going to start a bug regarding commit 368c7c051153157749af617f4101d24e9a15b2c8 but this seems related. Which was more a comment or nit pick -(mypaint-brush-path "/usr/share/mypaint/brushes:/usr/local/share/mypaint/brushes:~/.mypaint/brushes") +(mypaint-brush-path "/local/head/share/mypaint-data/1.0/brushes:~/.mypaint/brushes") 1) /local/head/share/mypaint-data/1.0/brushes is likely not correct Should be "/usr/share/mypaint-data/1.0//brushes" 2) ~/.mypaint/brushes can be problematic if the localy installed version of my paint exceeds v1.2.1 and you have some localy installed v2 brushes. hope this helps & keep up the good work. Should probably set mypaint-brush-path-writable to "" or a folder within ~/.config/GIMP/2.10.0 too
(In reply to mickski56 from comment #3) > 1) /local/head/share/mypaint-data/1.0/brushes is likely not correct > Should be "/usr/share/mypaint-data/1.0//brushes" Well neither actually. It must not be hardcoded and I think this was just an error of leaving some generated path in after a distcheck (to make the unit tests succeed, maybe). I made a fix for this issue. Thanks for the report. commit 479bcaafdd61c02d329c5a9b09b5bd9896ed79b2 (HEAD -> master, origin/master, origin/HEAD) Author: Jehan <jehan@girinstud.io> Date: Thu Mar 29 17:22:15 2018 +0200 configure, docs: set correct "mypaint-brush-path" value in man page. This was hard-coded to what I guess was a personal prefix (commit 368c7c0511), which is obviously wrong. This has to be constructed at compilation and the man must mirror whatever is the actual installation path of mypaint-brushes package. configure.ac | 4 ++++ docs/gimprc.5.in | 2 +- 2 files changed, 5 insertions(+), 1 deletion(-) > 2) ~/.mypaint/brushes can be problematic if the localy installed version of > my paint exceeds v1.2.1 and you have some localy installed v2 brushes. Well the problem is that this path comes from MyPaint itself which was not (and still isn't) versionning its brushes. So changing this path makes no sense because we would not get any brush anyway if the goal was to grab brushes initially installed for MyPaint. Actually this is even an old path. Now they use XDG (commit cf723b74cde5d1878a2bc148e5e22b5c60a6e2a1 on MyPaint repo from 2013!). Maybe we should get this path too, though it is also unversionned! But you are totally right that this is dangerous to mix these and that such data mix would continue to crash GIMP as long as MyPaint doesn't fix their library. On the other hand, MyPaint 2 has never been released yet either. I do hope that they will start versionning their data path by then (and especially that they will take ownership of mypaint-brushes repository!). And therefore we can still assume that any available brush is MyPaint 1 brushes (if people install development data, this is their responsibility to know what they are doing; dev data is unstable by definition). > hope this helps & keep up the good work. Yep it helped since I made a commit but that were actually other/unrelated problems. You could have made a separate bug reports, but well… it's done. :-) The problem here is simply that the reporter installed MyPaint brushes v2, and that is wrong. This should not happen. So either we have a bug somewhere in the configuration, or Patrick tweaked a script somewhere to force the wrong package into GIMP (if so, there is nothing we can do other than say "for your own good, don't do this" ;p). So I am waiting for input from you, Patrick. How did this happen? :-) > Should probably set > mypaint-brush-path-writable to "" or a folder within ~/.config/GIMP/2.10.0 > too No. The whole point of having a separate package (and not packaging MyPaint brushes within GIMP repo itself) is to be able to share with other projects using MyPaint brushes. I don't want to see any GIMP-specific path here. Ideally if all goes as planned, anyone who has custom brushes would install them in some directory shared between all programs, and MyPaint, GIMP or any other program using these brushes would just all see them on restart
I was gathering prerequisites for GIMP so I could try the new goodness. For mypaint-brushes I did a git clone of https://github.com/Jehan/mypaint-brushes I ran configure for gimp and built it without any tinkering with anything. You are right, they are for use by libmypaint 2.x. All I did was install it and then configure GIMP and build it. They mention that if I want brushes for version 1 I need to pull from the "v1.3.x" branch, so I'll try that and get back. I also had to switch to an early libmypaint (1.3), clean up and rebuild and now gimp works fine. Thanks for pointing my in the right direction.
No problems. Have fun with GIMP! :-)