GNOME Bugzilla – Bug 340656
Crash on large files
Last modified: 2008-01-15 13:07:21 UTC
Steps to reproduce: 1. Open a large image which (>300 MPixel, city maps are a good idea) Stack trace: Stack trace: There was no stack trace. The program popped up a message box "Glib-ERROR**: gmem.c:141:failed to allocate 16384 bytes\naborting..." " and then partially terminated. Two zombie processes were remaining (script-fu and png) which must be killed with the task manager. This happens after the file was successfully loaded. The load progress bar disappears and after 0,5 sec this message box appears. Other information: The main problems why this happens are: * Independend of the pixel depth images are converted to a 6 byte per pixel format. * The Gimp swap can be at most 2047,999999 MByte large. * Both together restrict the size of pictures to about 300 MPixel. Possible partially solution of the problem: * Open the swap file in a 64 bit mode (LARGE_FILE), this moves the limit to about 600 MPixel even when you still use 32 bit addressing internally. Possible complete solution of the problem: Possibility 1 (depreciated): * Open the swap file in a 64 bit mode (LARGE_FILE) and use 64 bit addressing. * Addressing of a tile can be done by a 64 bit address Possibility 2 (appreciated): * Open the swap file in a 32 bit mode and use multiple swap files, all around 1 GByte large (like DVD Video). * Addressing of a tile can be done by a 64 bit address, where Bit 63...32 are the swap file no and Bit 31...0 are the address. * Addressing of a tile can be done by a 32 bit address, where Bit 31...20 are the swap file no and Bit 19...0 are the address/4096. Other information: Photoshop on Win32 do this job without any problem. Even on smaller images it is much faster and needs less memory. A 4 bit image only need 0.5 byte per pixel, not 6 byte per pixel. An old version of ACDSee (Win32) also can open these files (and allows displaying loaded parts of the image while still loading).
You are most probably simply running out of memory. How much virtual memory do you have and how is the tile cache size configured in the GIMP preferences?
Machine is big enough. * Windows XP, SP2, english * 3 GByte of usable RAM + about 2x4 GByte of Swap * Free disk space for GIMP swap+tmp: 186 GByte Image has the following parameters: * Contents: Streetmap of London * Format: PNG, 4 bit, 16 colors, generated with PNMTOPNG * Size of file: 102,325,097 bytes * Width: 31800 pixel * Height: 29800 pixel * Frame Count: 1 * Resolution: 120 dpi x 120 dpi * Can be displayed with ACDSee Pentax within some seconds (takes 464 MByte of RAM and about 8 sec CPU time) * Can be displayed and processed with Photoshop CS1
Created attachment 64834 [details] Load dialog 200 ms before it is closed So far the program works. Internally it loads a 29800 x 31800 x 4 bit memory image (about 500 MB) from the pnglib call.
Created attachment 64835 [details] 200 ms later an error box Now internally GIMP blows up to 2 GByte and writes 2^31-1 Byte to the GIMP cache. GIMP terminates and leave a zombie process script-fu.exe with 9484 KByte memory usage. Process still hold a handle on the GIMP swap file.
Created attachment 64836 [details] 200 ms later an error box Now internally GIMP blows up to 2 GByte and writes 2^31-1 Byte to the GIMP cache. GIMP terminates and leave a zombie process script-fu.exe with 9484 KByte memory usage. Process still hold a handle on the GIMP swap file.
Created attachment 64837 [details] Load dialog 200 ms before it is closed So far the program works. Internally it loads a 29800 x 31800 x 4 bit memory image (about 500 MB) from the pnglib call.
Problem occures with 128x128 medium tiles and with 256x256 large tiles. Preview in the file open dialog works. The attachment shows the file open dialog ca. 200 ms before this dialog is closed.
Another (downloadable) test image with the same problem: ftp://ftp.iks-jena.de/mitarb/lutz/hacking/testbilder-klemm-b.png Size is 24576 x 18432 Pixel with 8 bit palette.
A GIMP crasher. File is 1 Mbyte large and a valid PNG.
Urgs. File is 1005 KByte large, but only 1000 KByte are allowed. Y:\TestImages\apple>dir *.png Volume in drive Y has no label. Volume Serial Number is 8CED-3C76 Directory of Y:\TestImages\apple 2001-11-12 20:33 81 image-0-bw.png 2001-11-03 13:02 230 image-0-color.png 2001-11-12 20:33 102 image-1-bw.png 2001-11-03 13:02 415 image-1-color.png 2001-11-12 20:33 142 image-2-bw.png 2001-11-03 13:02 945 image-2-color.png 2001-11-12 20:33 245 image-3-bw.png 2001-10-14 14:44 2,100 image-3-color.png 2001-11-12 20:33 461 image-4-bw.png 2001-10-14 14:45 5,008 image-4-color.png 2001-11-12 20:33 991 image-5-bw.png 2001-10-14 14:45 17,237 image-5-color.png 2001-11-12 20:33 2,527 image-6-bw.png 2001-10-14 14:47 54,921 image-6-color.png 2001-11-12 20:33 7,275 image-7-bw.png 2001-11-03 13:02 168,201 image-7-color.png 2001-11-12 20:33 19,567 image-8-bw.png 2001-11-03 13:02 514,610 image-8-color.png 2001-11-12 20:33 52,435 image-9-bw.png 2001-11-02 00:46 1,609,483 image-9-color.png 2001-11-12 20:34 140,560 image-a-bw.png 2001-11-02 00:49 5,173,267 image-a-color.png 2001-11-12 20:35 373,058 image-b-bw.png 2001-11-02 00:58 17,256,219 image-b-color.png 2001-11-12 20:38 1,029,273 image-c-bw.png 2001-11-02 01:31 54,165,463 image-c-color.png 26 File(s) 80,594,816 bytes 0 Dir(s) 640,652,144,640 bytes free Y:\TestImages\apple>
I don't see what you are trying to show us. We know very well that GIMP needs more than 4GB to be able to load this file. It can use the swap file to handle some of this but you won't be very satisfied with the performance. I don't see the point of your bug report. GIMP cannot handle this image, so what? Are you going to submit patches to resolve this issue? Otherwise this report is pretty much pointless. You also didn't answer my question about the tile-cache size. The other information you provided is pretty much useless. I am now closing this report as a duplicate of bug #311932. *** This bug has been marked as a duplicate of 311932 ***
BTW, the swap file is opened in LARGEFILE mode. If this is not the case on the Windows platform, this is either a bug somewhere or simply a limitation of the operating system.
And yes, offsets into the swap file are of type off_t which should be 64bit if your system supports largefile access. We have successfully tested GIMP with swap files larger than 2GB on UNIX systems.