After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 522149 - Crashes when writing EXIF information to file
Crashes when writing EXIF information to file
Status: RESOLVED WONTFIX
Product: f-spot
Classification: Other
Component: General
0.4.x
Other All
: Normal normal
: ---
Assigned To: F-spot maintainers
F-spot maintainers
gnome[unmaintained]
: 471713 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2008-03-13 01:56 UTC by Gomez
Modified: 2018-07-01 09:01 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Debug info from terminal (12.42 KB, text/plain)
2008-03-14 05:19 UTC, Gomez
Details

Description Gomez 2008-03-13 01:56:29 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.
=================================================================
Comment 1 Maxxer 2008-03-13 06:43:35 UTC
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).
Comment 2 Gomez 2008-03-14 05:19:25 UTC
Created attachment 107267 [details]
Debug info from terminal 

f-spot 0.4.0
Comment 3 Gomez 2008-03-14 05:21:55 UTC
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
Comment 4 Gomez 2008-03-14 05:25:15 UTC
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. 
Comment 5 Maxxer 2008-03-14 07:51:16 UTC
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

Comment 6 Stephane Delcroix 2008-03-14 09:22:45 UTC
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)
Comment 7 Gomez 2008-03-14 23:15:51 UTC
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. 
Comment 8 Gomez 2008-03-15 00:09:02 UTC
*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. 
Comment 9 Maxxer 2008-03-15 08:25:57 UTC
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] 
Comment 10 Gomez 2008-03-15 17:07:12 UTC
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.
Comment 11 Stephane Delcroix 2008-03-17 10:25:37 UTC
can't reproduce this bug
Comment 12 Maxxer 2008-03-18 14:29:58 UTC
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.
Comment 13 Tim Retout 2008-04-22 19:11:41 UTC
*** Bug 471713 has been marked as a duplicate of this bug. ***
Comment 14 Tim Retout 2008-04-24 22:42:43 UTC
This was already fixed in libexif CVS. Maxxer, perhaps you could confirm this and deal with the sourceforge bug report?
Comment 15 Maxxer 2008-04-27 14:32:00 UTC
(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.
Comment 16 Tim Retout 2008-04-27 22:51:41 UTC
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. :/
Comment 17 Stephane Delcroix 2008-04-28 07:07:21 UTC
Tim (comment #16), thx for the research. Yeah, leave the bug open.
Comment 18 Tim Retout 2008-04-28 07:18:19 UTC
Reopening. :)
Comment 19 André Klapper 2018-07-01 09:01:08 UTC
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.