Bug 166484

Summary: digiKam crashes when changing some settings and using "find similar" after the changes made
Product: [Applications] digikam Reporter: Andi Clemens <andi.clemens>
Component: Searches-SimilarityAssignee: Digikam Developers <digikam-bugs-null>
Status: RESOLVED FIXED    
Severity: crash    
Priority: NOR    
Version: 0.10.0   
Target Milestone: ---   
Platform: unspecified   
OS: Linux   
Latest Commit: Version Fixed In: 0.10.0
Attachments: backtrace

Description Andi Clemens 2008-07-14 00:23:58 UTC 
Version:           0.10.0-beta2 (rev.: 831837M) (using 4.00.98 (KDE 4.0.98 (4.1 RC1)), compiled sources)
Compiler:          gcc
OS:                Linux (i686) release 2.6.25-ARCH

Hi,

I discovered a strange crash. First I thought it was a broken digikam4.db, because I use this since 2 months and maybe it was converted wrong in the past. I had issues with find duplicates before and so I created a new database right now. Well the problem is still present.
Here are the steps to reproduce the crash:

1. Create / Update your fingerprint database if not yet done
2. Select an image in album view, go to Image->Find Similar. Now you are in the "fuzzy searches - Image" tab.
3. Go to Settings->Album View. Now toggle 'show file name'.
4. Save your new settings
5. Back in "fuzzy searches - Image" tab, go to "Sketch".
6. If not crashed yet, go back to "Image" tab.
7. It should crash now.

This only happens when changing the settings as described above, at least for me.
It seems to be important to change the settings while in "find similar" tab, otherwise I cannot reproduce this.
I'll attach a backtrace to this bugreport.

Andi
Comment 1 Andi Clemens 2008-07-14 00:24:53 UTC 
It seems to crash also when in normal album view tab, changing the settings and clicking on "fuzzy searches - Image".
Comment 2 Andi Clemens 2008-07-14 00:25:40 UTC 
Created attachment 26100 [details]
backtrace
Comment 3 Marcel Wiesweg 2008-07-14 22:33:09 UTC 
After setup a lot of reinitialization is triggered (as anything might have changed) and also Album objects (kept in AlbumManager) are recreated.
I was not aware of this problem until recently. It occurs everywhere and Album* is stored (in this case, SAlbum*) and AlbumManager signals are not listened.
I am thinking about either implementing to listen to the signals in affected class, or, as a more general solution, implement a safe Album pointer class that does the signal listening. Yes, the latter can be better.
Comment 4 Andi Clemens 2008-07-23 20:41:26 UTC 
Yes, this sounds plausible...
Comment 5 Marcel Wiesweg 2008-07-26 19:45:26 UTC 
SVN commit 838092 by mwiesweg:

The class AlbumPointer provides a guarded pointer to Album* or one of the
subclasses. When the album is deleted, the pointer is set to 0.
Implementation is inspired by QPointer<>.

Accompanying changes: Make Album destructor protected. This should only be
accessible from AlbumManager. Install a private shortcut to access
AlbumManager instance from Album (for updating guarded pointers).
K_GLOBAL_STATIC instance is not accessible from call stacks going
out from the destructor.

CCBUG: 166484


 M  +1 -0      album.cpp  
 M  +12 -12    album.h  
 M  +46 -1     albummanager.cpp  
 M  +53 -0     albummanager.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=838092
Comment 6 Marcel Wiesweg 2008-07-26 19:45:30 UTC 
SVN commit 838093 by mwiesweg:

Use AlbumPointer for storing SAlbums

BUG: 166484


 M  +2 -2      fuzzysearchview.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=838093