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): gimp-2.2.11-0.fc5.3 How reproducible: It seem that always with a "right" picture. At least I did not managed do that even once is such circumstances.
Created attachment 129789 [details] a sample picture which gives an indigestion to gimp
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 problems.
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"?
> 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 children: /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 doing ...... 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.
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.
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.
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.
Hi Michal, I've just tried this with a recent version on FC6 and the attached file opens fine: [nils@dingo ~]$ rpm -q gimp gimp-2.2.13-1.fc6 [nils@dingo ~]$ rpm -q gimp --qf '%{arch}\n' x86_64 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.
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.
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).
ufraw-0.9.1 is building right now for FC5
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.
Sorry for being dormant ;-). Have you had any luck with the new ufraw package?
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. :-)
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 ;-).
> Well, if you'd agree testing ... Yes, I can sick this package on various pictures I have here.
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.