After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 785087 - Gimp 2.9.5 won't start if modelling.myb and modelling2.myb MyPaint brushes are installed on the system
Gimp 2.9.5 won't start if modelling.myb and modelling2.myb MyPaint brushes ar...
Status: RESOLVED FIXED
Product: GIMP
Classification: Other
Component: General
git master
Other Linux
: Normal normal
: 2.10
Assigned To: GIMP Bugs
GIMP Bugs
: 783943 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2017-07-18 21:08 UTC by Josep Febrer
Modified: 2018-01-03 08:21 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
MyPaint brush (6.79 KB, text/plain)
2017-07-18 21:08 UTC, Josep Febrer
Details
MyPaint brush (9.81 KB, text/plain)
2017-07-18 21:08 UTC, Josep Febrer
Details

Description Josep Febrer 2017-07-18 21:08:07 UTC
Created attachment 355888 [details]
MyPaint brush

I've just installed Gimp and MyPaint both from git master, they use different libmypaint library versions, Gimp uses libmypaint libmypaint-1.3.so.0.0.0 and MyPaint libmypaint-2.0.so.0.0.0.
But the new MyPaint includes some new brushes that if they are installed on the system they crash Gimp on startup. They are modelling.myb and modelling2.myb if I remove them Gimp can start normally.

If they are present an I run Gimp from the terminal I've got this output:

This is a development version of GIMP.  Debug messages may appear here.

Missing fast-path babl conversion detected, Implementing missing babl fast paths
accelerates GEGL, GIMP and other software using babl, warnings are printed on
first occurance of formats used where a conversion has to be synthesized
programmatically by babl based on format description

*WARNING*: missing babl fast path(s) between formats "CIE LCH(ab) double" and "R'G'B' double"
gimp: mypaint-mapping.c:88: mypaint_mapping_set_n: Assertion `input >= 0 && input < self->inputs' failed.
gimp: terminated: Aborted

I had to use strace to know which brushes are causing the crashes. With strace I've got this output:

lstat("/usr/share/mypaint/brushes/classic/modelling.myb", {st_mode=S_IFREG|0644, st_size=6957, ...}) = 0
open("/usr/share/mypaint/brushes/classic/modelling.myb", O_RDONLY) = 10
fstat(10, {st_mode=S_IFREG|0644, st_size=6957, ...}) = 0
lstat("/usr/share/mypaint/brushes/classic/modelling.myb", {st_mode=S_IFREG|0644, st_size=6957, ...}) = 0
read(10, "{\n    \"comment\": \"MyPaint brush "..., 6957) = 6957
write(2, "gimp: mypaint-mapping.c:88: mypa"..., 106gimp: mypaint-mapping.c:88: mypaint_mapping_set_n: Assertion `input >= 0 && input < self->inputs' failed.
) = 106
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f50c59af000
rt_sigprocmask(SIG_UNBLOCK, [ABRT], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, ~[RTMIN RT_1], [], 8) = 0
getpid()                                = 11018
gettid()                                = 11018
tgkill(11018, 11018, SIGABRT)           = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
--- SIGABRT {si_signo=SIGABRT, si_code=SI_TKILL, si_pid=11018, si_uid=1000} ---
futex(0x7f50c05b8880, FUTEX_WAKE_PRIVATE, 2147483647) = 0
write(2, "gimp: terminated: Aborted\n", 26gimp: terminated: Aborted
) = 26
exit_group(1)                           = ?
+++ exited with 1 +++



lstat("/usr/share/mypaint/brushes/classic/modelling2.myb", {st_mode=S_IFREG|0644, st_size=10041, ...}) = 0
open("/usr/share/mypaint/brushes/classic/modelling2.myb", O_RDONLY) = 10
fstat(10, {st_mode=S_IFREG|0644, st_size=10041, ...}) = 0
lstat("/usr/share/mypaint/brushes/classic/modelling2.myb", {st_mode=S_IFREG|0644, st_size=10041, ...}) = 0
read(10, "{\n    \"comment\": \"MyPaint brush "..., 10041) = 10041
write(2, "gimp: mypaint-mapping.c:88: mypa"..., 106gimp: mypaint-mapping.c:88: mypaint_mapping_set_n: Assertion `input >= 0 && input < self->inputs' failed.
) = 106
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f06b7efc000
rt_sigprocmask(SIG_UNBLOCK, [ABRT], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, ~[RTMIN RT_1], [], 8) = 0
getpid()                                = 11180
gettid()                                = 11180
tgkill(11180, 11180, SIGABRT)           = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
--- SIGABRT {si_signo=SIGABRT, si_code=SI_TKILL, si_pid=11180, si_uid=1000} ---
futex(0x7f06b2b05880, FUTEX_WAKE_PRIVATE, 2147483647) = 0
write(2, "gimp: terminated: Aborted\n", 26gimp: terminated: Aborted
) = 26
exit_group(1)                           = ?
+++ exited with 1 +++


I will attach both brushes on this bug report.
Comment 1 Josep Febrer 2017-07-18 21:08:43 UTC
Created attachment 355889 [details]
MyPaint brush
Comment 2 Jehan 2017-07-18 21:20:41 UTC
Argh. I guess they need to version their brushes and discard them when they use new features.
I opened this bug report on their tracker just now: https://github.com/mypaint/libmypaint/issues/101

Thanks for the report.
Comment 3 Jehan 2017-07-18 21:23:54 UTC
Also I confirmed the crash when I add one of these brushes in my MyPaint brush folder.
Comment 4 Michael Natterer 2017-07-18 21:25:56 UTC
If it's crashing in libmypaint, we should give them the bug.
Comment 5 Jehan 2017-07-18 21:29:00 UTC
I did open a report there (cf. comment 2). I guess you mean, let's just close this one. Well ok.
Comment 6 koko.fr.mu 2017-12-31 00:31:24 UTC
It becomes very annoying on Fedora 27, since the Dirty brushes aka Anti crash libmypaint 1.3. A temporary fix is to disable them in $HOME/.config/GIMP/2.9/gimprc by adding (mypaint-brush-path "/usr/local/share/mypaint/brushes:~/.mypaint/brushes"). It removes system brushes which are installed in /usr/share/mypaint/brushes/.
I hope this helps.
Comment 7 Jehan 2018-01-01 22:08:16 UTC
For info, not only is libmypaint versionned since libmypaint 2, but we now also depend specifically on mypaint-brushes-1.0, which are basically MyPaint brushes frozen as their last release (MyPaint 1.2.1).

As briend of MyPaint explain in their bug report, not only the new brushes was such crash a problem (which is not fixed yet on libmypaint side) but brushes for current libmypaint master are basically incompatible with libmypaint:

> Actually, there is one other issue that I'm not sure how to solve. With 2.0 not only did new inputs come over, but the way speed is calculated was changed from being relative-to-pixel to relative-to-hand. So a bunch of brushes now won't work "quite right" on 1.3. It's not that they aren't compatible or anything, but the calibration is off. So 1.3 release needs to use brushes from before those viewzoom commits. This stinks :-(

Well he says "not that they aren't compatible" but different behavior is actually incompatibility to me. :p

So here for the new dependency:

commit f8e1d3b9c83cc3d55c8f1ac8a1c02f36b278a4e2
Author: Jehan <jehan@girinstud.io>
Date:   Mon Jan 1 21:57:34 2018 +0100

    app, configure: adding dependency to mypaint-brushes.
    
    This ensures that MyPaint default brushes are installed, otherwise this
    makes the MyPaint brush tool quite useless and confusing unless MyPaint
    is installed (which was making MyPaint a de-facto dependency of GIMP
    until this commit!). Also we won't have to guess anymore the right path
    for these brushs. The path will be known at compile time.

 app/config/Makefile.am      |  1 +
 app/config/gimpcoreconfig.c | 24 +-----------------------
 configure.ac                |  2 ++
 3 files changed, 4 insertions(+), 23 deletions(-)

----------------------------------------------------------

As a consequence, we will get stable brushes for GIMP 2.10.
Comment 8 Michael Schumacher 2018-01-03 08:21:16 UTC
*** Bug 783943 has been marked as a duplicate of this bug. ***