After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 398311 - GIMP swap file overflow
GIMP swap file overflow
Status: RESOLVED FIXED
Product: GIMP
Classification: Other
Component: General
2.2.x
Other Windows
: Normal enhancement
: 2.4
Assigned To: GIMP Bugs
GIMP Bugs
: 435384 442420 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2007-01-19 09:38 UTC by Pawel Pawlak
Modified: 2008-01-15 13:23 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
Suggested patch (8.47 KB, patch)
2007-01-25 01:45 UTC, Tor Lillqvist 		needs-work Details | Review
Suggested patch (7.33 KB, patch)
2007-01-25 10:55 UTC, Tor Lillqvist 		committed Details | Review

Description Pawel Pawlak 2007-01-19 09:38:28 UTC 
Steps to reproduce:
1. Load a large image, so that the GIMP swap file grows very large
2. Wait until image loads
3. Watch the GIMP crash (message window with some error flashes on the taskbar and all you can do is to close the GIMP)


Stack trace:


Other information:
"A large image" in my case was a 19000px x 28000px PNG file (size on disk is about 3MB). I noticed, that the GIMP swap file grew to 2048MB, which is the 32-bit signed integer boundary, and then the GIMP crashed.

System is Windows 2000 Professional with all updates. File system is NTFS.
Comment 1 Pawel Pawlak 2007-01-19 09:44:12 UTC 
Forgot to mention - the GIMP 2.3.12 also suffers from this bug
Comment 2 Sven Neumann 2007-01-19 19:31:49 UTC 
People should build gimp with large file support on Windows then. The source is prepared for this. Closing as NOTABUG.
Comment 3 Tor Lillqvist 2007-01-20 16:41:04 UTC 
Hmm, when you say "the source is prepared", what do you mean? As far as I see the source uses off_t for tile swap file offsets, which in the Microsoft C library is 32 bits. To use large files, one needs to use gint64 offsets, and a slightly different API (_lseeki64(), _telli64(), _stati64() etc). Sure, this sucks, but the Microsoft C library maintains binary compatibility back to the mid-90s, before Windows itself (?) supported large files. Unlike Solaris and Linux, it is not enough to just add a macro definition to the compilation to make all the file IO calls large file aware. Yeah, this sucks, too, as far as I see they could easily have made it work that way.
Comment 4 Sven Neumann 2007-01-20 18:45:59 UTC 
Then GLib should provide an abstraction layer for this.
Comment 5 Tor Lillqvist 2007-01-25 01:45:03 UTC 
Created attachment 81142 [details] [review]
Suggested patch

But until GLib does, how about this patch? Seems to work fine for me on XP. I created a 30000x30000 image and the tile swap file grew to over 10 GB when I filled it with a gradient;)
Comment 6 Sven Neumann 2007-01-25 07:18:16 UTC 
Why so complicated? Instead of defining LargeOffset, just use gint64 on all platforms. That would make the patch a lot smaller and the code more readable.
Comment 7 Tor Lillqvist 2007-01-25 10:55:05 UTC 
Created attachment 81163 [details] [review]
Suggested patch

Like this?
Comment 8 Sven Neumann 2007-01-26 22:10:33 UTC 
Looks good and compiles without warnings on Linux. Please commit.
Comment 9 Tor Lillqvist 2007-01-27 01:51:34 UTC 
Committed to trunk. Should we do this in the stable branch, too?
Comment 10 Sven Neumann 2007-01-28 10:21:21 UTC 
It's IMO too much of a change for the stable branch.
Comment 11 Sven Neumann 2007-05-10 06:16:56 UTC 
*** Bug 435384 has been marked as a duplicate of this bug. ***
Comment 12 Sven Neumann 2007-05-31 18:20:49 UTC 
*** Bug 442420 has been marked as a duplicate of this bug. ***