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 74478 - Cannot handle swap size of near 2 Gig (swap leak?)
Cannot handle swap size of near 2 Gig (swap leak?)
Product: GIMP
Classification: Other
Component: General
Other Linux
: Normal normal
: 2.0
Assigned To: GIMP Bugs
: 142920 (view as bug list)
Depends on:
Reported: 2002-03-13 05:43 UTC by Kelly Price
Modified: 2005-01-13 01:57 UTC
See Also:
GNOME target: ---
GNOME version: ---

Description Kelly Price 2002-03-13 05:43:34 UTC
I'm working on large 300 dpi images for my comic strip, and found out that
Gimp likes to leak swap.  It tries to hit the 2 Gig filesize limitation,
and fails miserablly -- it complains that it can't fileseek a tile (number
22).  Strange.
Comment 1 Raphaël Quinet 2002-03-13 13:35:55 UTC
I cannot test this for the moment (I do not have 2 Gb free on any of
my disks ;-) but I assume that you are right.  The GIMP would need to
handle large files correctly in order for this to work, and it should
use 64-bit long integers for accessing the tiles in the swap file.  It
does not do that yet.
Comment 2 Sven Neumann 2002-05-26 23:48:28 UTC
As a first step, I've added AC_SYS_LARGEFILE to in the
HEAD branch so we get the correct defines for large file support.
Comment 3 Sven Neumann 2002-05-27 11:52:07 UTC
I had a closer look and I think that the use of AC_SYS_LARGEFILE
should be sufficient to make gimp handle swap files of > 2GB. The code
off_t all over the place and AC_SYS_LARGEFILE changes this to be a 64
bit integer. I'd appreciate if someone could verify that large swap
files work in current CVS (or gimp >= 1.3.6).
Comment 4 Sven Neumann 2002-06-12 18:45:48 UTC
Obviously off_t wasn't used everywhere. Changed in the HEAD branch:

2002-06-12  Sven Neumann  <>

 * app/base/tile-swap.c: use off_t to handle file offsets (#74478).
Comment 5 Sven Neumann 2002-08-26 18:03:41 UTC
This should be fixed in gimp-1.3.8. I'd appreciate if someone would
stress-test this a bit and report back so that we can close this
report (or fix any remaining issues).
Comment 6 Sven Neumann 2003-01-04 15:08:28 UTC
Finally come around to do some testign and there was still one
variable that needed conversion to off_t. Now large swap files are
handled correctly. I've tested with a swap file larger than 4 GB.

I don't think we should attempt to fix this in the GIMP-1.2 branch.

2003-01-04  Sven Neumann  <>

  * app/base/tile-swap.c (tile_swap_find_offset): use off_t to
  return the offset. Finally allows to handle swap files larger than
  2 GB (fixes bug #74478).
Comment 7 Sven Neumann 2003-01-09 11:15:24 UTC
*** Bug 102518 has been marked as a duplicate of this bug. ***
Comment 8 Sven Neumann 2004-05-21 17:50:34 UTC
*** Bug 142920 has been marked as a duplicate of this bug. ***
Comment 9 Jens Lorenz 2005-01-12 12:56:36 UTC
I have reopened this bug, because this does not work with Gimp on Win32. The
swap file grows until 2GB is reached and then it gives the error "Unable to seek
to tile location on disk: Invalid argument".

Steps to reproduce:
1. Create a new image with 30000x30000 pixels
2. Wait until the above error message is displayed
Comment 10 Sven Neumann 2005-01-13 00:27:31 UTC
You should probably file a bug report against MS windows for not being POSIX
compliant then. I suggest that if you need to use large swap that you get a real
operating system. Alternatively you could write up a patch against glib that
makes the newly added stdio wrappers deal with this. We will switch to g_open()
and friends for GIMP 2.4 so that's where this would have to be fixed. Please
file an enhancement request against GLib.
Comment 11 Manish Singh 2005-01-13 01:57:23 UTC
Possibly the problem is in MingW or cygwin or whatever is used to make the
windows builds. The configure script uses AC_SYS_LARGEFILE, which should pull
define _FILE_OFFSET_BITS=64. If the windows build environment doesn't support
this, it should be fixed.