GNOME Bugzilla – Bug 774863
hashtable only tile cache is not thread safe
Last modified: 2017-07-23 18:47:19 UTC
On my Gentoo Linux, where all libraries are compiled from source, having loaded a jpeg image, the following sequence crashes Gimp nearly each time. Colors -> Desaturate -> Desaturate > Mode Luminance Here is a back trace GUI new func match: generic fallback using gegl copy (gimp:29824): GLib-GObject-CRITICAL **: g_object_unref: assertion 'G_IS_OBJECT (object)' failed (gimp:29824): GLib-GObject-CRITICAL **: g_object_unref: assertion 'G_IS_OBJECT (object)' failed (gimp:29824): GLib-GObject-CRITICAL **: g_object_unref: assertion 'G_IS_OBJECT (object)' failed (gimp:29824): GLib-GObject-CRITICAL **: g_object_unref: assertion 'G_IS_OBJECT (object)' failed *** Error in `/usr/bin/gimp': corrupted double-linked list: 0x000000000feb6800 *** ======= Backtrace: ========= /lib64/libc.so.6(+0x7072b)[0x7f8becd0072b] /lib64/libc.so.6(+0x76345)[0x7f8becd06345] /lib64/libc.so.6(+0x773b7)[0x7f8becd073b7] /usr/lib64/libglib-2.0.so.0(+0x397c2)[0x7f8bed5887c2] /usr/lib64/libglib-2.0.so.0(g_hash_table_destroy+0xe)[0x7f8bed589a6e] /usr/lib64/libgegl-0.3.so.0(+0x74988)[0x7f8beebc9988] /usr/lib64/libgobject-2.0.so.0(g_object_unref+0x135)[0x7f8bed87c535] /usr/lib64/libglib-2.0.so.0(g_slist_foreach+0x2d)[0x7f8bed5bb56d] /usr/lib64/libglib-2.0.so.0(g_slist_free_full+0xb)[0x7f8bed5bb58b] /usr/lib64/libgegl-0.3.so.0(+0x75604)[0x7f8beebca604] /usr/lib64/libgobject-2.0.so.0(g_object_unref+0x135)[0x7f8bed87c535] /usr/lib64/libgegl-0.3.so.0(+0x7416a)[0x7f8beebc916a] /usr/lib64/libgobject-2.0.so.0(g_object_unref+0x135)[0x7f8bed87c535] /usr/lib64/gegl-0.3/gegl-core.so(+0x467a)[0x7f8be2c5567a] /usr/lib64/libgegl-0.3.so.0(+0x844bd)[0x7f8beebd94bd] /usr/lib64/libglib-2.0.so.0(+0x75f6d)[0x7f8bed5c4f6d] /usr/lib64/libglib-2.0.so.0(+0x754f5)[0x7f8bed5c44f5] /lib64/libpthread.so.0(+0x75c6)[0x7f8bed0345c6] /lib64/libc.so.6(clone+0x6d)[0x7f8becd799ed]
This, and your bug 774615 smells like a typical case of Gentoo. Sorry but this stuff works for everybody else, on all platforms, on 32 and 64 bit.
Well maybe that came across a little harsh :) Do you use any special flags that could cause those bugs? Does such stuff happen with other apps?
(In reply to Michael Natterer from comment #2) > Well maybe that came across a little harsh :) Do you use any special > flags that could cause those bugs? Does such stuff happen with other > apps? After many trials I can now pinpoint the problem to the following environment settings when starting Gimp: GEGL_THREADS=4 GEGL_USE_OPENCL=yes I've been using these for ages but (only) recent (GIT) version of Gegl crash now, when these are set. Desaturate works just fine if these environment variables are deleted. I still consider this as a bug since an environment setting shouldn't crash an application. Bug 774615 is not affected since this environment wasn't used for 'root'.
Does either of them cause the crash, only one of them, or only both of them together?
(In reply to Michael Schumacher from comment #4) > Does either of them cause the crash, only one of them, or only both of them > together? It's only the setting GEGL_THREADS=4 which make Gimp crash.
Thanks for checking.
This commit is the most likely culprit e3e24a88be62f217e0fd7d963f41c9a28a8bffee
> After many trials I can now pinpoint the problem to the following > environment settings when starting Gimp: > > GEGL_THREADS=4 GEGL_USE_OPENCL=yes > > I've been using these for ages but (only) recent (GIT) version of Gegl crash > now, when these are set. Desaturate works just fine if these environment > variables > are deleted. > > I still consider this as a bug since an environment setting shouldn't crash > an application. These environment settings are knobs for testing experimental unstable features not yet considered stable - not an end-user performance tuning interface. Such tweaking of settings; whether during build or runtime decreases the credibility of gentoo originated bug reports.
(In reply to Øyvind Kolås from comment #8) > Such tweaking of settings; whether during build or runtime > decreases the credibility of gentoo originated bug reports. Oh, hold your horses, please! These settings have nothing to do with Gentoo, they aren't default settings in Gentoo. Anybody on any Linux system may set these environment variables. And these settings didn't crash Gimp for a long time. If some commit destroyed thread safeness, you should be glad to get some evidence that something is heavily broken. Image processing needs all the power a machine can deliver, and if an application cannot use multiple cores this is a real problem.
There is a real problem; which I will try to address. Sometimes the rolling release source based distros do provide good canary in the coal mine reports, but with gentoo it often takes too long to figure out what is special about the snowflake first. Bug reports from gentoo users often need additional scrutiny; to figure out if experimental compiler flags, cpu overclocking, custom patch sets or other performance tweaks have been enabled just in case.
(In reply to Øyvind Kolås from comment #7) > This commit is the most likely culprit > e3e24a88be62f217e0fd7d963f41c9a28a8bffee The problem also happens with this change reverted, tripped up by the crash sometimes happening after a delay - seemingly from an idle handler.
Helmut > don't take badly all comments on Gentoo. We often get the weirdest bug reports from Gentoo people so sometimes we can feel a little bitter (you know, after a long day…). But that's all in good faith. I used to be a desktop user of Gentoo as well (and still am a server user of Gentoo) and I like this distribution. Thanks for the report. :-)
There has been multiple thread safety fixes to GEGL recently, some mentioned in bug #784907, closing this bug for now. New bugs can be filed as concurrency issues turn up. *** This bug has been marked as a duplicate of bug 784907 ***