Waiting for the attachment..... ;)

Uh, please do not attach the file if you expect some privacy.
The file would be visible for everyone at bugzilla.gnome.org...

Can you give a bit more details about the file? Number of layers,
total size (Mb), grayscale/color/etc, resolution. You might be able to
reproduce the crash by removing the artwork (just fill the layer with
any color). It's unlikely (although not impossible) that the psd
plug-in crashes on the contents of the image, unless the problem has
to do with the compression.

Created attachment 20071 [details]
Photoshop File causing crash

Sorry about that.  I uploaded the file straight after posting the bug
but it seems to have gone wrong somewhere.

I can't tell you much about the photoshop file other than I wouldn't
expect a lot of large images in it and that it should be a full color
document (but mostly the colors are grey, black and white.)

I tried loading the file with the current CVS version (as of yesterday)
and I had no problems.  I could also load it with 1.2.5.  I see a
1-layer RGB image looking like a web page.  No crash in the PSD plug-in.
Unless someone else can reproduce the crash, I suggest that you provide
more details about your system and (if possible) a stack trace of the
plug-in when it crashes.

Loads fine for me as well. We will need more info to investigate this.

My system is a RH-9 box (up to date in terms of updates).

It's running garnome-0.27.1 which is the gnome-2.4 release
GIMP is compiles under garnome and is version 1.3.20

What else do you need to know?

Well, since we cannot reproduce the problem, there is nothing we can
do. You could try to run the plug-in in a debugger and see if that
gets you any further.

The attached file is a jpg file, not a Photoshop file. Even Microsoft
Paint opens it ;) Please try to provide the original Photoshop file.
If you want to protect the artwork, just fill the layers with any
color and see if it still crashes.

Damn I'm stupid.  Yes I've uploaded the jpg of the psd file I've got.

I've just tried to upload the psd file, but it's not going through.

I'll try bzip2ing the file and see if I can upload it then.

I've just tried opening the file again and it's still crashing (no
surprise there as nothing's changed).

However, I'm getting this output on the command line (which might be
helpful):

[rodd@flathead tmp]$ gimp-1.3 3039_New_Site_Dev_5c.psd &
[1] 29202
[rodd@flathead tmp]$ This is a development version of the GIMP
Debug messages may appear here.
 
Testing CPU features...
  mmx     : yes
  3dnow   : yes
  mmxext  : yes
  sse     : yes
  sse2    : no
 
gimp_composite: use=yes, verbose=no +mmx +sse +3dnow
added locale domain "gimp20-script-fu" for path "(null)"
 
(psd:29482): LibGimp-CRITICAL **: file gimppixelrgn.c: line 89
(gimp_pixel_rgn_init): assertion `x >= 0 && x + width <=
drawable->width' failed
 
(psd:29482): LibGimp-CRITICAL **: file gimppixelrgn.c: line 467
(gimp_pixel_rgn_set_rect): assertion `x >= 0 && x + width <=
pr->drawable->width' failed
 
(psd:29482): LibGimp-CRITICAL **: file gimppixelrgn.c: line 89
(gimp_pixel_rgn_init): assertion `x >= 0 && x + width <=
drawable->width' failed
 
GLib-ERROR **: gmem.c:140: failed to allocate 1962985600 bytes
aborting...
 
(gimp-1.3:29202): Gimp-Plug-In-WARNING **: gimp-1.3: plug_in_flush():
error: Broken pipe
 
(gimp-1.3:29202): Gimp-Plug-In-WARNING **: plug_in_close: plug-in
aborted before sending its procedure return values

The output clearly indicates that the pixel region handling in the PSD
plug-in needs to be fixed. Shouldn't be hard to debug this using gdb
and the 'fatal-warnings' features as described in
devel-docs/debug-plug-ins.txt.

Rodd, can you enable the debug information in the Photoshop plug-in
and try to load your file again? This will give you lots of additional
output which could help us.

To enable debug: change "#define PSD_DEBUG FALSE" to "define PSD_DEBUG
TRUE" on line 142 in the file gimp/plug-ins/common/psd.c and recompile
+ install again.

The memory problem (gmem.c:140: failed to allocate 1962985600 bytes)
suggests that either your file is really huge, or some kind of range
overflow/underflow in the width and/or height of the image. My guess
is that width somehow becomes negative.

We really need operating systems that can allocate 2 Terrabyte of data ;)

Before everything else, we should fix the code that accesses
GimpPixelRegions out of bounds. Btw, 1962985600 bytes are approx. 2
gigabyes which is a reasonable number for a _very_ large image.

Oops! Yes, gigabytes, no terrabytes. Unlikely that Gimp will be able
to allocate an extra 2 gig, tho.

Created attachment 20303 [details]
Output after enabling DEBUG in psd.c

I've attached the output after enabling DEBUG in psd.c

The file was huge (1277422 bytes) so I've compressed is with bzip2. 
Hope that's okay.

The output was gathered using 'gimp-1.3 > /tmp/gimp.output 2>&1'

Thanks for the output. I suspect this is the same problem as in
http://bugzilla.gnome.org/show_bug.cgi?id=123321. Somehow a layer with
width and height equal to zero is loaded. My guess is that this used
to work in Gimp 1.2.x. Could you please try to load your file with
1.2.x and tell us what happens?

Loads fine in gimp-1.2.

I had a quick (unqualified look) at the layers, but couldn't see any
layer that stood out as wrong.  All the layers seemed to have physical
size atleast.

I think Gimp-1.2 silently ignores layers with width and height both
set to zero. In Gimp-1.3.x this triggers an assert. This can easily be
fixed by checking width and height before calling gimp_pixel_rgn_init,
but I still don't understand where these zero-dimensioned layers come
from. We seem to have the same problem with one of the layers in the
file that comes with http://bugzilla.gnome.org/show_bug.cgi?id=123321.

This should be looked at before 2.0.

In the long run the PSD plug-in should be improved so that it doesn't
allocate memory for the whole drawable. A stripe of image-width *
tile-height should be sufficient.

Sven's right.  The scanline-at-a-time thing would a nice simple
beginner's project for anyone wanting to 'get into' GIMP coding -- it
doesn't require any PSD knowledge or even very much libgimp knowledge,
just some legwork.

I won't be able to work on this one (not for a long time), for my
usual whiny reasons (no GIMP build system, no time).  Can't pull a
'blind patch' like I sometimes do because this is a bit too invasive
to test without a build.

I don't see from the debugging output how the layer differs from the
one preceding it, except that the drawable returned from
gimp_drawable_get(layer_ID) has 0/0/0 width/height/bpp.  I don't
immediately see that we /asked/ for such a dimension for this layer,
and doubt that GIMP would have created such without an assertion, so I
assume the bad-dim'd returned drawable is simply symptomatic of an
out-of-memory condition.

Out-of-memory is unlikely since all memory is allocated using g_malloc(). 
g_malloc() never fails. It prefers to call exit() in case the memory
can't be allocated,

Well I'm stumped then (without looking somewhat deeper :)).  Because
that 0x0x0 is clearly wrong, but those values are straight off the
drawable returned by gimp_drawable_get(layer_ID).  (All of this is
based on what I remember of the psd plugin in 1.2.x -- I'm not really
familiar with any changes that have gone into the plugin in 1.3.x)

"YAH5 - merged_data=0x806cbf8, drawable=0x805cff0, drawdim=0x0x0"

From the (gimp 1.2.x) plugin source:

          drawable = gimp_drawable_get (layer_ID);          
          IFDBG
            fprintf(stderr, "YAH5 - merged_data=%p, drawable=%p,
drawdim=%dx%dx%d\n",
                    merged_data,
                    drawable,
                    drawable->width,
                    drawable->height,
                    drawable->bpp);

I don't think we CREATED a 0x0x0 drawable but the chances seem very
slim that any version of GIMP would have not asserted all over the
place if we did, especially the 0-bpp thing.  But a 0x0x0 drawable is
what we're getting back.  I might be misunderstanding/misremembering
the libgimp API and we're accidentally passing a bad layer_id or
something, and this is expected behaviour?  But I expect that we just
get back a NULL drawable from the gimp_drawable_get() call, not a
valid drawable with invalid dimensions.

If you pass an invalid drawable_ID to gimp_drawable_get() you will get
exactly that, a valid drawable with width, height, bpp set to 0. Perhaps 
this should be changed.

I see.  That's interesting.

Some of these layers have non-utf8 layer names... just as a data-point.

... so, the untested patch attached to bug 123321 might help.

The file apparently had the same problems as the
attachments of bug #123321.

It opens fine with current CVS.


*** This bug has been marked as a duplicate of 123321 ***