[digikam] [Bug 323888] New: Face recognition makes digikam fill all the available memory

[Gilles Caulier-4]

https://bugs.kde.org/show_bug.cgi?id=323888

--- Comment #77 from Gilles Caulier <[hidden email]> ---
Git commit fa909aa96e7e41225551cd9e866618717f1ea546 by Gilles Caulier.
Committed on 11/06/2014 at 21:06.
Pushed by cgilles into branch 'master'.

use a better C++ exception wrapper to handle non OpenCV exceptions (as pure C++
one)
Related: bug 335624, bug 330342, bug 329873, bug 326742, bug 326586, bug
326585, bug 324774, bug 323361, bug 320812, bug 312440, bug 309027, bug 308645,
bug 301611, bug 297558, bug 285517

M  +4    -0    libkface/facedetector.cpp
M  +17   -2    libkface/recognitiondatabase.cpp

http://commits.kde.org/libkface/fa909aa96e7e41225551cd9e866618717f1ea546

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

https://bugs.kde.org/show_bug.cgi?id=323888

--- Comment #78 from Gilles Caulier <[hidden email]> ---
With next digiKam 4.1.0, i fixed libkface to handle all C++ exception (and not
only OpenCV exception).

So, at least, digiKam must crash lesser now. If you want to review this entry
again, use current implementation from git/master, or wait next 4.1.0
release...

Thanks to update your feedback

Gilles Caulier

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

https://bugs.kde.org/show_bug.cgi?id=323888

--- Comment #79 from Gilles Caulier <[hidden email]> ---
Git commit 4662dd94102f8144bc65ce1cb66d6b6cb1d500fd by Gilles Caulier.
Committed on 18/06/2014 at 14:22.
Pushed by cgilles into branch 'master'.

Libkface now depand of last stable OpenCV library version 2.4.9
This prevent internal crash int Cv:Algorithm that we cannot handle in libkface
as exception.
Now, Face Recognition do not crash but still report Exception at training
operations, especially about wrong Cv:Matrix size :

digikam(8673)/digikam (core)
Digikam::DImg::load:"/mnt/data2/photos/GILLES/NEW/Adrien/2010-04-13/20100413_009.jpg"
 :
JPEG file identified
OpenCV Error: Assertion failed (0 <= _dims && _dims <= CV_MAX_DIM) in setSize,
file /mnt/devel/opencv/modules/core/src/matrix.cpp, line 89
digikam(8673)/KFACE: cv::Exception training LBPH:
/mnt/devel/opencv/modules/core/src/matrix.cpp:89: error: (-215) 0 <=_dims &&
_dims <= CV_MAX_DIM in function setSize

It still a problem somwhere, but it's better than previous state.
Related: bug 335624, bug 330342, bug 329873, bug 326742, bug 326586, bug
326585, bug 324774, bug 323361, bug 320812, bug 312440, bug 309027, bug 308645,
bug 301611, bug 297558, bug 285517

M  +1    -1    CMakeLists.txt

http://commits.kde.org/libkface/4662dd94102f8144bc65ce1cb66d6b6cb1d500fd

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

https://bugs.kde.org/show_bug.cgi?id=323888

--- Comment #80 from Gilles Caulier <[hidden email]> ---
Git commit 1fff86f31e3bf47a2a2cfa6eaa98bb1bdf1a863b by Gilles Caulier.
Committed on 24/06/2014 at 12:32.
Pushed by cgilles into branch 'master'.

add more test before to commit/checkout compressed histogram data in Face
database, to prevent crashes, especially if data are corrupted from database.
Related: bug 335624, bug 330342, bug 329873, bug 326742, bug 326586, bug
326585, bug 324774, bug 320812, bug 312440, bug 309027, bug 308645, bug 301611,
bug 297558, bug 285517

M  +62   -28   libkface/database/trainingdb.cpp

http://commits.kde.org/libkface/1fff86f31e3bf47a2a2cfa6eaa98bb1bdf1a863b

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

https://bugs.kde.org/show_bug.cgi?id=323888

--- Comment #81 from Gilles Caulier <[hidden email]> ---
I have bad news for this entry.

My investigations result sound to conclude that there are huge memory
liberation performed outside digiKam database interface.

I tested it with SQLite.

It's not memory leak. allocated memory is liberated at end of digiKam session.

But database transactions take memory again and again. There is no reason for
that. This is true for main digiKam database, and of course with Face database
which store image compressed histogram data processed by faces training
process.

I'm sure to not have seen it in the pass. I suspect a regression in libsqlite
or Qt4-sqlite plugin.

To resume, i suspect a UPSTREAM bug.

Gilles Caulier

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

https://bugs.kde.org/show_bug.cgi?id=323888

--- Comment #82 from Gilles Caulier <[hidden email]> ---
Note :

I suspect a similar problem with QSlite about main digiKAm database at scanning
process, especially at first time run, when collection to parse is huge. I
remember to see report about crash at start up when swap become active.

Here i cannot reproduce this typical crash, because my computer use 16 Gb of
RAM. It's of course reproducible with a VM using limited RAM.

Gilles Caulier

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[kde-bugs]

https://bugs.kde.org/show_bug.cgi?id=323888

--- Comment #83 from [hidden email] ---
I think Alexander has a point in #5 #6 and #72 - when the recognition.db is
deleted, everything works fine. So the real issue is that it must be verified
that it cannot grow as large as it had for those of us who had been affected by
this bug.

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

https://bugs.kde.org/show_bug.cgi?id=323888

--- Comment #84 from Gilles Caulier <[hidden email]> ---
In a VM, i can reproduce the memory leak from SQlite. I take a similar
fingerprint with valgrind here. Look log from attachment "digikam 4.0 still
leaking memory" :

==26673== 305,920 bytes in 239 blocks are possibly lost in loss record 120,501
of 120,538
==26673==    at 0x4C274A0: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==26673==    by 0x21076F46: ??? (in
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==26673==    by 0x21050AE9: ??? (in
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==26673==    by 0x21059217: ??? (in
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==26673==    by 0x2105CEBA: ??? (in
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==26673==    by 0x2105D125: ??? (in
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==26673==    by 0x210569B0: ??? (in
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==26673==    by 0x21083B35: ??? (in
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==26673==    by 0x21083F1C: ??? (in
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==26673==    by 0x21086102: ??? (in
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==26673==    by 0x21086179: ??? (in
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==26673==    by 0x21086257: ??? (in
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==26673==
==26673== 1,332,480 bytes in 1,041 blocks are possibly lost in loss record
120,527 of 120,538
==26673==    at 0x4C274A0: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==26673==    by 0x21076F46: ??? (in
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==26673==    by 0x21050AE9: ??? (in
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==26673==    by 0x21059217: ??? (in
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==26673==    by 0x2105CEBA: ??? (in
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==26673==    by 0x2105D125: ??? (in
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==26673==    by 0x210569B0: ??? (in
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==26673==    by 0x21083B35: ??? (in
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==26673==    by 0x21083F1C: ??? (in
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==26673==    by 0x21086102: ??? (in
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==26673==    by 0x21086179: ??? (in
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==26673==    by 0x2108B2AB: ??? (in
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==26673==
==26673== 2,752,344 bytes in 43 blocks are possibly lost in loss record 120,533
of 120,538
==26673==    at 0x4C274A0: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==26673==    by 0x21076F46: ??? (in
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==26673==    by 0x21050AE9: ??? (in
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==26673==    by 0x21059217: ??? (in
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==26673==    by 0x21062FD1: ??? (in
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==26673==    by 0x210D7F9D: ??? (in
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==26673==    by 0x36ED985E: QSQLiteDriver::open(QString const&, QString const&,
QString const&, QString const&, int, QString const&) (in
/usr/lib/x86_64-linux-gnu/qt4/plugins/sqldrivers/libqsqlite.so)
==26673==    by 0x4E44D60: QSqlDatabase::open() (in
/usr/lib/x86_64-linux-gnu/libQtSql.so.4.8.6)
==26673==    by 0x7516600:
Digikam::DatabaseCoreBackendPrivate::open(QSqlDatabase&) (in
/usr/lib/digikam/libdigikamcore.so.4.0.0)
==26673==    by 0x7516BCA:
Digikam::DatabaseCoreBackendPrivate::databaseForThread() (in
/usr/lib/digikam/libdigikamcore.so.4.0.0)
==26673==    by 0x7516E99: Digikam::DatabaseCoreBackend::getQuery() (in
/usr/lib/digikam/libdigikamcore.so.4.0.0)
==26673==    by 0x7519391: Digikam::DatabaseCoreBackend::prepareQuery(QString
const&) (in /usr/lib/digikam/libdigikamcore.so.4.0.0)
==26673==
==26673== 4,497,920 bytes in 3,514 blocks are possibly lost in loss record
120,535 of 120,538
==26673==    at 0x4C274A0: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==26673==    by 0x21076F46: ??? (in
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==26673==    by 0x21050AE9: ??? (in
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==26673==    by 0x21059217: ??? (in
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==26673==    by 0x2105CEBA: ??? (in
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==26673==    by 0x2105D125: ??? (in
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==26673==    by 0x210569B0: ??? (in
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==26673==    by 0x21083B35: ??? (in
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==26673==    by 0x2108AA23: ??? (in
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==26673==    by 0x2108C55E: ??? (in
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==26673==    by 0x210B72E8: ??? (in
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==26673==    by 0x210B834E: sqlite3_step (in
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==26673==

==26673== 305,920 bytes in 239 blocks are possibly lost in loss record 120,501
of 120,538
==26673==    at 0x4C274A0: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==26673==    by 0x21076F46: ??? (in
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==26673==    by 0x21050AE9: ??? (in
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==26673==    by 0x21059217: ??? (in
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==26673==    by 0x2105CEBA: ??? (in
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==26673==    by 0x2105D125: ??? (in
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==26673==    by 0x210569B0: ??? (in
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==26673==    by 0x21083B35: ??? (in
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==26673==    by 0x21083F1C: ??? (in
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==26673==    by 0x21086102: ??? (in
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==26673==    by 0x21086179: ??? (in
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==26673==    by 0x21086257: ??? (in
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==26673==
==26673== 1,332,480 bytes in 1,041 blocks are possibly lost in loss record
120,527 of 120,538
==26673==    at 0x4C274A0: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==26673==    by 0x21076F46: ??? (in
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==26673==    by 0x21050AE9: ??? (in
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==26673==    by 0x21059217: ??? (in
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==26673==    by 0x2105CEBA: ??? (in
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==26673==    by 0x2105D125: ??? (in
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==26673==    by 0x210569B0: ??? (in
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==26673==    by 0x21083B35: ??? (in
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==26673==    by 0x21083F1C: ??? (in
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==26673==    by 0x21086102: ??? (in
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==26673==    by 0x21086179: ??? (in
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==26673==    by 0x2108B2AB: ??? (in
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==26673==
==26673== 2,752,344 bytes in 43 blocks are possibly lost in loss record 120,533
of 120,538
==26673==    at 0x4C274A0: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==26673==    by 0x21076F46: ??? (in
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==26673==    by 0x21050AE9: ??? (in
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==26673==    by 0x21059217: ??? (in
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==26673==    by 0x21062FD1: ??? (in
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==26673==    by 0x210D7F9D: ??? (in
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==26673==    by 0x36ED985E: QSQLiteDriver::open(QString const&, QString const&,
QString const&, QString const&, int, QString const&) (in
/usr/lib/x86_64-linux-gnu/qt4/plugins/sqldrivers/libqsqlite.so)
==26673==    by 0x4E44D60: QSqlDatabase::open() (in
/usr/lib/x86_64-linux-gnu/libQtSql.so.4.8.6)
==26673==    by 0x7516600:
Digikam::DatabaseCoreBackendPrivate::open(QSqlDatabase&) (in
/usr/lib/digikam/libdigikamcore.so.4.0.0)
==26673==    by 0x7516BCA:
Digikam::DatabaseCoreBackendPrivate::databaseForThread() (in
/usr/lib/digikam/libdigikamcore.so.4.0.0)
==26673==    by 0x7516E99: Digikam::DatabaseCoreBackend::getQuery() (in
/usr/lib/digikam/libdigikamcore.so.4.0.0)
==26673==    by 0x7519391: Digikam::DatabaseCoreBackend::prepareQuery(QString
const&) (in /usr/lib/digikam/libdigikamcore.so.4.0.0)
==26673==
==26673== 4,497,920 bytes in 3,514 blocks are possibly lost in loss record
120,535 of 120,538
==26673==    at 0x4C274A0: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==26673==    by 0x21076F46: ??? (in
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==26673==    by 0x21050AE9: ??? (in
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==26673==    by 0x21059217: ??? (in
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==26673==    by 0x2105CEBA: ??? (in
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==26673==    by 0x2105D125: ??? (in
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==26673==    by 0x210569B0: ??? (in
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==26673==    by 0x21083B35: ??? (in
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==26673==    by 0x2108AA23: ??? (in
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==26673==    by 0x2108C55E: ??? (in
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==26673==    by 0x210B72E8: ??? (in
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==26673==    by 0x210B834E: sqlite3_step (in
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==26673==

Memory leak from SQlite is just enormous...

Gilles Caulier

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

https://bugs.kde.org/show_bug.cgi?id=323888

--- Comment #85 from Gilles Caulier <[hidden email]> ---
With next digiKam 4.1.0, a lots of improvements/fixes have be done around face
management. Please give us a fresh feedback.

Note i recommend to delete face recognition database to prevent dysfunction due
to possible wrong data store in this container. Look where file is located in
my computer :

[gilles@localhost database]$ pwd
/home/gilles/.kde4/share/apps/libkface/database
[gilles@localhost database]$ ls -al
total 397028
drwx------ 2 gilles gilles      4096 juin  24 14:22 ./
drwx------ 3 gilles gilles      4096 juin  18 19:08 ../
-rw-r--r-- 1 gilles gilles 406543360 juin  24 14:22 recognition.db
[gilles@localhost database]$

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

https://bugs.kde.org/show_bug.cgi?id=323888

Gilles Caulier <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Face recognition makes      |Face recognition makes
                   |digikam fill all the        |digikam fill all the
                   |available memory            |available memory (Qt SQlite
                   |                            |plugin relevant)

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

https://bugs.kde.org/show_bug.cgi?id=323888

Gilles Caulier <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|4.0.0                       |4.2.0

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

https://bugs.kde.org/show_bug.cgi?id=323888

--- Comment #86 from Gilles Caulier <[hidden email]> ---
I just check again digiKam 4.2.0 (current git/master implementation), and i can
confirm the huge memory leak done by Qt Sqlite plugin when face are detected
from image and registered to digiKam Database.

Sound like there is a big problem in Qt Sqlite plugin. See end of valgrind
backtrace below :

==7348== 34,560 bytes in 27 blocks are possibly lost in loss record 26,533 of
26,604
==7348==    at 0x4C266ED: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==7348==    by 0x1F8569A6: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==7348==    by 0x1F832189: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==7348==    by 0x1F83A317: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==7348==    by 0x1F83CDCA: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==7348==    by 0x1F83D021: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==7348==    by 0x1F8378E8: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==7348==    by 0x1F862255: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==7348==    by 0x1F86250C: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==7348==    by 0x1F864701: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==7348==    by 0x1F8649EE: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==7348==    by 0x1F8660E4: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==7348==
==7348== 44,800 bytes in 35 blocks are possibly lost in loss record 26,540 of
26,604
==7348==    at 0x4C266ED: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==7348==    by 0x1F8569A6: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==7348==    by 0x1F832189: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==7348==    by 0x1F83A317: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==7348==    by 0x1F83CDCA: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==7348==    by 0x1F83D021: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==7348==    by 0x1F8378E8: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==7348==    by 0x1F862255: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==7348==    by 0x1F86250C: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==7348==    by 0x1F864701: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==7348==    by 0x1F864779: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==7348==    by 0x1F864867: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==7348==
==7348== 64,008 bytes in 1 blocks are possibly lost in loss record 26,549 of
26,604
==7348==    at 0x4C266ED: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==7348==    by 0x1F8569A6: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==7348==    by 0x1F832189: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==7348==    by 0x1F83A317: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==7348==    by 0x1F840AE1: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==7348==    by 0x1F8B42A6: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==7348==    by 0x2D04581E: ??? (in
/usr/lib64/qt4/plugins/sqldrivers/libqsqlite.so)
==7348==    by 0x4E42D60: QSqlDatabase::open() (in
/usr/lib64/libQtSql.so.4.8.6)
==7348==    by 0x7C179D6:
Digikam::DatabaseCoreBackendPrivate::open(QSqlDatabase&)
(databasecorebackend.cpp:214)
==7348==    by 0x7C172C0:
Digikam::DatabaseCoreBackendPrivate::databaseForThread()
(databasecorebackend.cpp:120)
==7348==    by 0x7C1A7A3:
Digikam::DatabaseCoreBackend::open(Digikam::DatabaseParameters const&)
(databasecorebackend.cpp:769)
==7348==    by 0x81D2BD1:
Digikam::DatabaseAccess::checkReadyForUse(Digikam::InitializationObserver*)
(databaseaccess.cpp:286)
==7348==
==7348== 602,880 bytes in 471 blocks are possibly lost in loss record 26,596 of
26,604
==7348==    at 0x4C266ED: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==7348==    by 0x1F8569A6: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==7348==    by 0x1F832189: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==7348==    by 0x1F83A317: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==7348==    by 0x1F83CDCA: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==7348==    by 0x1F83D021: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==7348==    by 0x1F8378E8: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==7348==    by 0x1F862255: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==7348==    by 0x1F86250C: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==7348==    by 0x1F864701: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==7348==    by 0x1F864779: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==7348==    by 0x1F866338: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==7348==
==7348== 768,096 bytes in 12 blocks are possibly lost in loss record 26,600 of
26,604
==7348==    at 0x4C266ED: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==7348==    by 0x1F8569A6: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==7348==    by 0x1F832189: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==7348==    by 0x1F83A317: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==7348==    by 0x1F840AE1: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==7348==    by 0x1F8B42A6: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==7348==    by 0x2D04581E: ??? (in
/usr/lib64/qt4/plugins/sqldrivers/libqsqlite.so)
==7348==    by 0x4E42D60: QSqlDatabase::open() (in
/usr/lib64/libQtSql.so.4.8.6)
==7348==    by 0x7C179D6:
Digikam::DatabaseCoreBackendPrivate::open(QSqlDatabase&)
(databasecorebackend.cpp:214)
==7348==    by 0x7C172C0:
Digikam::DatabaseCoreBackendPrivate::databaseForThread()
(databasecorebackend.cpp:120)
==7348==    by 0x7C1D2DD: Digikam::DatabaseCoreBackend::getQuery()
(databasecorebackend.cpp:1512)
==7348==    by 0x7C1CF12: Digikam::DatabaseCoreBackend::prepareQuery(QString
const&) (databasecorebackend.cpp:1467)
==7348==
==7348== 2,291,200 bytes in 1,790 blocks are possibly lost in loss record
26,603 of 26,604
==7348==    at 0x4C266ED: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==7348==    by 0x1F8569A6: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==7348==    by 0x1F832189: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==7348==    by 0x1F83A317: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==7348==    by 0x1F83CDCA: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==7348==    by 0x1F83D021: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==7348==    by 0x1F8378E8: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==7348==    by 0x1F862255: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==7348==    by 0x1F865B53: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==7348==    by 0x1F866B26: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==7348==    by 0x1F895911: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==7348==    by 0x1F89655E: sqlite3_step (in /usr/lib64/libsqlite3.so.0.8.6)
==7348==
==7348== LEAK SUMMARY:
==7348==    definitely lost: 246,004 bytes in 1,710 blocks
==7348==    indirectly lost: 584,784 bytes in 10,817 blocks
==7348==      possibly lost: 4,004,231 bytes in 4,642 blocks
==7348==    still reachable: 21,369,113 bytes in 64,209 blocks
==7348==         suppressed: 0 bytes in 0 blocks
==7348== Reachable blocks (those to which a pointer was found) are not shown.
==7348== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==7348==
==7348== For counts of detected and suppressed errors, rerun with: -v
==7348== Use --track-origins=yes to see where uninitialised values come from
==7348== ERROR SUMMARY: 1474 errors from 1450 contexts (suppressed: 4 from 3)

Gilles Caulier

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

https://bugs.kde.org/show_bug.cgi?id=323888

Gilles Caulier <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|Face Management             |qt
            Version|4.2.0                       |4.11.5
           Assignee|[hidden email]       |[hidden email]
            Product|digikam                     |kdelibs

--- Comment #87 from Gilles Caulier <[hidden email]> ---
Note : Linux Mageia 4 64 bits, Qt 4.8.2, libsqlite 3.8.0.2

I forward this file to qt components for future investigations from Qt
developers.

Gilles Caulier

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

https://bugs.kde.org/show_bug.cgi?id=323888

Gilles Caulier <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|qt                          |Database
            Version|4.11.5                      |4.2.0
           Assignee|[hidden email]        |[hidden email]
            Product|kdelibs                     |digikam

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

https://bugs.kde.org/show_bug.cgi?id=323888

Gilles Caulier <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|Database                    |Face Management

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

https://bugs.kde.org/show_bug.cgi?id=323888

--- Comment #89 from Gilles Caulier <[hidden email]> ---
I progressed well in this entry about investigations.

Here under Mageia4, i use Qt 4.8.2 and libsqlite 3.8.0.2

I written a small CLI program to check digiKam database init with valgrind.
Installing qt and sqlite debug package, i can identify now where memory is
leak.

In fact it's a know problem already reported in this entry :

https://bugs.kde.org/show_bug.cgi?id=329697

... where users complain that digiKam crash into libsqlite memory management
functions.

So now with valgrind, we can see where memory is leak on my computer :
==32332== 7,680 bytes in 6 blocks are possibly lost in loss record 2,049 of
2,066
==32332==    at 0x4C266ED: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==32332==    by 0x1DDFF9A6: sqlite3MemMalloc (sqlite3.c:15739)
==32332==    by 0x1DDDB189: mallocWithAlarm (sqlite3.c:19037)
==32332==    by 0x1DDE3317: sqlite3Malloc (sqlite3.c:19070)
==32332==    by 0x1DDE5DCA: pcache1Alloc (sqlite3.c:36875)
==32332==    by 0x1DDE6021: pcache1Fetch (sqlite3.c:36959)
==32332==    by 0x1DDE08E8: sqlite3PcacheFetch (sqlite3.c:36286)
==32332==    by 0x1DE0B255: sqlite3PagerAcquire (sqlite3.c:43632)
==32332==    by 0x1DE0B50C: btreeGetPage (sqlite3.c:51175)
==32332==    by 0x1DE0D701: getAndInitPage (sqlite3.c:51230)
==32332==    by 0x1DE0D9EE: moveToRoot (sqlite3.c:53987)
==32332==    by 0x1DE0F0E4: sqlite3BtreeMovetoUnpacked (sqlite3.c:54204)
==32332==
==32332== 9,000 bytes in 45 blocks are possibly lost in loss record 2,056 of
2,066
==32332==    at 0x4C266ED: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==32332==    by 0x1DDFF9A6: sqlite3MemMalloc (sqlite3.c:15739)
==32332==    by 0x1DDDB189: mallocWithAlarm (sqlite3.c:19037)
==32332==    by 0x1DDE3317: sqlite3Malloc (sqlite3.c:19070)
==32332==    by 0x1DDE3450: sqlite3DbMallocRaw (sqlite3.c:19406)
==32332==    by 0x1DDF06DB: exprDup (sqlite3.c:76262)
==32332==    by 0x1DE2EEA3: sqlite3Parser (sqlite3.c:76350)
==32332==    by 0x1DE34459: sqlite3RunParser (sqlite3.c:115140)
==32332==    by 0x1DE34A81: sqlite3Prepare (sqlite3.c:96189)
==32332==    by 0x1DE34D64: sqlite3LockAndPrepare (sqlite3.c:96280)
==32332==    by 0x1DE34DF4: sqlite3_prepare (sqlite3.c:96344)
==32332==    by 0x1DE34EAE: sqlite3InitCallback (sqlite3.c:95658)
==32332==
==32332== 9,564 (1,920 direct, 7,644 indirect) bytes in 20 blocks are
definitely lost in loss record 2,058 of 2,066
==32332==    at 0x4C26BF5: operator new(unsigned long) (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==32332==    by 0x5C39FA2: ??? (in /usr/lib64/libQtCore.so.4.8.6)
==32332==    by 0x5C34567: QFactoryLoader::updateDir(QString const&,
QSettings&) (in /usr/lib64/libQtCore.so.4.8.6)
==32332==    by 0x5C364C6: QFactoryLoader::update() (in
/usr/lib64/libQtCore.so.4.8.6)
==32332==    by 0x5C366E9: QFactoryLoader::QFactoryLoader(char const*, QString
const&, Qt::CaseSensitivity) (in /usr/lib64/libQtCore.so.4.8.6)
==32332==    by 0x6456754: ??? (in /usr/lib64/libQtGui.so.4.8.6)
==32332==    by 0x6456BBF: ??? (in /usr/lib64/libQtGui.so.4.8.6)
==32332==    by 0x6458891: ??? (in /usr/lib64/libQtGui.so.4.8.6)
==32332==    by 0x6459DE7: QImageReader::read(QImage*) (in
/usr/lib64/libQtGui.so.4.8.6)
==32332==    by 0x6459FB3: QImageReader::read() (in
/usr/lib64/libQtGui.so.4.8.6)
==32332==    by 0x644E5D8: operator>>(QDataStream&, QImage&) (in
/usr/lib64/libQtGui.so.4.8.6)
==32332==    by 0x64676D8: operator>>(QDataStream&, QPixmap&) (in
/usr/lib64/libQtGui.so.4.8.6)
==32332==
==32332== 15,288 bytes in 39 blocks are possibly lost in loss record 2,059 of
2,066
==32332==    at 0x4C266ED: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==32332==    by 0x1DDFF9A6: sqlite3MemMalloc (sqlite3.c:15739)
==32332==    by 0x1DDDB189: mallocWithAlarm (sqlite3.c:19037)
==32332==    by 0x1DDE3317: sqlite3Malloc (sqlite3.c:19070)
==32332==    by 0x1DDE3450: sqlite3DbMallocRaw (sqlite3.c:19406)
==32332==    by 0x1DE31C06: sqlite3Parser (sqlite3.c:83487)
==32332==    by 0x1DE34459: sqlite3RunParser (sqlite3.c:115140)
==32332==    by 0x1DE34A81: sqlite3Prepare (sqlite3.c:96189)
==32332==    by 0x1DE34D64: sqlite3LockAndPrepare (sqlite3.c:96280)
==32332==    by 0x1DE34DF4: sqlite3_prepare (sqlite3.c:96344)
==32332==    by 0x1DE34EAE: sqlite3InitCallback (sqlite3.c:95658)
==32332==    by 0x1DE35258: sqlite3_exec (sqlite3.c:92433)
==32332==
==32332== 38,400 bytes in 30 blocks are possibly lost in loss record 2,063 of
2,066
==32332==    at 0x4C266ED: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==32332==    by 0x1DDFF9A6: sqlite3MemMalloc (sqlite3.c:15739)
==32332==    by 0x1DDDB189: mallocWithAlarm (sqlite3.c:19037)
==32332==    by 0x1DDE3317: sqlite3Malloc (sqlite3.c:19070)
==32332==    by 0x1DDE5DCA: pcache1Alloc (sqlite3.c:36875)
==32332==    by 0x1DDE6021: pcache1Fetch (sqlite3.c:36959)
==32332==    by 0x1DDE08E8: sqlite3PcacheFetch (sqlite3.c:36286)
==32332==    by 0x1DE0B255: sqlite3PagerAcquire (sqlite3.c:43632)
==32332==    by 0x1DE0B50C: btreeGetPage (sqlite3.c:51175)
==32332==    by 0x1DE0D701: getAndInitPage (sqlite3.c:51230)
==32332==    by 0x1DE0D779: moveToChild (sqlite3.c:53869)
==32332==    by 0x1DE0D867: moveToLeftmost (sqlite3.c:54049)
==32332==
==32332== 64,008 bytes in 1 blocks are possibly lost in loss record 2,064 of
2,066
==32332==    at 0x4C266ED: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==32332==    by 0x1DDFF9A6: sqlite3MemMalloc (sqlite3.c:15739)
==32332==    by 0x1DDDB189: mallocWithAlarm (sqlite3.c:19037)
==32332==    by 0x1DDE3317: sqlite3Malloc (sqlite3.c:19070)
==32332==    by 0x1DDE9AE1: setupLookaside.part.235 (sqlite3.c:116154)
==32332==    by 0x1DE5D2A6: openDatabase (sqlite3.c:93720)
==32332==    by 0x2BA5A81E: ??? (in
/usr/lib64/qt4/plugins/sqldrivers/libqsqlite.so)
==32332==    by 0x6E8CD60: QSqlDatabase::open() (in
/usr/lib64/libQtSql.so.4.8.6)
==32332==    by 0x5173AA8:
Digikam::DatabaseCoreBackendPrivate::open(QSqlDatabase&)
(databasecorebackend.cpp:214)
==32332==    by 0x51733D0:
Digikam::DatabaseCoreBackendPrivate::databaseForThread()
(databasecorebackend.cpp:120)
==32332==    by 0x5176861:
Digikam::DatabaseCoreBackend::open(Digikam::DatabaseParameters const&)
(databasecorebackend.cpp:769)
==32332==    by 0x572FBD1:
Digikam::DatabaseAccess::checkReadyForUse(Digikam::InitializationObserver*)
(databaseaccess.cpp:286)
==32332==
==32332== 64,008 bytes in 1 blocks are possibly lost in loss record 2,065 of
2,066
==32332==    at 0x4C266ED: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==32332==    by 0x1DDFF9A6: sqlite3MemMalloc (sqlite3.c:15739)
==32332==    by 0x1DDDB189: mallocWithAlarm (sqlite3.c:19037)
==32332==    by 0x1DDE3317: sqlite3Malloc (sqlite3.c:19070)
==32332==    by 0x1DDE9AE1: setupLookaside.part.235 (sqlite3.c:116154)
==32332==    by 0x1DE5D2A6: openDatabase (sqlite3.c:93720)
==32332==    by 0x2BA5A81E: ??? (in
/usr/lib64/qt4/plugins/sqldrivers/libqsqlite.so)
==32332==    by 0x6E8CD60: QSqlDatabase::open() (in
/usr/lib64/libQtSql.so.4.8.6)
==32332==    by 0x5173AA8:
Digikam::DatabaseCoreBackendPrivate::open(QSqlDatabase&)
(databasecorebackend.cpp:214)
==32332==    by 0x51733D0:
Digikam::DatabaseCoreBackendPrivate::databaseForThread()
(databasecorebackend.cpp:120)
==32332==    by 0x517939B: Digikam::DatabaseCoreBackend::getQuery()
(databasecorebackend.cpp:1512)
==32332==    by 0x5178FD0: Digikam::DatabaseCoreBackend::prepareQuery(QString
const&) (databasecorebackend.cpp:1467)
==32332==
==32332== 64,008 bytes in 1 blocks are possibly lost in loss record 2,066 of
2,066
==32332==    at 0x4C266ED: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==32332==    by 0x1DDFF9A6: sqlite3MemMalloc (sqlite3.c:15739)
==32332==    by 0x1DDDB189: mallocWithAlarm (sqlite3.c:19037)
==32332==    by 0x1DDE3317: sqlite3Malloc (sqlite3.c:19070)
==32332==    by 0x1DDE9AE1: setupLookaside.part.235 (sqlite3.c:116154)
==32332==    by 0x1DE5D2A6: openDatabase (sqlite3.c:93720)
==32332==    by 0x2BA5A81E: ??? (in
/usr/lib64/qt4/plugins/sqldrivers/libqsqlite.so)
==32332==    by 0x6E8CD60: QSqlDatabase::open() (in
/usr/lib64/libQtSql.so.4.8.6)
==32332==    by 0x5173AA8:
Digikam::DatabaseCoreBackendPrivate::open(QSqlDatabase&)
(databasecorebackend.cpp:214)
==32332==    by 0x51733D0:
Digikam::DatabaseCoreBackendPrivate::databaseForThread()
(databasecorebackend.cpp:120)
==32332==    by 0x5176861:
Digikam::DatabaseCoreBackend::open(Digikam::DatabaseParameters const&)
(databasecorebackend.cpp:769)
==32332==    by 0x5181716:
Digikam::ThumbnailDatabaseAccess::checkReadyForUse(Digikam::InitializationObserver*)
(thumbnaildatabaseaccess.cpp:216)
==32332==
==32332== LEAK SUMMARY:
==32332==    definitely lost: 8,000 bytes in 690 blocks
==32332==    indirectly lost: 9,358 bytes in 81 blocks
==32332==      possibly lost: 391,691 bytes in 1,652 blocks
==32332==    still reachable: 336,972 bytes in 4,708 blocks
==32332==         suppressed: 0 bytes in 0 blocks
==32332== Reachable blocks (those to which a pointer was found) are not shown.
==32332== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==32332==
==32332== For counts of detected and suppressed errors, rerun with: -v
==32332== ERROR SUMMARY: 957 errors from 957 contexts (suppressed: 2 from 2)
[gilles@localhost tests]$

So i suspect this entry to be fully relevant of Sqlite implementation as it's
have already reported as UPSTREAM #329697

Note the difference : #329697 is about libsqlite:: sqlite3MemCompare() when
this file is about libsqlite::sqlite3MemMalloc().

#329697 have been fixed with a patch release of libsqlite has it's explained in
this Ubuntu report :

https://bugs.launchpad.net/ubuntu/+source/sqlite3/+bug/1317449

- Packagers and Users must update libsqlite to last stable 3.8.5
(http://www.sqlite.org/news.html)
- Users must try to run FaceManagement again and look if memory leak still
present or not.
- If yes, this file must be reported as UPSTREAM to SQLite bug tracker.

Giles Caulier

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

https://bugs.kde.org/show_bug.cgi?id=323888

Mathieu Clabaut <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[hidden email]

--- Comment #90 from Mathieu Clabaut <[hidden email]> ---
For information, the problem still present with digikam 4.1.0 and sqlite 3.8.5.

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

https://bugs.kde.org/show_bug.cgi?id=323888

Gilles Caulier <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |UPSTREAM
             Status|CONFIRMED                   |RESOLVED

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Nico Kruber]

https://bugs.kde.org/show_bug.cgi?id=323888

Nico Kruber <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[hidden email]

--- Comment #91 from Nico Kruber <[hidden email]> ---
if it really is fixed upstream, can you link the commit with the patch that
fixes this issue if there is one?

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

https://bugs.kde.org/show_bug.cgi?id=323888

--- Comment #92 from Gilles Caulier <[hidden email]> ---
Nico,

I never said that problem is already fixed as UPSTREAM fixes

I closed this file as UPSTREAM because i suspect that problem is located in
libsqlite.

This problem must be reported to SQlite bugzilla to be analysed by Sqlite team.

It can be a problem also in Qt sqlite plugin, but i'm not sure...

Gilles Caulier

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel