I have a system with 4G of RAM and when I work with an image with lots of 800x600 layers, somewhere around 120, GIMP crashes. The error generated is.

GLib-ERROR **: gmem.c:165: failed to allocate 12400 bytes

Any tips on optimizing GIMP's memory use or do I just need more RAM?

Does anyone know if layers that have been merged/deleted are actually tossed or are they hanging around on a memory heap somewhere?

I should also mention that I'm seeing this when using Script-fu to generate a bunch of layers. The number of layers I can generate/manipulate seems to depend how much other stuff I'm doing within the script.

GnuTux

don't know if this will help you but,
i made an new folder i called "on-or-off"
in my user scripts folder as a test.
i put my Gimp-surfr.scm file in the on-or-off folder.
use Preferences and script-fu refresh
to turn on or off, turn off user stuff you don't use.
can do this for all user resources, brushes, gradients...,
except *user\plugins*
cutting memory requirements

I have a script to help you Make sure you get the latest (from sourceforge)

I think you suggestion 2) is counter-productive. The more RAM you use for the tile cache, the less RAM can be used by other apps... or by GIMP for things that don't go in the tile cache. So I would reduce the tile cache size... 3) I don't see why the HDD should be external. Ideally a second internal HDD should be used, or an external HDD only if there is a
very good link (but these HDD are usually removable, so may not be there when you start Gimp). Otherwise the standard location is also a good choice. GnuTux is on Linux and the Linux filesystems are a lot more efficient than those of the "popular platforms".

Make sure the Script disables the undo stack while it runs (ideally does most of its work in an invisible window with undo disabled).

Otherwise it's hard to tell what's happening without some system data. But I doubt that the problem is due to RAM exhaustion because there is virtual memory for this so unless you have no swap on your system or the swap is full (easy to check....) this kind of thing never happens. I would believe more in some memory block corruption that makes the glibc allocator trip. The underlying error may have been logged somewhere.

I just tried out the link to souceforge and I'm getting a page not found message. Just wanted to check that the script version I'm using is the latest one.

Thanks for all the responses. I tried adjusting the suggested options but nothing I do seems to make one bit of difference. It's almost like there is no paging/swapping going on. I disabled undo and it made no difference.

I've did some more testing and it turns out that I can manipulate many more layers using the devel version of GIMP 2.9.1 running in a VM than I can with GIMP 2.8.x running on my main system outside of the VM.

I have more fonts, patterns, gradient & scripts in 2.8 but not that many. I'm not convinced the extra resources are causing the issue. Yes.. 2.9.1 was much slower in the VM but I was able to generate 200 layers with no problem, whereas I always crashed just after 100 layers on GIMP 2.8.x.

I'm gonna try moving 2.9.1 out of the VM and and see if I can run it alongside 2.8.x. Just gotta make sure all the libs are available to 2.9.1.

I'm not sure what's going on here.

Well, I moved the .gimp-2.8 folder and let it create from scratch and it still crashes so there is not a GIMP resource issue. I couldn't run V2.9.1 that I copied over from the F20 VM. Looks like maybe a GTK version issue.

gimp-2.9: undefined symbol: g_type_add_instance_private

Indeed... this is a setting that covers most uses cases a priori, but in GnuTux' case that's still the wrong way to go IMHO.

Yes, I understood what you meant. Certainly, more hardware resources would improve my results. Currently, I have a 3.2ghz Quad core /w 4G Ram and tons of HD space. More RAM would certainly help but that doesn't explain why my results would be so much better using GIMP 2.9.1 in a small VM on the same machine.

I wanted a clean test so I allowed the .gimp-2.8 resource folder to be created from scratch, but it didn't help.

I guess it's time to move to F20 and dump the old F18 install, keeping F19 intact. I usually keep the last two versions of Fedora available so I guess that will be my next PC project.

It's all relative. I can run a simple script and create 500+ large layers on GIMP2.8 before it crashes & probably 1000+ layers on 2.9.1 in a small VM on the same box. The number of layers that I can get just depends on what else the script is doing and how large the layers are.

Considering the results I'm seeing with 2,.9.1 in a small VM on the same box, there must be a problem with 2.8.x on my machine and nothing that has been suggested so far has addressed the issue.

Any chance of a look at your script that's showing the problem?

When I was writing my "test for duplicate scripts" script in script-fu I was sometimes getting what looked like memory corruption within the script (variables containing the wrong contents) and found I had to restructure things a bit to build shorter lists etc.

Kevin

@Gnu Tux

Did you tried the first suggestion of K1TesseraEna ?
That for me , on my computer does a LOT of differences , especially in case of long session :

After 30 minutes ,max 1 hour , i check the work in progress, just to be sure that i will not need the Undo history, i save everything, and reopen

I think kept record of undo history require a lot of resources because at soon reloaded, with same images but purged from history is quite more responsive on heavy images.

And yes would be possible discard history without reloading...but after using many tools, script, plugin i prefer exit and reload, just in case one of the many filters or tools used during the session didn't released properly all the memory used ...

Yep, I did all that, PC. GIMP 2.8, for the most part, actually runs fine, until I start generating 100s & 100s of layers. That's when things get wonky. It's not something that I would normally do, anyway. I mean, I wouldn't normally create that large of an extrusion. I'm just testing the limits.


Well, as it turned it out, the problem was not script related so I've came back and edited this post to remove my initial response.

What would be nice tho, would be a good Script-Fu stress script, so we can compare the various GIMP versions and platforms.

I've had this same issue with gimp since I switched from 2.6 to 2.8. So for quite a while. Any images I work on that are larger, I run the risk of a big fat nope from gimp. I might not mind so much if it told me it couldn't manage somehow and gave me an option to save. But it sort of punches you with it and then runs off to shut down. There's nothing you can do to save your file at all. Once you see the dreaded error of memory allocation, you're already hosed.

I tried all the suggestions given here. more cache, less cache, color management off, etc. I've had gimp 2.8 on an xp machine and now on a vista, it was a windows 7 before. I can't necessarily increase my ram nilly-willy, got bills to pay before I get to buy new toys. I would appreciate nothing more than a revamp of the oops-we-screwed-up into an oops-we-screwed-up-here's-a-save instead.

You might be onto something, ek22. It might be an issue with V2.8, being I'm not seeing this problem in GIMP 2.9.1. I have a older box that's still running 2.6.x, so I should test it there as well. Off to try that right now..