Summary: | digikam deadlocks on batch renaming/moving images | ||
---|---|---|---|
Product: | [Applications] digikam | Reporter: | Johannes Hirte <johannes.hirte> |
Component: | AdvancedRename-engine | Assignee: | Digikam Developers <digikam-bugs-null> |
Status: | RESOLVED FIXED | ||
Severity: | crash | CC: | caulier.gilles |
Priority: | NOR | ||
Version: | 3.5.0 | ||
Target Milestone: | --- | ||
Platform: | Gentoo Packages | ||
OS: | Linux | ||
Latest Commit: | http://commits.kde.org/digikam/010d0293d322ce458d00ef1ff35ac90562ef7da6 | Version Fixed In: | 4.0.0 |
Sentry Crash Report: |
Description
Johannes Hirte
2014-02-27 19:10:17 UTC
Thanks a lot for your backtrace. A case to verify the good old rules: - a true deadlock happens if two mutexes are locked in varying order (or: you must define and adhere to a locking hierarchy, if two mutexes are locked at the same time) - you may need half an hour, but the deadlock can always be spotted from the backtrace Git commit 010d0293d322ce458d00ef1ff35ac90562ef7da6 by Marcel Wiesweg. Committed on 04/03/2014 at 12:41. Pushed by mwiesweg into branch 'master'. Reorder mutex locks - the ImageInfo ReadWriteLock must remain an "inner", transparent mutex. It is called from a place where DatabaseAccess is locked, so DatabaseAccess must not be locked from a place where the ImageInfo lock is held. To reduce by one or two mutex locks, consolidate read operations at one place and return the hash from a local variable which is in sync with the cached hash. (note: we do not rule out a parallel operation between the DatabaseAccess and the writing of the cached values. it's so far acceptable for a read cache.) CCMAIL: mike@mghansen.de M +22 -11 libs/database/imageinfo.cpp http://commits.kde.org/digikam/010d0293d322ce458d00ef1ff35ac90562ef7da6 |