Bug 162038

Hi Marcus,

Yes, please check libsqlite version. Somebody has reported in this room than last version break digiKam everywhere. We have not find yet the right way to fix it.

Gilles Caulier

Quoting Gilles Caulier
[bugs.kde.org quoted mail]

Ok; found these packages matching sqlite on my system:

libmono-sqlite1.0-cil:	1.9.1+dfsg-1 
libsqlite0:		2.8.17-4 
libsqlite0-dev:		2.8.17-4 
libsqlite3-0:		3.5.8-1 
libsqlite3-dev:		3.5.8-1 

I can upgrade the lisqlite3-* packages to 3.5.8-4, if you think it helps.

Marcus,

It will be better to test with libsqlite 3.5.6...


Gilles Caulier

I downloaded (from CVS) libsqlite as of 2008/02/06 (as this was the date when 
the file VERSION, containing 3.5.5 was comitted). 

I can confirm that the described behaviour does not occur in this version. I 
removed digikam3.db and re-initialised the db  (using 100GB of pictures).

Will trace upwards the version tree of libsqlite.

One problem though is that in my svn version of 
digikam, /usr/lib/libsqlite3.so.0 seems to be hardlinked, because setting 
LD_LIBRARY_PATH to my own sqlite installation didn't help. I had to redirect 
the link, which is not so nice...

Marcus,

thanks for the feedback.

Arnd,

there is a duplicate entry in B.K.O ?

Gilles

The problem occurs between these two CVS versions (obtained via cvs log 
VERSION in the sqlite cvs tree)

revision 1.170
date: 2008/04/15 14:37:51;  author: drh;  state: Exp;  lines: +1 -1
Increment the version number.
----------------------------
revision 1.169
date: 2008/03/11 15:41:14;  author: drh;  state: Exp;  lines: +1 -1
Increase the version number to 3.5.7 in anticipation of the next release.



The strange part is that the fiele VERSION of 2008/03/11 15:41:14;  contains 
3.5.6 (and works) while the one of 2008/04/15 14:37:51;  contains 3.5.7 and 
does not work.

According to the cvs comments either the versioning is wrong or I 
misunderstand things; Just writing this to make that clear.

Hope it helps.

If you want me to try a specific different point in time: Here I am.

Gilles, this sounds like 
https://bugs.kde.org/show_bug.cgi?id=160966
for which I filed a bug for sqlite, see the discussion in 
http://www.sqlite.org/cvstrac/tktview?tn=3087

Marcus, great detective work! In the above entry they claim
that this has been fixed with 
http://www.sqlite.org/cvstrac/chngview?cn=5026
Can you maybe confirm this?

Thanks a lot, Arnd

Hi Arnd,

Will check the fix you suggest. I've ran a couple of compilations and found 
that the CVS version as of
	2008-05-26-15:00:00 
works, while
	2008-05-26-16:00:00 
does not.

I have no deep understanding of sqlite, so I'd rather post the excerpt of the 
diff that IMO causes the trouble observed.

The Diff was created having the 15:00 version, diffing against 16:00. It can 
be reproduced using;

cvs up -D 2008/03/26\ 15:00:00
cvs diff -D 2008/03/26\ 16:00:00 -u

Index: src/where.c
===================================================================
RCS file: /sqlite/sqlite/src/where.c,v
retrieving revision 1.292
retrieving revision 1.291
diff -u -r1.292 -r1.291
--- src/where.c 26 Mar 2008 14:56:35 -0000      1.292
+++ src/where.c 25 Mar 2008 09:47:35 -0000      1.291
@@ -16,7 +16,7 @@
 ** so is applicable.  Because this module is responsible for selecting
 ** indices, you might also think of this module as the "query optimizer".
 **
-** $Id: where.c,v 1.292 2008/03/26 14:56:35 drh Exp $
+** $Id: where.c,v 1.291 2008/03/25 09:47:35 danielk1977 Exp $
 */
 #include "sqliteInt.h"

@@ -743,10 +743,7 @@
   }
   prereqAll = exprTableUsage(pMaskSet, pExpr);
   if( ExprHasProperty(pExpr, EP_FromJoin) ){
-    Bitmask x = getMask(pMaskSet, pExpr->iRightJoinTable);
-    prereqAll |= x;
-    pTerm->prereqRight |= x-1; /* ON clause terms may not be used with an 
index
-                               ** on left table of a LEFT JOIN.  Ticket #3015 
*/
+    prereqAll |= getMask(pMaskSet, pExpr->iRightJoinTable);
   }
   pTerm->prereqAll = prereqAll;
   pTerm->leftCursor = -1;
@@ -2046,36 +2043,14 @@
     pWhere = 0;
   }

-  /* Assign a bit from the bitmask to every term in the FROM clause.
-  **
-  ** When assigning bitmask values to FROM clause cursors, it must be
-  ** the case that if X is the bitmask for the N-th FROM clause term then
-  ** the bitmask for all FROM clause terms to the left of the N-th term
-  ** is (X-1).   An expression from the ON clause of a LEFT JOIN can use
-  ** its Expr.iRightJoinTable value to find the bitmask of the right table
-  ** of the join.  Subtracting one from the right table bitmask gives a
-  ** bitmask for all tables to the left of the join.  Knowing the bitmask
-  ** for all tables to the left of a left join is important.  Ticket #3015.
-  */
-  for(i=0; i<pTabList->nSrc; i++){
-    createMask(&maskSet, pTabList->a[i].iCursor);
-  }
-#ifndef NDEBUG
-  {
-    Bitmask toTheLeft = 0;
-    for(i=0; i<pTabList->nSrc; i++){
-      Bitmask m = getMask(&maskSet, pTabList->a[i].iCursor);
-      assert( (m-1)==toTheLeft );
-      toTheLeft |= m;
-    }
-  }
-#endif
-
   /* Analyze all of the subexpressions.  Note that exprAnalyze() might
   ** add new virtual terms onto the end of the WHERE clause.  We do not
   ** want to analyze these virtual terms, so start analyzing at the end
   ** and work forward so that the added virtual terms are never processed.
   */
+  for(i=0; i<pTabList->nSrc; i++){
+    createMask(&maskSet, pTabList->a[i].iCursor);
+  }
   exprAnalyzeAll(pTabList, &wc);
   if( db->mallocFailed ){
     goto whereBeginNoMem;





	

[bugs.kde.org quoted mail]

Quoting Arnd Baecker
[bugs.kde.org quoted mail]
Arnd told, that sqlite claims, the bug was fixed with:
http://www.sqlite.org/cvstrac/chngview?cn=5026

I can confirm that this does _NOT_ fix the bug.

But the CVS version as of today (May 24th) does not contain the bug anymore.

> Can you maybe confirm this?
>
> Thanks a lot, Arnd

[bugs.kde.org quoted mail]

In Debian/unstable this problem is fixed by 
libsqlite3-0 Version 3.5.9-1

Thanks Marcus,

Question what is the sqlite version where the problem is appears exactly ?

Arnd, 

This is want mean than we need to :

1/ Patch README file dependencies descriptions.
2/ Patch configure.in.in to check the right sqlite version.
3/ To post a message in mailing lists about this problem.
4/ To post a new blog entry to www.digikam.org

Gilles

The bug appeared somewhere in versions 3.5.7 and 3.5.8.
It is is not present in 3.5.9 

I confirmed this for the CVS versions as well as the corresponding debian 
packages of 3.5.8(currently in testing) and 3.5.9.(currently in unstable)




Note: The dates of the CVS I've specified earlier in this mailing were 
contradicting: All dates I wanted to mention were in March, not in May.


M.



[bugs.kde.org quoted mail]

Achim,

How we can use KDE_PCK_CHECK_MODULES in .configure.in.in to check libsqlite version istalled using these conditions:

sqlite3 >= 3.5.9
OR
(sqlite3 >= 3.0 && sqlite3 <= 3.5.6)

Gilles Caulier

I'm apparently getting the same bug fairly frequently when changing ratings on files. Actually I have libsqlite3-0 3.4.2-2 on Ubuntu 8.04, but the same symptoms. I mention it because of the workaround below that may be useful to others:

Actually digikam uses lots of CPU but so does the kio_digikamalbums kdeinit process. I found that running `pkill -f kio_digikamalbums` resolves the problem within a few seconds (digikam launches a new slave process).

Closing some old bugreports that are related to old digiKam version, and that have not received answers for two years now.

If you think the reports are still valid, feel free to re-open them, but please provide updates and do not just open them without giving feedback.

New digiKam 4.11.0 is available.

https://www.digikam.org/node/740

Can you reproduce the problem with this release ?

GUI doesn't hang on performing any of the above action in digiKam. Try 5.0.0 version.

If you think the report is still valid, feel free to re-open.