Bug 192629 - gimp does not want to open some images
gimp does not want to open some images
Product: Fedora
Classification: Fedora
Component: ufraw (Show other bugs)
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Nils Philippsen
David Lawrence
: Reopened
Depends On:
  Show dependency treegraph
Reported: 2006-05-21 20:00 EDT by Michal Jaegermann
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version: 0.9.1-1.fc5
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-04-25 11:47:45 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
a sample picture which gives an indigestion to gimp (907.60 KB, image/jpeg)
2006-05-21 20:00 EDT, Michal Jaegermann
no flags Details

  None (edit)
Description Michal Jaegermann 2006-05-21 20:00:31 EDT
Description of problem:

There are JPEG images where an attempt to open causes gimp just to sit
and spin wheels.  AFAICT 'file' has to report such image as
'JPEG image data, EXIF standard 2.2' and it needs to be over some size
(no idea what the real lower limit is but it seems to be somewhere between
half and one megabyte in size and probably closer to the higher number).
If EXIF header is dropped from a picture, or even when a picture does have
this header but it is small enough, then gimp does open it.  Otherwise
gimp sits there apparently spinning wheels and when killed from a terminal
one can see:

/usr/lib64/gimp/2.0/plug-ins/script-fu terminated: Interrupt
/usr/lib64/gimp/2.0/plug-ins/ufraw-gimp terminated: Interrupt
/usr/lib64/gimp/2.0/plug-ins/ufraw-gimp terminated: Interrupt

The last two lines do not show up if a picture was shown and gimp
is interrupted from a terminal.

I do not know if this problem is really x86_64 specific. I had no
issues opening a test picture on i386 machine but this was with
a different gimp version.

A test picture was produced from a bigger original and EXIF header
was "transferred" to it with a help of jhead.

Version-Release number of selected component (if applicable):

How reproducible:
It seem that always with a "right" picture.  At least I did not managed
do that even once is such circumstances.
Comment 1 Michal Jaegermann 2006-05-21 20:00:32 EDT
Created attachment 129789 [details]
a sample picture which gives an indigestion to gimp
Comment 2 Michal Jaegermann 2006-05-21 21:01:08 EDT
I realized that I can test something "close enough" on i386 machine.
Namely gimp-2.2.11-0.fc4.3.  This did open my test file without any
Comment 3 Nils Philippsen 2006-05-22 08:24:30 EDT
I couldn't reproduce this with gimp-2.2.11-0.fc5.3 on i386. Can you try it
without CPU specific accelerations, i.e. GIMP started with "gimp --no-cpu-accel"?
Comment 4 Michal Jaegermann 2006-05-22 22:55:51 EDT
> I couldn't reproduce this with gimp-2.2.11-0.fc5.3 on i386.

Not a real surprise.  Like I wrote - the bug seems to be x86_64,
or maybe more generally 64-bit, specific.

> Can you try it without CPU specific accelerations, i.e. GIMP
> started with "gimp --no-cpu-accel"?

Does not change anything.  Likewise removing thumbnail from an EXIF
header and I thought at some moment that the problem is in
thumbnails handling.  "Bare" EXIF header turns out to be enough
to trigger the problem (with a file "big enough").

Looking at process table one can see that gimp spawned two

/usr/lib64/gimp/2.0/plug-ins/script-fu -gimp 8 7 -run 0
/usr/lib64/gimp/2.0/plug-ins/ufraw-gimp -gimp 10 8 -run 0

Attaching strace to the second one shows that it quickly loops
read(7, "", 4096)                       = 0
read(7, "", 4096)                       = 0
read(7, "", 4096)                       = 0
read(7, "", 4096)                       = 0
read(7, "", 4096)                       = 0

and so on.  The first one just sits in

select(1024, [8], NULL, NULL, NULL ....

but this is OK.  It likely waits from some data on a pipe but they
will be not coming.
Comment 5 Michal Jaegermann 2006-05-23 02:11:49 EDT
OK, I started digging closer and the bug is not really in gimp
but in 'ufraw' from extras.  If 'ufraw' package is installed
then gimp behaves like described.  Without it gimp does open the
test file without any problems.

After some mucking around with gdb I got the following backtrace:

#0  parse_makernote () at dcraw.c:3343
#1  0x000000000044364f in parse_exif (base=12) at dcraw.c:3486
#2  0x00000000004463ab in parse_tiff_ifd (base=12, level=0) at dcraw.c:3618
#3  0x0000000000447544 in parse_tiff (base=12) at dcraw.c:3764
#4  0x00000000004477c0 in parse_jpeg (offset=Variable "offset" is not available.
) at dcraw.c:4173
#5  0x00000000004487cb in identify (no_decode=0) at dcraw.c:4749
#6  0x0000000000412828 in dcraw_open (h=0x6735d0,
    filename=0x61fe70 "/home/michal/gimp_bug/gimp_no_open.jpg")
    at dcraw_api.c:89
#7  0x000000000040a7f6 in ufraw_open (
    filename=0x61fe70 "/home/michal/gimp_bug/gimp_no_open.jpg")
    at ufraw_ufraw.c:144
#8  0x000000000040879b in run (name=Variable "name" is not available.
) at ufraw-gimp.c:153
#9  0x00000036bd110bf2 in gimp_main () from /usr/lib64/libgimp-2.0.so.0
#10 0x00000036b861cf34 in __libc_start_main () from /lib64/libc.so.6
#11 0x0000000000408249 in _start ()
#12 0x00007fffffe05438 in ?? ()
#13 0x0000000000000000 in ?? ()

And here is the offending code:

(gdb) f 0
#0  parse_makernote () at dcraw.c:3343
3343          while ((c = fgetc(ifp)))

If we will ever get EOF from fgetc then we have an infinite loop
on line 3343 and the next one.  That is exactly what happens.

While the following patch:

--- ufraw-0.6/dcraw.c~  2005-11-13 09:47:56.000000000 -0700
+++ ufraw-0.6/dcraw.c   2006-05-22 23:22:41.000000000 -0600
@@ -3340,7 +3340,7 @@ void CLASS parse_makernote()
       if (tag == 0x1c) tag = 0x1017;
     if (tag == 0x1d)
-      while ((c = fgetc(ifp)))
+      while ((c = fgetc(ifp)) && c != EOF)
        serial = serial*10 + (isdigit(c) ? c - '0' : c % 10);
     if (tag == 0x81)  { /* NTC UF*/
       tone_mode_offset = ftell(ifp);

makes my test file to load without any problems there is a lot
of unchecked fgetc() calls in dcraw.c. It seems that in many
places we are for a serious "fun" if we will ever get EOF
there and things may get even more interesting on 64-bit
platforms.  This is not a full list but in dcraw.c lines 1025,
1792, 1944, 1949, 2026, 4147 look at least suspicious.

Niels, you seem to "own" both gimp and ufraw so I will leave
a component reassignment to your discretion.
Comment 6 Michal Jaegermann 2006-05-23 02:24:07 EDT
On the second thought - because the problem clearly depends on a size
of a file, and I am getting it consistently with many files, then
probably earlier there is some other bug and in "right" circumstances
we are not reading from intended locations.  That may be 64-bit specific.
Still assuming that we will always get something reasonable, even if
data were corrupted (deliberately or not), looks like a dangerous game.
Comment 7 Michal Jaegermann 2006-05-23 13:07:22 EDT
My suspicions about ufraw code got confirmed pretty quickly.
Here is another "interesting" loop in dcraw.c.  I hit it while
trying to load a test file produced by doing 'jhead -dt ...'
("drop thumbnail") on a test file attached to this report.

Here is the code from dcraw.c

3397        if (tag == 0xe01) {         /* Nikon Capture Note */
3398          type = order;
3399          order = 0x4949;
3400          fseek (ifp, 22, SEEK_CUR);
3401          for (offset=22; offset+22 < len; offset += 22+i) {
3402            tag = get4();
3403            fseek (ifp, 14, SEEK_CUR);
3404            i = get4()-4;
3405            if (tag == 0x76a43207) flip = get2();
3406            else fseek (ifp, i, SEEK_CUR);
3407          }
3408          order = type;
3409        }

While we are hitting it in the first place I am not sure
but on line 3402 'tag' is set to 0xffffffff and two lines below
'i' to 0xfffffffb.  After that we are off on a wild goose chase
in an enclosing loop.

Why gimp is trying to get ufraw to parse a file in the first place
I am not sure.  Clearly it is not necessary as uninstalling 'ufraw'
hides the problem.  So maybe this is a gimp bug in the first place?

The following patch makes my next test file to load while still
not breaking the first one :-)

--- ufraw-0.6/dcraw.c~  2006-05-23 10:16:45.000000000 -0600
+++ ufraw-0.6/dcraw.c   2006-05-23 10:55:25.000000000 -0600
@@ -3400,6 +3400,8 @@ void CLASS parse_makernote()
       fseek (ifp, 22, SEEK_CUR);
       for (offset=22; offset+22 < len; offset += 22+i) {
        tag = get4();
+       if (tag == 0xffffffff)
+         goto quit;
        fseek (ifp, 14, SEEK_CUR);
        i = get4()-4;
        if (tag == 0x76a43207) flip = get2();

but this obviously just papers over the issues.
Comment 8 Nils Philippsen 2007-02-08 06:50:16 EST
Hi Michal,

I've just tried this with a recent version on FC6 and the attached file opens fine:

[nils@dingo ~]$ rpm -q gimp
[nils@dingo ~]$ rpm -q gimp --qf '%{arch}\n'

This version is also available for FC5 (if you still use that), so I'll close
the bug for now. If that doesn't fix it, please reopen the bug.
Comment 9 Michal Jaegermann 2007-02-08 12:43:04 EST
Like I wrote in comment #5 and comment #7 this is not really gimp which
is at fault but ufraw plugin from extras.  The one for FC5 did not
change from 2006-02-17 and regardless of a version of gimp is affected
by the same bugs.  With ufraw plugin loaded I see what is described
in the report and that gimp-2.2.13 is in use is immaterial.
No ufraw then no problem.

Again - a gimp issue here is that it lets ufraw to do a superfluous
file parsing.

A version of ufraw for FC6 is 0.9.1-1 from 2006-08-29.  I will be
able to check it only later and I will put a separate note.
Comment 10 Michal Jaegermann 2007-02-08 20:24:50 EST
The same version of gimp with ufraw-0.9.1-1 from FC6 version of
extras opens the same pictures which give an indigestion to
ufraw from FC5.  If anything else will not wedge it I cannot tell
but at this moment I do not have examples. :-)

So yes, FC5 setup is still broken like it was in May of 2006
(and fixing it is quite trivial).
Comment 11 Nils Philippsen 2007-02-09 04:29:04 EST
ufraw-0.9.1 is building right now for FC5
Comment 12 Nils Philippsen 2007-02-09 04:31:42 EST
scratch that, the build system doesn't seem to want to build right now:

/usr/bin/plague-client build ufraw ufraw-0_9_1-1_fc5 fc5
Package ufraw enqueued.  (However, no Job ID was provided in the time required)

I'll retry later.
Comment 13 Nils Philippsen 2007-04-25 03:59:53 EDT
Sorry for being dormant ;-). Have you had any luck with the new ufraw package?
Comment 14 Michal Jaegermann 2007-04-25 11:47:45 EDT
At least my sample pictures which were tripping gimp via ufraw in
the past load without problems with ufraw-0.9.1-1.fc5 installed.
OTOH ufraw is at 0.11 by this time. :-)
Comment 15 Nils Philippsen 2007-04-25 12:32:51 EDT
Well, if you'd agree testing the 0.11 packages with a split off -common
subpackage and whether updates run smoothly enough, I'm willing to put one
through Extras ;-).
Comment 16 Michal Jaegermann 2007-04-25 12:45:47 EDT
> Well, if you'd agree testing ...
Yes, I can sick this package on various pictures I have here.
Comment 17 Nils Philippsen 2007-04-25 12:48:41 EDT
I was more interested in you testing that the update from the unsplit to the
split package works ;-). If you're still interested, I could check in the
necessary changes to CVS and you could do a _local_ build (perhaps tick down the
release to "0.1%{?dist}" beforehands) and test that as I don't know a means to
build packages but not push them to the repos.

Note You need to log in before you can comment on or make changes to this bug.