Bug 166484 - digiKam crashes when changing some settings and using "find similar" after the changes made
Summary: digiKam crashes when changing some settings and using "find similar" after th...
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Searches-Similarity (show other bugs)
Version: 0.10.0
Platform: unspecified Linux
: NOR crash
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-07-14 00:23 UTC by Andi Clemens
Modified: 2012-06-27 11:26 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In: 0.10.0
Sentry Crash Report:


Attachments
backtrace (4.50 KB, text/plain)
2008-07-14 00:25 UTC, Andi Clemens
Details

Note You need to log in before you can comment on or make changes to this bug.
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