Version: 1.3.0 (using KDE 3.4.91 (beta1, >= 20050910), Gentoo) Compiler: gcc version 3.3.6 (Gentoo 3.3.6, ssp-3.3.6-1.0, pie-8.7.8) OS: Linux (i686) release 2.6.12-gentoo-r6 Viewing a certain image immediately crashes Gwenview (1.3.0). The backtrace doesn't reveal much: Using host libthread_db library "/lib/libthread_db.so.1". `system-supplied DSO at 0xffffe000' has disappeared; keeping its symbols. [Thread debugging using libthread_db enabled] [New Thread -1209702736 (LWP 2894)] [KCrash handler] #4 0x4bf6f4d5 in exif_get_short () from /usr/lib/libexif.so.9 #5 0x4bf67639 in exif_data_new_from_data () from /usr/lib/libexif.so.9 #6 0x4c1c33dc in ?? () #7 0x00000001 in ?? () #8 0x08397c00 in ?? () #9 0x0000fbe4 in ?? () #10 0x0000fbd0 in ?? () #11 0x08397bf8 in ?? () #12 0x4bf77318 in ?? () from /usr/lib/libexif.so.9 #13 0x082e25f8 in ?? () #14 0x083937e0 in ?? () #15 0xb6b50f7a in ?? () #16 0x4bf673b4 in exif_content_add_entry () from /usr/lib/libexif.so.9 #17 0x083937e0 in ?? () #18 0x00000000 in ?? () #19 0x00000000 in ?? () #20 0x4bf77318 in ?? () from /usr/lib/libexif.so.9 #21 0x00113b13 in ?? () #22 0x956793b6 in ?? () #23 0x00000003 in ?? () Other than the fact that the crash is probably related to exif. Why does Gwenview have to crash just because a library does? /usr/kde/3.5/bin/exif.py also crashes on the file: Traceback (most recent call last): File "/usr/kde/3.5/bin/exif.py", line 1065, in ? data=process_file(file, 1) File "/usr/kde/3.5/bin/exif.py", line 999, in process_file hdr.dump_IFD(exif_off.values[0], 'EXIF') File "/usr/kde/3.5/bin/exif.py", line 786, in dump_IFD printable=str(values[0]) IndexError: list index out of range
Sorry, but this bugreport is completely useless without that "certain image". > Why does Gwenview have to crash just because a library does? Because that's the way it is.
>Sorry, but this bugreport is completely useless without that "certain image". I'll attach it. > > Why does Gwenview have to crash just because a library does? > Because that's the way it is. I was trying to come come up with a sarcastic answer to your completely useless answer... But I suppose I'd better not. I know this isn't a support forum, but I asked because I sincerely want to know. If you don't know either, just say so.
Created attachment 12833 [details] Img with faulty exif
> > > Why does Gwenview have to crash just because a library does? > > Because that's the way it is. > I was trying to come come up with a sarcastic answer to your completely > useless answer... But I suppose I'd better not. > I know this isn't a support forum, but I asked because I sincerely want to > know. If you don't know either, just say so. If a call to a library function causes a crash, the program which called the library function will crash too, because they are the same process (not that this does not mean all instances of the program will crash). This is not specific to Gwenview.
Thank you Aurelien, that makes sense.
btw I can open your image without problems here
Re: comment 6: That's interesting. I still get the crash mentioned. If I open the attachment from this page directly in Gwenview, the image loads and when it's finished -- crash. That behaviour again leads me to believe that exif is the culprit: Gwenview only crashes when it reaches the end of the file. However, I suppose we should really be looking at /usr/kde/3.5/bin/exif.py not Gwenview. Also: Konqueror in file manager mode doesn't show metadata/exif in properties for this file.
I suppose we're using different kde and exif versions. Can you add those information?
I'm using KDE 3.5_beta1 and libexif 0.5.12. I still think it's important that exif.py crashes. Could the image possibly have been changed during upload/download? Mine has an MD5 sum of 10f7eea517ef83db1541c2eddeccf688. I've just found out that "ldd gwenview" shows connections to my old KDE 3.4. I'm not much of a programmer, but that certainly looks like a possible source of error to me. I'll clean things up and let you know how it goes.
I removed my KDE 3.4.2 and re-emerged (installed) libkipi, kipi-plugins, libexif and gwenview. I still get the exact same crash. What else can I do to help?
The image has not changed (I checked the md5sum) and it loads correctly on my machine. You are using an old version of libexif (0.5.12, latest is 0.6.12, my machine is using 0.6.9), so I suggest you upgrade it. The fact that both exif.py and libexif crash make me believe that the EXIF information in this file is not standard. I guess the latest version has a better handling of non-standard EXIF. Just to clarify: exif.py is not a part of libexif. It's a standalone EXIF reader and is distributed by KDE.
mine is 0.6.11.
I should have thought about the libexif version... But alas, I updated to 0.6.12 and the crash is the same as ever. I understand about exif.py, but I find it curious that a faulty image can crash two separate programs. It doesn't seem reasonable to suggest that neither can parse a certain string of bytes without crashing. And only on my machine. Suggestions? It's pretty annoying that I can't browse around in my filesystem without risking a crash.
well exif.py seems to fail here as well So it's not a gwenview problem isn't it? I saved your image as "immagine.jpg": # exif.py tmp/immagine.jpg tmp/immagine.jpg: Intel format IFD 0 (Image) at offset 8: ImageDescription: (0x010E) ASCII= @ 146 Make: (0x010F) ASCII=NIKON @ 157 Model: (0x0110) ASCII=E775 @ 163 Orientation: (0x0112) Short=1 @ 54 XResolution: (0x011A) Ratio=300 @ 168 YResolution: (0x011B) Ratio=300 @ 176 ResolutionUnit: (0x0128) Short=Pixels/Inch @ 90 Software: (0x0131) ASCII=E775v1.4u @ 184 DateTime: (0x0132) ASCII=2004:06:18 09:03:02 @ 194 YCbCrPositioning: (0x0213) Short=2 @ 126 ExifOffset: (0x8769) Long=214 @ 138 EXIF SubIFD at offset 214: ExposureTime: (0x829A) Ratio=10/110 @ 576 FNumber: (0x829D) Ratio=32/10 @ 584 ExposureProgram: (0x8822) Short=Program Normal @ 248 ISOSpeedRatings: (0x8827) Short=100 @ 260 ExifVersion: (0x9000) Undefined=[48, 50, 49, 48] @ 272 DateTimeOriginal: (0x9003) ASCII=2004:06:18 09:03:02 @ 592 DateTimeDigitized: (0x9004) ASCII=2004:06:18 09:03:02 @ 612 ComponentsConfiguration: (0x9101) Undefined=YCbCr @ 308 CompressedBitsPerPixel: (0x9102) Ratio=3 @ 632 ExposureBiasValue: (0x9204) Signed Ratio=0/10 @ 640 MaxApertureValue: (0x9205) Ratio=35/10 @ 648 MeteringMode: (0x9207) Short=5 @ 356 LightSource: (0x9208) Short=Unknown @ 368 Flash: (0x9209) Short=No @ 380 FocalLength: (0x920A) Ratio=81/10 @ 656 MakerNote: (0x927C) Undefined=[] @ 664 UserComment: (0x9286) Undefined=[] @ 1338 FlashPixVersion: (0xA000) Undefined=[48, 49, 48, 48] @ 428 ColorSpace: (0xA001) Short=1 @ 440 ExifImageLength: (0xA003) Long=1600 @ 452 ExifImageWidth: (0xA002) Long=1200 @ 464 InteroperabilityOffset: (0xA005) Long=886 @ 476 FileSource: (0xA300) Undefined=Digital Camera @ 488 SceneType: (0xA301) Undefined=Directly Photographed @ 500 Traceback (most recent call last): File "/usr/bin/exif.py", line 1064, in ? data=process_file(file, 1) File "/usr/bin/exif.py", line 998, in process_file hdr.dump_IFD(exif_off.values[0], 'EXIF') File "/usr/bin/exif.py", line 786, in dump_IFD printable=str(values[0]) IndexError: list index out of range
Le Mardi 4 Octobre 2005 22:51, Niels a écrit : [bugs.kde.org quoted mail] Did you rebuild Gwenview after updating? Make sure Gwenview is not using its outdated/will-be-removed-soon copy of libexif (check the output of ./configure) Aurélien
It works! No, I hadn't updated Gwenview after updating libexif (my comment #13). I just did, and: no crash. Here's a grep for exif in the configure output: checking for libexif >= 0.5.12... yes checking LIBEXIF_CFLAGS... -I/usr/include/libexif checking LIBEXIF_LIBS... -lexif -lm fast creating src/libgvexif/Makefile I obviously don't know what it said in the previous configure. There's still the crash in exif.py to consider. Thank you Angelo and Aurélien for your help!
The bug was not in Gwenview after all, closing it.