Cyrill, Gimp is broken due to a kernel bug included in 3.12. It cannot open large files without failing memory allocations due to exceeding vm.max_map_count. The relevant bugzilla entries are
https://bugzilla.kernel.org/show_bug.cgi?id=67651 https://bugzilla.gnome.org/show_bug.cgi?id=719619#c0 They include details on how to reproduce the issue. In my case, a failure shows messages like this (gimp:11768): GLib-ERROR **: gmem.c:110: failed to allocate 4096 bytes (file-tiff-load:12038): LibGimpBase-WARNING **: file-tiff-load: gimp_wire_read(): error xinit: connection to X server lost waiting for X server to shut down /usr/lib64/gimp/2.0/plug-ins/file-tiff-load terminated: Hangup /usr/lib64/gimp/2.0/plug-ins/script-fu terminated: Hangup /usr/lib64/gimp/2.0/plug-ins/script-fu terminated: Hangup X-related junk is there was because I was using a headless server and xinit directly to launch gimp to reproduce the bug. Automated bisection using mmtests (https://github.com/gormanm/mmtests) and the configuration file configs/config-global-dhp__gimp-simple (needs local web server with a copy of the image file) identified the following commit. Test case was simple -- try and open the large file described in the bug. I did not investigate the patch itself as I'm just reporting the results of the bisection. If I had to guess, I'd say that VMA merging has been affected. d9104d1ca9662498339c0de975b4666c30485f4e is the first bad commit commit d9104d1ca9662498339c0de975b4666c30485f4e Author: Cyrill Gorcunov <[email protected]> Date: Wed Sep 11 14:22:24 2013 -0700 mm: track vma changes with VM_SOFTDIRTY bit Pavel reported that in case if vma area get unmapped and then mapped (or expanded) in-place, the soft dirty tracker won't be able to recognize this situation since it works on pte level and ptes are get zapped on unmap, loosing soft dirty bit of course. So to resolve this situation we need to track actions on vma level, there VM_SOFTDIRTY flag comes in. When new vma area created (or old expanded) we set this bit, and keep it here until application calls for clearing soft dirty bit. Thus when user space application track memory changes now it can detect if vma area is renewed. Reported-by: Pavel Emelyanov <[email protected]> Signed-off-by: Cyrill Gorcunov <[email protected]> Cc: Andy Lutomirski <[email protected]> Cc: Matt Mackall <[email protected]> Cc: Xiao Guangrong <[email protected]> Cc: Marcelo Tosatti <[email protected]> Cc: KOSAKI Motohiro <[email protected]> Cc: Stephen Rothwell <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: "Aneesh Kumar K.V" <[email protected]> Cc: Rob Landley <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> -- Mel Gorman SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
