GNOME Bugzilla – Bug 774615
GIT (2016/11/17) fails to compile with Floating point exception
Last modified: 2016-11-28 11:11:46 UTC
Compilation of the GIT (2016/11/17) version of GIT with the GIT version of GEGL fails with /bin/sh: line 1: 16652 Floating point exception(core dumped) GEGL_USE_OPENCL=no GEGL_SWAP=ram /usr/bin/gegl ../../icons/Symbolic/16/gimp-gradient-conical-symmetric.png -o 16/gimp-gradient-conical-symmetric.png -- gegl:invert-gamma
Hi, 1/ Could you tell us the git commit hash (for both GIMP and GEGL) please? 2/ Does the gegl call fail with any image? For instance if you have another PNG file "input.png" somewhere on your drive, and if you run this (be careful, make sure you have no file named "output.png" in your current directory because this command would overwrite it. Better run from some temp directory): > GEGL_USE_OPENCL=no GEGL_SWAP=ram /usr/bin/gegl output.png -o output.png -- gegl:invert-gamma Does it work and produce a file "output.png" or do you get the same error? 3/ Finally I can't help but notice that it uses `/usr/bin/gegl`. Did you actually install GEGL using the `/usr/` prefix? If not, this is likely your problem: it uses some older gegl version which was installed on your system. Make sure the prefix used in the GEGL installation is before any other prefix in your PATH environment variable.
Also, what exact Linux is this?
> 1/ Could you tell us the git commit hash (for both GIMP and GEGL) please? Trie today with the same problem. git checkout --quiet refs/git-r3/HEAD GIT update --> repository: git://git.gnome.org/gimp updating from commit: 571f5c86b3b12d4637849a702c2c921c9b2970ef to commit: 29ac01d6b75e1cfcd156c1953a5efb871ad432b3 git checkout --quiet refs/git-r3/HEAD GIT update --> repository: git://git.gnome.org/gegl at the commit: cd7fb514ec401a835c3208c66de6978145d08bd9 > 2/ Does the gegl call fail with any image? > > For instance if you have another PNG file "input.png" somewhere on your > drive, and if you run this (be careful, make sure you have no file named > "output.png" in your current directory because this command would overwrite > it. Better run from some temp directory): > > > GEGL_USE_OPENCL=no GEGL_SWAP=ram /usr/bin/gegl output.png -o output.png -- gegl:invert-gamma > > Does it work and produce a file "output.png" or do you get the same error? Yes, it works even with the exact same file which causes the floating-point exception during Gimp's install phase. Even more, it works successfully on the first 412 png-files when "Making all in Symbolic-Inverted" And, Gimp and GEGL (GIT from 2016/11/15) is my current WORKING version of Gimp. Helmut > 3/ Finally I can't help but notice that it uses `/usr/bin/gegl`. Did you > actually install GEGL using the `/usr/` prefix? > If not, this is likely your problem: it uses some older gegl version which > was installed on your system. Make sure the prefix used in the GEGL > installation is before any other prefix in your PATH environment variable. No, I am on GenToo Linux and /usr/bin/gegl is a symbolic link to /usr/bin/gegl-0.3 And yes, installation with prefix /usr is the standard for GenToo Linux. What can I do to help with finding the cause of this problem? I doubt that a back trace is of any help, isn't it? Helmut
> Yes, it works even with the exact same file which causes the floating-point exception during Gimp's install phase. Uh? That's extra weird. You are saying the exact same command (with the exact same file) works when you run it standalone, but not when it is run in make? That makes no sense, there has to be a difference somewhere. Try to run the exact same command from the exact same directory as make. There has to be as little difference as possible, because make doesn't normally do anything special else than running what it is told to. Does Gentoo change anything in the build environment (I used to use Gentoo, but that was long ago…)? > I doubt that a back trace is of any help, isn't it? Well no, a backtrace can actually be very helpful. A backtrace is nearly always helpful for a crash. But if you don't manage to crash this command as standalone, I don't really see how you can get a backtrace (unless you can get make to run every command in a debugger, which would be extra-slow. Is there even such a feature?). If you can get one, do it. :-)
I have tried several times with gegl and gimp up-to-date (GIT) at different days. The command GEGL_USE_OPENCL=no GEGL_SWAP=ram /usr/bin/gegl output.png -o output.png -- gegl:invert-gamma dies of a floating point exception for various image files. Doing 'make' in icons/Symbolic-Inverted *again and again*, finally processes all image files in this folder. Then 'make' at the global level succeeds in each case.
> GEGL_USE_OPENCL=no GEGL_SWAP=ram /usr/bin/gegl output.png -o output.png -- gegl:invert-gamma > > dies of a floating point exception for various image files. Sorry, are you saying it crashes also when running as standalone command? In this case, you should be able to get us a backtrace. > Doing 'make' in icons/Symbolic-Inverted *again and again*, finally processes all image files in this folder. Feels like a race condition of some sort in this case. So running in a debugger many times, you may be able to have it crash at some point and get us a backtrace (though debuggers are often annoying on race conditions since they slow down the whole program and make some race condition occur nearly impossible but that's worth a try at least).
So while I was testing an export plugin using GEGL, it crashed with this "Floating point exception" error again. Note that running the exact same export immediately after (no rebuild, nothing), it worked fine and this crash would not reproduce in any of my later tests. > /home/jehan/.local/lib/gimp/2.0/plug-ins/file-webp: fatal error: Floating point exception It crashed with a stacktrace which traces back to babl_init_db(). My babl repo was on commit 0fe05d1e85dda5e2f13cf8c206ff32b9976779e5. Pippin tells me on IRC that updating the babl repo may fix the issue (I indeed see active development on babl/babl-cache.c). In any case, seeing how rare it seems to happen, we'll have to wait to confirm. I still paste the trace below, just in case: /home/jehan/.local/lib/gimp/2.0/plug-ins/file-webp (pid:3219): [E]xit, [H]alt, show [S]tack trace or [P]roceed: s
+ Trace 236878
Created attachment 340840 [details] [review] Test patch: revert code to identify bug 774615 with old babl cache %0 bug Pippin's right; there was a time()-based mod-by-zero bug in babl, that would have also affected startup for gimp and plugins that used gegl. babl/babl-cache.c: babl_init_db() lines 188-189 Introduced Nov 15 commit 9e44467 Fixed Nov 20 commit fd10677 With the old broken conditional pasted into the latest babl master, it took 4 tries of 'make -k' in 'gimp/icons/Symbolic-Inverted' before it completed, with errors like this (on msys2/mingw): make: *** [Makefile:2232: 16/gimp-histogram.png] Error 127 ... Resembling Helmut's experience in comment 5. Apparently on Linux, SIGFPE 'Floating point exception' includes integer division overflow; see https://www.gnu.org/software/libc/manual/html_node/Program-Error-Signals.html. I think this bug is likely the culprit in both your cases. Patching the attachment to babl should reproduce the same symptoms (adjusted to occur more often) and confirm this is the same bug.
closing this as fixed now