I have compiled Gimp 1.2.3 with -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 and it can see files over 2GB ok, but if I create a new image that is over say 3GB then the swap file fills up until gets to 2GB and then stops. Gimp then starts to use up the rest of physical memory until the kernel jumps in and then sends it to its rest. Is there a variable in the source that I can increase to make the swap file bigger?

Michael

Sven Neumann wrote:

Hi,

Michael writes:

I have compiled Gimp 1.2.3 with -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 and it can see files over 2GB ok, but if I create a new image that is over say 3GB then the swap file fills up until gets to 2GB and then stops. Gimp then starts to use up the rest of physical memory until the kernel jumps in and then sends it to its rest.
Is there a variable in the source that I can increase to make the swap file bigger?

there are several places that need to be tweaked. I have done a couple of changes in the 1.3 development tree that should allow to use large swap files as well as large tile cache sizes. These changes haven't yet seen much testing however. I'd appreciate your feedback if you want to give it a try.

Salut, Sven

Hello again,

I have compiled the 1.3.8 release after finally getting hold of the required files (I only have a modem so they were a bit big for me) and grepped the resulting binaries to check that fopen64 was there. If I set the image size to 65536 x 65536 the file size indocator says 0 kb, after messing with the sizes a bit more it seems that the indicator wraps around at 4096 MB. If I then open a file it seems that this version does things the other way and fills up the memory first and then attacks the kernel's swapfile so I couldn't check Gimps swap file because it didn't seem to create one before the kernel killed it. I must say that I was impressed at the speed at which the Gimp filled up the memory it was very fast.

Michael.

Hello,

Sven Neumann wrote:
> Hi,
>
> Michael writes:
>
>
>>I have compiled the 1.3.8 release after finally getting hold of the >>required files (I only have a modem so they were a bit big for me) and >>grepped the resulting binaries to check that fopen64 was there. If I >>set the image size to 65536 x 65536 the file size indocator says 0 kb, >
>
> hmm, that's a bug in the user interface. Could you file a bug-report > for it, please ?
>
I'm not actually running Gnome 2, I only have the libraries required to compile Gimp 1.3. Should I then just be filing the report against gtk+2? >
>>after messing with the sizes a bit more it seems that the indicator >>wraps around at 4096 MB. If I then open a file it seems that this >>version does things the other way and fills up the memory first and >>then attacks the kernel's swapfile so I couldn't check Gimps swap file >>because it didn't seem to create one before the kernel killed it. I >>must say that I was impressed at the speed at which the Gimp filled up >>the memory it was very fast.
>
>
> hmm, we didn't do any significant changes to the way GIMP handles the > tile cache so it should actually behave just like GIMP-1.2. The only > difference should be that it should now be possible to use a cache of > size > 2GB and that the core should be able to deal with swap files > larger than 2GB. I say "should" since these changes haven't seen much > testing yet.
>
Yes they do look the same. I have added some g_print() statements in the code and the config file is being parsed for the temp file location but the value is being lost somewhere. Can you suggest any good places to put some g_prints to see what is going on? Here is some sample output:-

[root@mike bin]# ./gimp-1.3 using MMX: yes
swapfile is: /big/tmp/gimpswap.30852 swap add filename: /big/tmp/gimpswap.30852/n[Invalid UTF-8] swapfile is still: (¹g@(¹g@/gimpswap.30852

so it is being parsed ok if, you ignore my errors, but there is no error to say why the file is not being created in the suggested location.

> > Salut, Sven
>
>

Michael.

p.s. if I turn on conservative memory usage then it does create a few smaller temp files, but still no big one.

>[root@mike bin]# ./gimp-1.3
>using MMX: yes
>swapfile is: /big/tmp/gimpswap.30852 >swap add filename: /big/tmp/gimpswap.30852/n[Invalid UTF-8] >swapfile is still: (¹g@(¹g@/gimpswap.30852

I was just looking at the above text and suddenly realised that the path had turned to garbage in the third g_print line which I had put into base.c like this:-

void
base_init (void)
{
gchar *swapfile;
gchar *path;

#ifdef HAVE_ASM_MMX use_mmx = use_mmx && (intel_cpu_features() & (1 << 23)) ? 1 : 0; g_print ("using MMX: %s\n", use_mmx ? "yes" : "no"); #endif

toast_old_temp_files ();

/* Add the swap file */ if (base_config->swap_path == NULL) base_config->swap_path = g_strdup (g_get_tmp_dir ());

swapfile = g_strdup_printf ("gimpswap.%lu", (unsigned long) getpid ());

path = g_build_filename (base_config->swap_path, swapfile, NULL);

g_print ("swapfile is: %s\n", path);

g_free (swapfile);

tile_swap_add (path, NULL, NULL);

g_free (path);

paint_funcs_setup ();

g_print ("swapfile is still: %s\n", path); }

so for some reason the path is being messed up in the lines between my two added g_prints. Any advice?

Michael.

p.s. Just did a bit more testing and found that if I change the path to /tmp the I get this:-

swapfile is: /tmp/gimpswap.32180 swap add filename: /tmp/gimpswap.32180/n[Invalid UTF-8] swapfile is still: (¹g@(¹g@pswap.32180

so it looks like that corruption eats into the path at some point during initialisation.