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 395310 - Importing some photos makes F-Spot take 100% of CPU
Importing some photos makes F-Spot take 100% of CPU
Status: RESOLVED FIXED
Product: f-spot
Classification: Other
Component: Import
0.3.0
Other All
: Normal normal
: ---
Assigned To: F-spot maintainers
F-spot maintainers
Depends on:
Blocks:
 
 
Reported: 2007-01-11 08:09 UTC by Maxxer
Modified: 2007-01-30 15:19 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
A picture which causes the problem. (8.55 KB, image/jpeg)
2007-01-11 08:12 UTC, Maxxer
Details
Screenshot (147.99 KB, image/png)
2007-01-11 12:26 UTC, Maxxer
Details

Description Maxxer 2007-01-11 08:09:43 UTC
Please describe the problem:
I've imported some pictures I'll attach to this bug. After that, F-Spot takes 100% of memory and never drops it. Even closing and reopening the program doesn't solve the problem. 
Those pics were taken with a Nokia 7250, and don't contain Exif infos.

Steps to reproduce:


Actual results:


Expected results:


Does this happen every time?


Other information:
Comment 1 Maxxer 2007-01-11 08:12:12 UTC
Created attachment 80010 [details]
A picture which causes the problem.
Comment 2 Maxxer 2007-01-11 08:13:23 UTC
The following is the console output of an import session of the picture.
During the cpu load F-Spot doesn't output any error on the console.


$ f-spot -p fspassa/ -b fspassa/
BaseDirectory is now fspassa/
PhotoDirectory is now /home/maxxer/fspassa/
Starting new FSpot server
Reloading
item changed
item ImportCommand+SourceItem
Scanning /home/maxxer/fspassa
item changed
open uri = file:///home/maxxer/fspassa/Immag044.jpg
System.NullReferenceException: Object reference not set to an instance of an object
  at FSpot.JpegFile.get_Date () [0x00000] 
open uri = file:///home/maxxer/fspassa/Immag044.jpg
System.NullReferenceException: Object reference not set to an instance of an object
  at FSpot.JpegFile.get_Date () [0x00000] 
System.NullReferenceException: Object reference not set to an instance of an object
  at FSpot.JpegFile.get_Description () [0x00000] 
open uri = file:///home/maxxer/fspassa/2007/1/11/Immag044.jpg
open uri = file:///home/maxxer/fspassa/2007/1/11/Immag044.jpg
error checking orientation
open uri = file:///home/maxxer/fspassa/2007/1/11/Immag044.jpg
cleanup context
cleanup context
open uri = file:///home/maxxer/fspassa/2007/1/11/Immag044.jpg
old = "" new = "" heading = "ASCII"
value = f-spot version 0.3.0 len = 20
value = 2007:01:11 09:11:46 len = 19
value = 2007:01:11 09:11:46 len = 19
value = f-spot version 0.3.0 len = 20
value = 2007:01:11 09:11:46 len = 19
Saved 124 bytes
item changed
open uri = file:///home/maxxer/fspassa/2007/1/11/Immag044.jpg
error checking orientation
open uri = file:///home/maxxer/fspassa/2007/1/11/Immag044.jpg
Stopping
open uri = file:///home/maxxer/fspassa/2007/1/11/Immag044.jpg
open uri = file:///home/maxxer/fspassa/2007/1/11/Immag044.jpg
error checking orientation
open uri = file:///home/maxxer/fspassa/2007/1/11/Immag044.jpg
open uri = file:///home/maxxer/fspassa/2007/1/11/Immag044.jpg
error checking orientation
Reloading
item changed
open uri = file:///home/maxxer/fspassa/2007/1/11/Immag044.jpg
error checking orientation
open uri = file:///home/maxxer/fspassa/2007/1/11/Immag044.jpg
Comment 3 Stephane Delcroix 2007-01-11 09:12:17 UTC
hi maxxer,

I'm not sure I understand your issue... the topic is about 100%CPU and the description about 100%memory...
and you say that f-spot does not free its memory even after being killed !

btw, I can import your image just fine, getting the same logs as you, without any long term strange behavior with either cpu or memory
Comment 4 Maxxer 2007-01-11 09:23:02 UTC
(In reply to comment #3)
> hi maxxer,
> 
> I'm not sure I understand your issue... the topic is about 100%CPU and the
> description about 100%memory...
> and you say that f-spot does not free its memory even after being killed !

Sorry the problem is about CPU usage.

> btw, I can import your image just fine, getting the same logs as you, without
> any long term strange behavior with either cpu or memory

As I get that picture into F-Spot my cpu load goes 100%.
I'm using F-Spot 0.3.0.  I will try CVS today and will report back...
Comment 5 Maxxer 2007-01-11 09:41:09 UTC
tested now, same identical behavior with latest SVN.

What else can I do? 
Comment 6 Stephane Delcroix 2007-01-11 09:46:19 UTC
start f-spot,
load your image
kill f-spot
if the cpu is still 100% used, use top (or ps or whatever) to check which process is running
Comment 7 Maxxer 2007-01-11 11:15:05 UTC
(In reply to comment #6)
> start f-spot,
> load your image
> kill f-spot
> if the cpu is still 100% used, use top (or ps or whatever) to check which
> process is running


I'm already sure F-spot is taking the CPU, because I see it in top when f-spot is running, and when I close it the cpu returns to normal usage!
Comment 8 Stephane Delcroix 2007-01-11 11:52:13 UTC
ah, when you kill f-spot, the cpu usage is 'normal' then ! sorry for the misunderstanding...
Comment 9 Maxxer 2007-01-11 12:26:12 UTC
Created attachment 80022 [details]
Screenshot

A screenshot which shows cpu usage.
Comment 10 Stephane Delcroix 2007-01-19 11:21:15 UTC
hi maxxer,

this photo is corrupted, as reported by the gimp loader: "Corrupt JPEG data: 100 extraneous bytes before marker 0xd9"

Probably yet another libexif bug. Which version of libexif are you using ??
Comment 11 Maxxer 2007-01-19 11:55:25 UTC
(In reply to comment #10)

> this photo is corrupted, as reported by the gimp loader: "Corrupt JPEG data:
> 100 extraneous bytes before marker 0xd9"
> 
> Probably yet another libexif bug. Which version of libexif are you using ??

0.6.13 
Comment 12 Stephane Delcroix 2007-01-19 12:20:53 UTC
mmm, this version works here...

if you strip the exif part, can you load it (so we're sure that the culprit is the exif part) ?

you can strip exifs using jhead

jhead -purejpg photo.jpg
Comment 13 Maxxer 2007-01-30 15:09:33 UTC
I'm sorry, it seems that I cannot reproduce it anymore.
So either it got fixed itself in the latest releases or I really don't know what happened :-)

Thanks
Comment 14 Stephane Delcroix 2007-01-30 15:19:07 UTC
Don't be sorry.

... closing it