Crash when preparing photo for import
Submitted by an unknown user
Link to original bug (#718171)
Description
---- Reported by shotwell-maint@gnome.bugs 2011-11-17 22:15:00 -0800 ----
Original Redmine bug id: 4407
Original URL: http://redmine.yorba.org/issues/4407
Searchable id: yorba-bug-4407
Original author: Timo Jyrinki
Original description:
Another crash. This only seems to happen when I enable the "watch" feature from preferences and Shotwell starts auto-importing. After a short while it crashes with the following trace:
Program received signal SIGFPE, Arithmetic exception.
[Switching to Thread 0xaf31cb70 (LWP 2803)]
0x08377f83 in ?? ()
(gdb) bt
#0 0x08377f83 in ?? ()
#1 0x0836ffa1 in LibRaw::identify() ()
#2 0x083484ee in LibRaw::open_datastream(LibRaw_abstract_datastream*) ()
#3 0x08348d3c in LibRaw::open_file(char const*, long long) ()
#4 0x0834e036 in libraw_open_file ()
#5 0x080fcfbd in graw_processor_open_file ()
#6 0x08103e46 in ?? ()
#7 0x080f0c57 in photo_file_sniffer_sniff ()
#8 0x080f195d in photo_file_interrogator_interrogate ()
#9 0x082283fc in photo_prepare_for_import ()
#10 0x08259403 in ?? ()
#11 0x080ba36f in background_job_execute ()
#12 0x080b8cf0 in ?? ()
#13 0x00ce5a27 in g_thread_pool_thread_proxy (data=0x91a0498)
at /build/buildd/glib2.0-2.30.0/./glib/gthreadpool.c:319
#14 0x00ce35f4 in g_thread_create_proxy (data=0x93fbbc0)
at /build/buildd/glib2.0-2.30.0/./glib/gthread.c:1962
#15 0x00ecad31 in start_thread () from /lib/i386-linux-gnu/libpthread.so.0
#16 0x00fb10ce in clone () from /lib/i386-linux-gnu/libc.so.6
Backtrace stopped: Not enough registers or memory available to unwind further
(gdb)
Using Ubuntu 11.10 and Shotwell 0.11.4. Note that this is a different machine and different photo collection than what I used in my other crash report 4379. I'm happy to try out patches or prepare better debug output if you tell me how (this is just with libglib + libgtk debug symbols installed).
And yes, the same crash also happens if I do a manual import. I don't know how to find out which specific file causes it.
---- Additional Comments From shotwell-maint@gnome.bugs 2013-05-01 11:38:00 -0700 ----
History
Comment 1
Updated by Timo Jyrinki about 2 years ago
- File P1010671.JPG added
Update. First of all, forget about the "This only seems to happen" part in the beginning of the report. As written in the last paragraph, I found out while writing the report that it indeed crashes also on manual import.
But more importantly, I found a file causing the crash. It's a corrupted JPG file. Shotwell should handle corrupted files as well as non-corrupted files without crashing. Please feel free to use all the 8192 bytes of it for your debugging purposes.
If someone has a patch at some point, I'll be glad to test it.
Comment 2
Updated by Adam Dingle about 2 years ago
- Priority changed from Normal to High
- Target version set to 0.12
Comment 3
Updated by Adam Dingle about 2 years ago
- Priority changed from High to Urgent
Comment 4
Updated by Clinton Rogers about 2 years ago
I dug into this a little last week; the crash is happening on LibRaw's side, although, presumably, we shouldn't even be getting this far. It might be better if the sniffer knew a bit more about when it could trivially reject certain corrupted files.
Comment 5
Updated by Adam Dingle about 2 years ago
I think it may be tricky for us to detect every photo which might crash libraw, so I'm not sure we should even try to do that. The best way to address this is to fix libraw. Do we know whether the crash occurs in the latest libraw?
Comment 6
Updated by Timo Jyrinki about 2 years ago
raw-identify from libraw 0.14.3 seems to crash on it still. Could you / should you report it upstream?
I wonder if it's in any way possible to catch such crashes without the whole shotwell crashing.
Comment 7
Updated by Adam Dingle about 2 years ago
OK - I've reported this to the libraw developers here:
http://www.libraw.org/node/1316
But, still: why is Shotwell passing this file to libraw at all, given that it has a .JPG extension? Clint, can you investigate and/or explain?
Comment 8
Updated by Adam Dingle about 2 years ago
- Assignee set to Clinton Rogers
Comment 9
Updated by Clinton Rogers about 2 years ago
A 'healthy' JPEG normally has its details detected by JfifSniffer (which, in turn, calls into GdkSniffer), so something about this particular file is somehow tricking Shotwell into thinking it is a RAW.
Given that the file is corrupted, is it possible that the filename is also somehow mangled? (This type of corruption could be triggered if something like an SD card were removed without syncing or unmounting first.) I already know that if I rename a .SRW to whatever.JPEG, Shotwell can still cope with it, initially trying with JfifSniffer, then when it fails, trying again with RawSniffer (at which point it succeeds).
Comment 10
Updated by Adam Dingle about 2 years ago
-
Assignee deleted (
_Clinton Rogers_) - Priority changed from Urgent to Normal
-
Target version deleted (
_0.12_)
Thanks for the investigation. This is really a libraw bug. It's debatable whether we should be passing this JPEG file to libraw at all from Shotwell. There are various changes we could make to cause Shotwell not to do that - for example, Shotwell could possibly look at the JPEG file's magic number and see that it's actually a JPEG despite the fact that the JfifSniffer has rejected it. But this is an edge case, so making any change here is not a high priority. The right path forward here is to fix this in libraw.
Comment 11
Updated by Timo Jyrinki almost 2 years ago
Hi. Thanks for the investigation so far.
A few data points still, though, related to earlier comments: it's not a mangled file name, it's a truncated JPG file. The 'file' utility correctly detects it as JPEG, so there is probably something more that could be done to prevent handing it over to libraw as well. (also, if you look at the file with less, you can see that there is even exif data and camera model info seen).
Comment 12
Updated by Jim Nelson 11 months ago
- Target version set to 0.14.0
Comment 13
Updated by Jim Nelson 11 months ago
- Category set to import
Comment 14
Updated by Jim Nelson 10 months ago
- Status changed from Open to 5
- Resolution set to fixed
This appears to be fixed. I've tried importing the file both manually and via auto-import and Shotwell catches the problem. Closing.
Comment 15
Updated by Charles Lindsay 7 months ago
- Status changed from 5 to Fixed
--- Bug imported by chaz@yorba.org 2013-11-25 21:55 UTC ---
This bug was previously known as bug 4407 at http://redmine.yorba.org/show_bug.cgi?id=4407 Imported an attachment (id=262238)
Unknown milestone "unknown in product shotwell. Setting to default milestone for this product, "---". Setting qa contact to the default for this product. This bug either had no qa contact or an invalid one.
Version: 0.14.0
Resolution: RESOLVED FIXED