GNOME Bugzilla – Bug 719619
Gimp crashes silently on large images with 3.12 kernel
Last modified: 2014-05-20 20:58:58 UTC
I've found that if I'm running the 3.12 Linux kernel, then if I try to open a very large image in GIMP, it crashes while trying to open it - for example, this 15427 x 12549 pixel tif image available from the European Southern Observatory web site: http://www.eso.org/public/archives/images/original/eso0949c.tif. When I try to open this or similar sized images, the progress bar at the bottom of the file open dialog crawls across to 100%, then GIMP stops responding for a few seconds, and then the entire GIMP window disappears with no error message from either GIMP or the operating system, System Monitor shows no gimp process running, and the only entries I can find at the relevant time in any of the log files in /var/log are like this: Nov 22 06:15:36 nick-desktop kernel: [ 1458.563084] traps: gimp-2.8[4160] trap int3 ip:7f508c2dd3d9 sp:7fff6768a050 error:0 The same problem happens if I try to create a new large image - select New from the file menu, enter 12000 pixels for the width and height in the dialog, and OK. After a few seconds of no response, the GIMP window vanishes. I can open or create and work on smaller images (eg the 20 megapixel 5472x3648 images from my Sony camera) without any problem. If I boot up a version of the 3.11 kernel instead - I tried both 3.11.0 and 3.11.10 - then I can open or create the large images without any problem. I tested this on both Ubuntu 13.10 and Linux Mint 16 amd64, and with both Gimp 2.8.8 and 2.8.10. The problem happens with both the 3.12.1 and 3.12.2 kernels. The machine I'm testing on has 32Gb of RAM and over 1Tb of free disk space.
Hey, Thanks for the report. On http://www.linuxmint.com/rel_petra_mate_whatsnew.php they say that Linux Mint 16 uses Linux 3.11. Did you compile 3.12 yourself? Or you used an experimental package maybe (if so, where from?)? Thanks.
No, I installed the mainline 3.12 kernels for Ubuntu / Linux Mint that are available at http://kernel.ubuntu.com/~kernel-ppa/mainline/. One thing I forgot to mention in my original report was that I also tested Gimp 2.8.8 and 2.8.10 on Ubuntu 13.10 and Mint 16 with the 3.12.0 kernel from http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.12-saucy/. Same problem as with the 3.12.1 and 3.12.2 kernels - a crash with large images.
Ok. I was going to update my mint soon anyway. So I will do it again in a few days, and will try this kernel. Can you confirm that this is the one you installed: http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.12-saucy/linux-image-3.12.0-031200-generic_3.12.0-031200.201311031935_amd64.deb
Yes, that's the kernel I installed. I downloaded http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.12-saucy/linux-headers-3.12.0-031200_3.12.0-031200.201311031935_all.deb http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.12-saucy/linux-headers-3.12.0-031200-generic_3.12.0-031200.201311031935_amd64.deb http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.12-saucy/linux-image-3.12.0-031200-generic_3.12.0-031200.201311031935_amd64.deb to a temp folder, and then ran sudo dpkg -i *.deb in that folder.
I have the same problem on Arch linux 3.12.2 kernel (from official repo), gimp 2.8.8. Gimp crashes when I try to load ~77MB png image 9920x13652, with similar error visible in dmesg: traps: gimp[11348] trap int3 ip:7fa9b41a0289 sp:7fffb8ddff20 error:0
Hello, I updated my Arch to latest version (kernel 3.12.5), this makes no difference - gimp still crashes with following error printed on console: (gimp:1245): GLib-ERROR **: gmem.c:110: failed to allocate 16384 bytes Trace/breakpoint trap (core dumped) I tried fiddling with gimp memory settings as suggested here: https://bbs.archlinux.org/viewtopic.php?id=173659 After setting tile cache size to 256MB (was 7GB) and max new image size to 256MB, gimp loads big images successfully (but swaps to disk and works terribly slow) I have 16GB of RAM in my system, 14.5GB was free when I was testing, so this must be bug in glib memory allocation or in kernel.
After seeing the above I tested changing gimp tile cache size with 3.12.6 kernel. Changing it to 512Mb allows me to create a new 12000x12000 pixel image, which was previously causing gimp to crash with the 3.12 kernel. However, if I up the new image size to 16000x16000, gimp still crashes out. Changed the tile cache size down to 128Mb and I was able to create a new 16000x16000 image. However, as noted above, reducing the tile cache size really makes things slow. Even shutting down gimp becomes very slow - after creating a blank 16000x16000 image, it takes about 15 seconds between selecting quit from the file menu and the gimp window actually closing.
I also just tested against the 3.13 rc5 kernel with the gimp tile cache size at the default. Same crash as with 3.12: (gimp:2669): GLib-ERROR **: /build/buildd/glib2.0-2.38.1/./glib/gmem.c:110: failed to allocate 4096 bytes (script-fu:2680): LibGimpBase-WARNING **: script-fu: gimp_wire_read(): error Rebooted back into the 3.11.10 kernel and all is well.
I have filed a bug against Linux 3.12, though I am unsure whether this bug lies within Linux 3.12, GIMP or glib. https://bugzilla.kernel.org/show_bug.cgi?id=67651
This looks like a kernel bug to me. I can reproduce this here, on kernel 3.12.5, Arch Linux x86_64, glibc 2.18-11. I created new images that were 16000x16000 to test this. I have 8 GB of memory. I do not have any swap space. I was able to get a backtrace with debugging symbols, and this error is happening because malloc () is returning NULL for some of our allocations (specifically, in my case, allocations for image tiles). glib then detects this for us, and then spits out the error message: (gimp-2.8:22436): GLib-ERROR **: gmem.c:110: failed to allocate 4096 bytes malloc should not normally return NULL under these circumstances because I have plenty of free memory on the machine. (Even if I did not, glibc malloc would not normally return NULL). This does not happen with gimp-2.9, so the port to gegl somehow avoids this bug. I cannot reproduce this under valgrind. I cannot reproduce this if I run gimp with the environment variable MALLOC_MMAP_MAX_ set to 0. I'm therefore guessing this has something to do with changes in the kernel's mmap implementation between 3.11 and 3.12.
Created attachment 264848 [details] Stack trace Stack trace. To sum up my previous comment, if any of you want to try a temporary workaround for this bug, you can run gimp like this: MALLOC_MMAP_MAX_=0 gimp
I can confirm that it's a kernel change in 3.12. Over on bug 712330, I did some investigation and see that with 3.12 is is running out of entries in the maps table. The test I was doing results in 1177 entries in /proc/<pid>/maps with the 3.11 kernel, but 70054 entries with the 3.12 kernel. The default maps limit is 65530, so malloc returns null when the maps reaches that limit.
*** Bug 712330 has been marked as a duplicate of this bug. ***
*** Bug 722541 has been marked as a duplicate of this bug. ***
> malloc should not normally return NULL under these circumstances because I have > plenty of free memory on the machine. (Even if I did not, glibc malloc would > not normally return NULL). Shouldn't GLib/GIMP check for NULL and show an error message instead of crash? Also the bug appears on Linux 3.13 RC8 with the same type of error message: (gimp:1694): GLib-ERROR **: /build/buildd/glib2.0-2.39.3/./glib/gmem.c:108: failed to allocate 16384 bytes
That message is the check for NULL. Because getting null is a rare case, glib aborts when NULL is returned. glib does provide other allocation functions that allow the application to handle NULL values more gracefully, but we didn't use them because an allocation like this should never fail under normal circumstances anyway.
> Because getting null is a rare case NULL is only returned in rare cases if an error appears. But NULL is also easily returned in non-rare cases if you are running a Linux system without overcommitting.
(In reply to comment #17) > NULL is only returned in rare cases if an error appears. But NULL is also > easily returned in non-rare cases if you are running a Linux system without > overcommitting. It's true that you can get NULL if you're out of memory, depending on how your kernel is set up. Gimp's current solution is to try to avoid situations where you're completely out of memory. Gimp alone should never be able to use over a certain portion of your system's ram (which is user configurable). If memory usage grows too high, we manually swap image tiles to disk. At the point where there's no memory left, there's not really too much we can do anyway. If a 16 KB allocation fails (like above), we probably can't save images, and we might not even be able to pop up a dialog box.
> At the point where there's no memory left, there's not really too much we can > do anyway. If a 16 KB allocation fails (like above), we probably can't save > images, and we might not even be able to pop up a dialog box. Even if you can't show immediately anything to the user due to OOM the process should still be kept open. Just imagine a user that invests some work on an image and wants to scale it up a little. If GIMP crashes here the user would lose the work he has done. But if GIMP would do nothing the user can still handle the problem manually to save his work (for example closing another processes to free memory). GIMP could also try to revert the last action if it was the cause for the problem to free memory and then print an error message that the operation couldn't be performed.
BTW, what happened to the bug at kernel.org? Last comment there is by Mike.
The fix for this appears to have been backported to the latest 3.12 kernel. I just installed the 3.12.13 kernel on Mint 16 amd64 from http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.12.13-trusty/, and I no longer get the crash that was happening with earlier versions of the 3.12 kernel when opening or creating very large images (e.g 16000x16000 pixels).
I have made now a test on the Linux Kernel 3.13.4 from Ubuntu 14.04 dev (Ubuntu 3.13.0-12.32-generic) and could successfully scale up an image from 1680x1050 to 53760x33600.
Let's finally resolve this as NOTGNOME then.