GNOME Bugzilla – Bug 522149
Crashes when writing EXIF information to file
Last modified: 2018-07-01 09:01:08 UTC
Steps to reproduce: 1. start f-spot Stack trace: Other information: Ubuntu 7.10 - Gutsy terminal error message: ================================================================= Got a SIGSEGV while executing native code. This usually indicates a fatal error in the mono runtime or one of the native libraries used by your application. =================================================================
f-spot version? installed from where? you didn't provide any information to investigate this problem. please run f-spot --debug from command line, and post SOME lines of output (from bash to bash).
Created attachment 107267 [details] Debug info from terminal f-spot 0.4.0
Comment on attachment 107267 [details] Debug info from terminal Sorry I am new to reporting issues. attached is the debug info you requested. I am using: f-spot 0.4.0-0ubuntu3 from the package manager in Ubuntu 7.10
i can also say that it was working fine until i added a new folder of scanned images, the folders contain .tif, .jpg, .psd, .pnm and .db (left over form windows) files.
i'm not sure, but can you send me or attach here this picture? looks like f-spot cannot write metadata information to this file. file:///media/sdb1_wd2500/Art/My Art/Photography/08.13.05 loatis land and other stuff/P8130869.JPG
could you please confirm if this happen (or not) with "Write metadata to file" disabled. I ff-spot crash at startup, change that option using the gconf-editor (the key is /apps/f-spot/metadata/embed_in_image)
Maxxer: I took the requested file out of my folder, while doing so, i realized there were a ton of strange text files with the same names as my images, but with characters after them. i deleted the file giving the problem, and all of the strange files made and it happened again with this image that i've zipped. also in this zip is the strange file that is created. each time i run f-spot, it hangs up on this image and creates a new file with different characters at the end. http://teamtreetops.com/files/fspot_picture_files.zip Stephane: as for your suggestion, i am sorry but i can't find these folders, or the file anywhere, i even did a search with catfish, no luck.
*update* i took that whole folder out of my watch folders and i no longer have an issue with it crashing. I think you were right Maxxer, something happened to those photos that f-spot didn't like, because they were visible in f-spot for a time, hopefully you will be able to see what went wrong from that image i sent you.
Stephane told you to disable that gconf key, it's not a file! :) Anyway that wouldn't help, because I also tried, if there are syncjobs in queue they will be worked even if the flag is set to off. Confirmed, the problem is when f-spot tries to write exif data to file. If it can be of help F-Spot throws this out when opening the file: open uri = file:///home/maxxer/work/fspot/bin/Photos/2005/07/09/P7090815.JPG FSpot.Tiff.ParseException: Invalid charset name: at FSpot.Tiff.UserComment..ctor (System.Byte[] raw_data, Boolean little) [0x00000] at FSpot.Tiff.DirectoryEntry.get_UserCommentValue () [0x00000] at FSpot.Tiff.DirectoryEntry.get_ValueAsString () [0x00000] at FSpot.Tiff.Header.SelectDirectory (FSpot.Tiff.ImageDirectory dir, StatementSink sink) [0x00000] at FSpot.Tiff.Header.SelectDirectory (FSpot.Tiff.ImageDirectory dir, StatementSink sink) [0x00000]
thanks for the help guys, i'm just glad to have it working again. Hopefully the developers can work the issue out, let me know if you need anything more. I will leave the file up for download to anyone who wants to mess with it.
can't reproduce this bug
Seems like a libexif bug, happening also when issuing the following command: exif --ifd=EXIF --tag 0x9003 --set-value='2007:09:17 09:30:55' P7090815.JPG I've submitted the bug upstream to libexif: https://sourceforge.net/tracker/index.php?func=detail&aid=1918227&group_id=12272&atid=112272 Gomez, please don't delete the file from the server so the libexif team can download it for checking. Thanks.
*** Bug 471713 has been marked as a duplicate of this bug. ***
This was already fixed in libexif CVS. Maxxer, perhaps you could confirm this and deal with the sourceforge bug report?
(In reply to comment #14) > This was already fixed in libexif CVS. Maxxer, perhaps you could confirm this > and deal with the sourceforge bug report? How do you say this has been fixed in cvs? We left this bug open in order to let people better find this bug, even if it's not strictly F-Spot related.
Well, I recompiled libexif with debugging symbols, used the testcase from comment #12, obtained a backtrace, saw that it was a problem in exif-mnote-data-olympus.c, went to browse libexif CVS and found two likely-looking patches: http://libexif.cvs.sourceforge.net/libexif/libexif/libexif/olympus/exif-mnote-data-olympus.c?r1=1.30&r2=1.31 http://libexif.cvs.sourceforge.net/libexif/libexif/libexif/olympus/exif-mnote-data-olympus.c?r1=1.32&r2=1.33 Rebuilding libexif with these patches led to both exif and f-spot working fine with the testcase. I haven't found out how long it will be until the next libexif release, though - there are various other fixes sitting in there. As for the bug status, I don't mind too much, but I doubt leaving this open is going to stop people filing duplicates of it. :/
Tim (comment #16), thx for the research. Yeah, leave the bug open.
Reopening. :)
f-spot is not under active development anymore, has not seen code changes for five years, and saw its last tarball release in the year 2010. Its codebase has been archived: https://gitlab.gnome.org/Archive/f-spot/commits/master Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect reality. Please feel free to reopen this ticket (or rather transfer the project to GNOME Gitlab, as GNOME Bugzilla is deprecated) if anyone takes the responsibility for active development again.