GNOME Bugzilla – Bug 712330
crash when opening png file: gmem.c:110: failed to allocate 4096 bytes
Last modified: 2013-12-30 21:12:07 UTC
Created attachment 259837 [details] Backtrace of crash GNU Image Manipulation Program version 2.8.8 git-describe: GIMP_2_8_6-115-g76dd14f using GEGL version 0.2.0 (compiled against version 0.2.0) using GLib version 2.38.1 (compiled against version 2.38.1) using GdkPixbuf version 2.30.0 (compiled against version 2.30.0) using GTK+ version 2.24.22 (compiled against version 2.24.22) using Pango version 1.36.0 (compiled against version 1.36.0) using Fontconfig version 2.11.0 (compiled against version 2.11.0) using Cairo version 1.13.1 (compiled against version 1.13.1) Fedora package: gimp-2.8.8-3.fc20.x86_64 The crash occurs when I run the following command: % gimp pirkko1.png The crash happens immediately after the loading bar hits 100% Image information: pirkko1.png: PNG image data, 10196 x 14024, 8-bit/color RGB, non-interlaced, 148M, just scanned using gnome simple scan gthumb can open the picture correctly
That image allocates more than 1 Gig of tiles, how large is your tile cache setting? Check preferences.
Such a large image works fine here btw with a tile cache size of 2 Gig and 12 Gig of physical memory.
I have tile cache size of 7 Gig and 16 Gig of physical memory.
You must be on a 64 bit system then. I can't reproduce that crash at all. Does it happen with all images of similar size or only with that one?
In the last hour I have scanned 4 large images (same dimensions, ~ same size). They all crash the same way. Yes. I'm running a 64bit system. Fedora bug reporter automatically reported also a fedora bug: https://bugzilla.redhat.com/show_bug.cgi?id=1030624 with more automatically analyzed results as attachments.
Hmm:
+ Trace 232777
Thread 1 (Thread 0x7f0472f7d9c0 (LWP 1840))
--> This (failing to allocate 4kB) makes it seem as if the GIMP process has completely exhausted the amount of memory the OS is willing to give it. Are there system limits on how much memory a user process is allowed to have ("ulimit -m")? If not, it seems as if you've simply run out of available memory (RAM + Swap).
NB: This is the relevant line of the backtrace which Bugzilla hid so obligingly: msg = 0x7f0476dccbe0 "gmem.c:110: failed to allocate 4096 bytes"
I have recently been hitting this on 64 bit Fedora 19, since a recent round of package updates. I never had a problem before. Running gimp with strace shows that it fails to do an mmap system call; ... mmap(NULL, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fe1fad55000 mmap(NULL, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fe1fad51000 mmap(NULL, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fe1fad4d000 mmap(NULL, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM (Cannot allocate memory) and further digging shows that it's not out of memory, it is out of maps. I increased sysctl vm.max_map_count from 65530 to 131072, and the problem has gone away. Looking at /proc/<pid>/maps in the now-working gimp process, I see 70054 maps, which confirms that it has used more than the previous limit. It looks as though something has changed in the way memory is mapped.
Is this bug 719619? This one involves the 3.12 Linux kernel.
Yes, it is something to do with the 3.12 Linux kernel. I can confirm that reverting to 3.11 makes the problem I'm seeing go away. With 3.12, a particular sequence of gimp operations (with a 36 megapixel image) results in 70054 entries in /proc/<pid>/maps, while the same set of steps with kernel 3.11 only has 1177 maps entries.
I'm resolving this bug as a duplicate of the newer report - because that one has the 3.12 kernel in focus from the start. *** This bug has been marked as a duplicate of bug 719619 ***