Hi Bruce,

Bruce Burden wrote:

I created a 45MB jpg with GIMP a few years ago. Now, when I attempt to open the image, the file is successfully loaded, the first tile or so is shown, then GIMP crashes because:

45 MB!!! That's a big image.

bash-2.05b$ gimp
GLib-ERROR **: could not allocate 16384 bytes aborting...
gimp terminated: Abort trap
Now, I realize that this is a GLib error, but I am looking for pointers on why GLib is not able to allocate a few K of memory. On a maching with nearly 1GB of free memory, I would expect to be able to read a 45MB file (especially since I created the image with less memory!)

The 16K is likely to be the straw that broke the camel's back, the little bit of memory that pushed things over the top. Since glib contains all the memory allocation functions we use, a glib error would be the expected way for this kind of failure to happen.

If you have lots of memory, you might consider increasing your tile cache size (this figure corresponds to how much RAM the GIMP will use for image data before it starts writing it to disk). You might also check that the partition your home directory is in is not full, although IIRC that would be another issue.

Also, you might consider running top to see how much memory the GIMP takes up. With a 45M compressed file, the image in memory is likely to be bigger than 200M (depending on the compression settings you used), this will let you see what's happenning in terms of the GIMP's memory usage.

You might also try installing 2.0pre3 alongside your 1.2.5 installation, and test whether this bug has somehow been fixed during the last 3 years. You can install both versions alongside each other, so this will not affect your 1.2.5 installation in the slightest.

And while you're at it could I ask you to open a bugzilla report against this? While it is unlikely that we will ever have a 1.2.6 release, if the bug is still present in the 2.0 release, it is more likely to be fixed if there is a bugzilla report open against it.

Cheers, Dave.

Hmmm, I just did a dummy scan and made a 90MB tiff file. I opened it with the Gimp 1.2.5 and saved it as a jpeg in the best quality possible. Unfortunately, it resulted in a small 10MB file. But no problem to open it.

I am following up on my earlier post.

I increased the tiff file size to about 380MB by increasing the picture size and resolution. I then saved it as a jpg which resulted in a file size of 73MB. I closed the Gimp, re-opened it and opened the 73MB file. It was very slow on an 800MHz Duron with about 400MB RAM, but there were NO errors. The Tile Cache Size is set at 32MB

Tom

Hmmm, I just did a dummy scan and made a 90MB tiff file. I opened it with the Gimp 1.2.5 and saved it as a jpeg in the best quality possible. Unfortunately, it resulted in a small 10MB file. But no problem to open it.

Hi,

Bruce Burden writes:

And while you're at it could I ask you to open a bugzilla report against this?

Is there a reasonable way to provide more detail as to what GIMP is doing in a bug report? Reporting that GTK is failing when a 45MB jpg file is expanded to 500MB+ is perhaps a bit too generic. It would be nice to say it was in routine XXXX.

Sure, you can run gimp in gdb and provide a back-trace from the crash.

Sven

Bruce Burden wrote:

That is what I figured. Since I was able to create and manipulate the file to start with, I assume it is something that I changed. Problem is, I don't see that malloc() returns a useful error indication.

You could try running the gimp in valgrind - this should tell you if there is any funniness going on with malloc. It will also probably take all your ram (valgrind is essentially an x86 emulator that relaces the system libc with its own).

Is there a reasonable way to provide more detail as to what GIMP is doing in a bug report? Reporting that GTK is failing when a 45MB jpg file is expanded to 500MB+ is perhaps a bit too generic. It would be nice to say it was in routine XXXX.

It's actually not (that) unusual that the GIMP would take 500M of memory for a 45M jpeg. It appears that some other people have had trouble reproducing the problem, but perhaps that's because they didn't use version 1.2.3 to create the jpegs in question.

In any case, creating a bugzilla report is essential to getting the problem solved. I've already forgotten the actual symptoms of the problem that you reported in your original mail :)

Also, it would be nice if you would test this in the 2.0 pre-releases, since if it is not a problem there it is unlikely to be fixed in the 1.2 branch.

Hope this helps,
Dave.

Hi,

Dave Neary writes:

Is there a reasonable way to provide more detail as to what GIMP is doing in a bug report? Reporting that GTK is failing when a 45MB jpg file is expanded to 500MB+ is perhaps a bit too generic. It would be nice to say it was in routine XXXX.

It's actually not (that) unusual that the GIMP would take 500M of memory for a 45M jpeg.

Some plug-ins (for example PSD) are implemented quite badly and allocate a block of memory large enough to hold the full data of the uncompressed layer. But as far as I know, the JPEG plug-in does it the right way and only allocates relatively few memory. There could however very well be a bug in the implementation.

Sven