[digikam] [Bug 326525] New: Severe memory leak during maintainance scan for rebuild thumbnails

[Gilles Caulier-4]

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

--- Comment #19 from Gilles Caulier <[hidden email]> ---
Important : I suspect that a lots of bug-reports are relevant of PGF codec
bugs. For ex in face management, we have serious and stranges crashes when face
thumbs data are set/get to database.

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

[Rex Dieter]

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

--- Comment #20 from Rex Dieter <[hidden email]> ---
Re: comment #14

I can confirm https://git.reviewboard.kde.org/r/110649/ landed in kde-runtime
4.11 branch

--
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=326525

--- Comment #21 from Gilles Caulier <[hidden email]> ---
Thanks Rex,

Sadly, under my Linux, i run KDE 4.10.

But under my MacBook, it's last KDE 4.11. So i can add try to make a WebP
wrapper for thumb database, using KImageIO plugin.

Gilles

--
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=326525

--- Comment #22 from Gilles Caulier <[hidden email]> ---
Note : another advantage to use WebP with digiKam thumbs DB is to drop
definitively LibPGF code (yes another one!), and to remove another external
dependency...

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=326525

--- Comment #23 from Gilles Caulier <[hidden email]> ---
There is a simple test to confirm that memory leak is relevant of PGF codec
implementation.

In digiKam thumbnails database interface, we have code to change image
compression format to store in DB. Currently PGF is hardcoded in this line :

https://projects.kde.org/projects/extragear/graphics/digikam/repository/revisions/master/entry/libs/threadimageio/thumbnailcreator.cpp#L687

Just change :

dbInfo.type             = DatabaseThumbnail::PGF;

by :

dbInfo.type             = DatabaseThumbnail::JPEG;

... and recompile and install digiKam. Re-run maintenance tool and look if
memory leak still here.

Note, with this change, JPEG will be used instead PGF to store thumbnails in
DB.

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=326525

Gilles Caulier <[hidden email]> changed:

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

--- Comment #24 from Gilles Caulier <[hidden email]> ---
Marcel,

Running digiKam into valgrind give me these backtraces :

There is a lots of memory allocation into ThumbnailImageCatcher. This is not a
memory leak. When digiKam is stopped, all memory is free properly. Look below :

==7668== 7,128,144 bytes in 15,102 blocks are possibly lost in loss record
25,758 of 25,761
==7668==    at 0x4C285F1: operator new(unsigned long) (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==7668==    by 0x80B40EE:
QList<Digikam::ThumbnailImageCatcher::Private::CatcherResult>::node_construct(QList<Digikam::ThumbnailImageCatcher::Private::CatcherResult>::Node*,
Digikam::ThumbnailImageCatcher::Private::CatcherResult const&) (qlist.h:372)
==7668==    by 0x80B2D2D:
QList<Digikam::ThumbnailImageCatcher::Private::CatcherResult>::append(Digikam::ThumbnailImageCatcher::Private::CatcherResult
const&) (qlist.h:512)
==7668==    by 0x80B197E:
QList<Digikam::ThumbnailImageCatcher::Private::CatcherResult>::operator<<(Digikam::ThumbnailImageCatcher::Private::CatcherResult
const&) (qlist.h:334)
==7668==    by 0x80AFC76:
Digikam::ThumbnailImageCatcher::slotThumbnailLoaded(Digikam::LoadingDescription
const&, QImage const&) (thumbnailloadthread.cpp:1142)
==7668==    by 0x80ABB70:
Digikam::ThumbnailImageCatcher::qt_static_metacall(QObject*, QMetaObject::Call,
int, void**) (thumbnailloadthread.moc:172)
==7668==    by 0xF9AE8CE: QMetaObject::activate(QObject*, QMetaObject const*,
int, void**) (in /usr/lib64/libQtCore.so.4.8.5)
==7668==    by 0x808FCEA:
Digikam::LoadSaveThread::signalThumbnailLoaded(Digikam::LoadingDescription
const&, QImage const&) (loadsavethread.moc:174)
==7668==    by 0x8090538:
Digikam::LoadSaveThread::thumbnailLoaded(Digikam::LoadingDescription const&,
QImage const&) (loadsavethread.cpp:204)
==7668==    by 0x80ADFEC:
Digikam::ThumbnailLoadThread::thumbnailLoaded(Digikam::LoadingDescription
const&, QImage const&) (thumbnailloadthread.cpp:684)
==7668==    by 0x80B5565: Digikam::ThumbnailLoadingTask::execute()
(thumbnailtask.cpp:229)
==7668==    by 0x809029C: Digikam::LoadSaveThread::run()
(loadsavethread.cpp:136)
==7668==
==7668== 335,044,008 bytes in 709,839 blocks are possibly lost in loss record
25,761 of 25,761
==7668==    at 0x4C285F1: operator new(unsigned long) (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==7668==    by 0x80B40EE:
QList<Digikam::ThumbnailImageCatcher::Private::CatcherResult>::node_construct(QList<Digikam::ThumbnailImageCatcher::Private::CatcherResult>::Node*,
Digikam::ThumbnailImageCatcher::Private::CatcherResult const&) (qlist.h:372)
==7668==    by 0x80B2D59:
QList<Digikam::ThumbnailImageCatcher::Private::CatcherResult>::append(Digikam::ThumbnailImageCatcher::Private::CatcherResult
const&) (qlist.h:521)
==7668==    by 0x80B197E:
QList<Digikam::ThumbnailImageCatcher::Private::CatcherResult>::operator<<(Digikam::ThumbnailImageCatcher::Private::CatcherResult
const&) (qlist.h:334)
==7668==    by 0x80AFC76:
Digikam::ThumbnailImageCatcher::slotThumbnailLoaded(Digikam::LoadingDescription
const&, QImage const&) (thumbnailloadthread.cpp:1142)
==7668==    by 0x80ABB70:
Digikam::ThumbnailImageCatcher::qt_static_metacall(QObject*, QMetaObject::Call,
int, void**) (thumbnailloadthread.moc:172)
==7668==    by 0xF9AE8CE: QMetaObject::activate(QObject*, QMetaObject const*,
int, void**) (in /usr/lib64/libQtCore.so.4.8.5)
==7668==    by 0x808FCEA:
Digikam::LoadSaveThread::signalThumbnailLoaded(Digikam::LoadingDescription
const&, QImage const&) (loadsavethread.moc:174)
==7668==    by 0x8090538:
Digikam::LoadSaveThread::thumbnailLoaded(Digikam::LoadingDescription const&,
QImage const&) (loadsavethread.cpp:204)
==7668==    by 0x80ADFEC:
Digikam::ThumbnailLoadThread::thumbnailLoaded(Digikam::LoadingDescription
const&, QImage const&) (thumbnailloadthread.cpp:684)
==7668==    by 0x80B5565: Digikam::ThumbnailLoadingTask::execute()
(thumbnailtask.cpp:229)
==7668==    by 0x809029C: Digikam::LoadSaveThread::run()
(loadsavethread.cpp:136)

Typically, ThumbnailImageCatcher is called in ThumbsTask from maintenance tool
:

https://projects.kde.org/projects/extragear/graphics/digikam/repository/revisions/master/entry/utilities/maintenance/thumbstask.cpp#L76

and ThumbnailImageCatcher store thumbs in a QList cache here, without limit :

https://projects.kde.org/projects/extragear/graphics/digikam/repository/revisions/master/entry/libs/threadimageio/thumbnailloadthread.cpp#L1142

... until memory is full...

Question : there is something missing in ThumbsTask::run() to prevent this
problem ?

Gilles

--
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=326525

Gilles Caulier <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rschweizer@schweizer-inform
                   |                            |atik.ch

--- Comment #25 from Gilles Caulier <[hidden email]> ---
Raphael,

In same way that thumb cache memory allocation problem from digiKam core, we
have also a memory problems with PGF codec :

memory leak :

==7668== 2,208 bytes in 6 blocks are possibly lost in loss record 25,044 of
25,761
==7668==    at 0x4C26DFF: calloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==7668==    by 0x4011008: _dl_allocate_tls (in /usr/lib64/ld-2.17.so)
==7668==    by 0xFD008B8: pthread_create@@GLIBC_2.2.5 (in
/usr/lib64/libpthread-2.17.so)
==7668==    by 0x10AAACBD: ??? (in /usr/lib64/libgomp.so.1.0.0)
==7668==    by 0x80BC413: CPGFImage::WriteHeader(CPGFStream*)
(PGFimage.cpp:924)
==7668==    by 0x80BCE86: CPGFImage::Write(CPGFStream*, unsigned int*, bool
(*)(double, bool, void*), void*) (PGFimage.cpp:1145)
==7668==    by 0x80C876E: Digikam::PGFUtils::writePGFImageDataToStream(QImage
const&, CPGFStream&, int, unsigned int&, bool) (pgfutils.cpp:280)
==7668==    by 0x80C7BF0: Digikam::PGFUtils::writePGFImageData(QImage const&,
QByteArray&, int, bool) (pgfutils.cpp:178)
==7668==    by 0x80A8E99:
Digikam::ThumbnailCreator::storeInDatabase(Digikam::ThumbnailInfo const&,
Digikam::ThumbnailImage const&) const (thumbnailcreator.cpp:695)
==7668==    by 0x80A6818: Digikam::ThumbnailCreator::load(QString const&, QRect
const&, bool) const (thumbnailcreator.cpp:267)
==7668==    by 0x80A63C5: Digikam::ThumbnailCreator::load(QString const&) const
(thumbnailcreator.cpp:199)
==7668==    by 0x80B51F9: Digikam::ThumbnailLoadingTask::execute()
(thumbnailtask.cpp:172)

memory corruption :

==7668== Thread 16:
==7668== Conditional jump or move depends on uninitialised value(s)
==7668==    at 0x80C47CF: CSubband::Quantize(int) (Subband.cpp:132)
==7668==    by 0x80C5772: CWaveletTransform::ForwardTransform(int, int)
(WaveletTransform.cpp:164)
==7668==    by 0x80C3023: CPGFImage::WriteHeader(CPGFStream*) [clone
._omp_fn.0] (PGFimage.cpp:949)
==7668==    by 0x10AAA809: ??? (in /usr/lib64/libgomp.so.1.0.0)
==7668==    by 0xFCFFD17: start_thread (in /usr/lib64/libpthread-2.17.so)
==7668==    by 0x10FB67CC: clone (in /usr/lib64/libc-2.17.so)
==7668==
==7668== Conditional jump or move depends on uninitialised value(s)
==7668==    at 0x80C4828: CSubband::Quantize(int) (Subband.cpp:134)
==7668==    by 0x80C5772: CWaveletTransform::ForwardTransform(int, int)
(WaveletTransform.cpp:164)
==7668==    by 0x80C3023: CPGFImage::WriteHeader(CPGFStream*) [clone
._omp_fn.0] (PGFimage.cpp:949)
==7668==    by 0x10AAA809: ??? (in /usr/lib64/libgomp.so.1.0.0)
==7668==    by 0xFCFFD17: start_thread (in /usr/lib64/libpthread-2.17.so)
==7668==    by 0x10FB67CC: clone (in /usr/lib64/libc-2.17.so)
==7668==
==7668== Thread 14:
==7668== Conditional jump or move depends on uninitialised value(s)
==7668==    at 0x80B8979: CEncoder::WriteValue(CSubband*, int)
(Encoder.cpp:327)
==7668==    by 0x80B8640: CEncoder::Partition(CSubband*, int, int, int, int)
(Encoder.cpp:258)
==7668==    by 0x80C49FB: CSubband::ExtractTile(CEncoder&, bool, unsigned int,
unsigned int) (Subband.cpp:185)
==7668==    by 0x80BC9C4: CPGFImage::WriteLevel() (PGFimage.cpp:1029)
==7668==    by 0x80BCD55: CPGFImage::WriteImage(CPGFStream*, bool (*)(double,
bool, void*), void*) (PGFimage.cpp:1103)
==7668==    by 0x80BCEA1: CPGFImage::Write(CPGFStream*, unsigned int*, bool
(*)(double, bool, void*), void*) (PGFimage.cpp:1148)
==7668==    by 0x80C876E: Digikam::PGFUtils::writePGFImageDataToStream(QImage
const&, CPGFStream&, int, unsigned int&, bool) (pgfutils.cpp:280)
==7668==    by 0x80C7BF0: Digikam::PGFUtils::writePGFImageData(QImage const&,
QByteArray&, int, bool) (pgfutils.cpp:178)
==7668==    by 0x80A8E99:
Digikam::ThumbnailCreator::storeInDatabase(Digikam::ThumbnailInfo const&,
Digikam::ThumbnailImage const&) const (thumbnailcreator.cpp:695)
==7668==    by 0x80A6818: Digikam::ThumbnailCreator::load(QString const&, QRect
const&, bool) const (thumbnailcreator.cpp:267)
==7668==    by 0x80A63C5: Digikam::ThumbnailCreator::load(QString const&) const
(thumbnailcreator.cpp:199)
==7668==    by 0x80B51F9: Digikam::ThumbnailLoadingTask::execute()
(thumbnailtask.cpp:172)
==7668==
==7668== Conditional jump or move depends on uninitialised value(s)
==7668==    at 0x80B8979: CEncoder::WriteValue(CSubband*, int)
(Encoder.cpp:327)
==7668==    by 0x80B872D: CEncoder::Partition(CSubband*, int, int, int, int)
(Encoder.cpp:283)
==7668==    by 0x80C49FB: CSubband::ExtractTile(CEncoder&, bool, unsigned int,
unsigned int) (Subband.cpp:185)
==7668==    by 0x80BC9C4: CPGFImage::WriteLevel() (PGFimage.cpp:1029)
==7668==    by 0x80BCD55: CPGFImage::WriteImage(CPGFStream*, bool (*)(double,
bool, void*), void*) (PGFimage.cpp:1103)
==7668==    by 0x80BCEA1: CPGFImage::Write(CPGFStream*, unsigned int*, bool
(*)(double, bool, void*), void*) (PGFimage.cpp:1148)
==7668==    by 0x80C876E: Digikam::PGFUtils::writePGFImageDataToStream(QImage
const&, CPGFStream&, int, unsigned int&, bool) (pgfutils.cpp:280)
==7668==    by 0x80C7BF0: Digikam::PGFUtils::writePGFImageData(QImage const&,
QByteArray&, int, bool) (pgfutils.cpp:178)
==7668==    by 0x80A8E99:
Digikam::ThumbnailCreator::storeInDatabase(Digikam::ThumbnailInfo const&,
Digikam::ThumbnailImage const&) const (thumbnailcreator.cpp:695)
==7668==    by 0x80A6818: Digikam::ThumbnailCreator::load(QString const&, QRect
const&, bool) const (thumbnailcreator.cpp:267)
==7668==    by 0x80A63C5: Digikam::ThumbnailCreator::load(QString const&) const
(thumbnailcreator.cpp:199)
==7668==    by 0x80B51F9: Digikam::ThumbnailLoadingTask::execute()
(thumbnailtask.cpp:172)

Sure, memory leak with PGF codec is lesser than thumb cache from digiKam core,
but it exists...

See my comments #16 about Coverity Scan source code reports
(https://scan.coverity.com/) which are fully relevant of this memory
problems...

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=326525

--- Comment #26 from Gilles Caulier <[hidden email]> ---
Rex,

libpgf maintainer is now in CC. Wait and see...

Gilles

--
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

[eldk]

Thank you Gilles,

I will try this and the compilation digikam with internal PGF.

Give you the result today or monday.

Greatings,

Eric

Le samedi 26 octobre 2013 à 05:09 +0000, Gilles Caulier a écrit :

> https://bugs.kde.org/show_bug.cgi?id=326525
>
> --- Comment #23 from Gilles Caulier <[hidden email]> ---
> There is a simple test to confirm that memory leak is relevant of PGF codec
> implementation.
>
> In digiKam thumbnails database interface, we have code to change image
> compression format to store in DB. Currently PGF is hardcoded in this line :
>
> https://projects.kde.org/projects/extragear/graphics/digikam/repository/revisions/master/entry/libs/threadimageio/thumbnailcreator.cpp#L687
>
> Just change :
>
> dbInfo.type             = DatabaseThumbnail::PGF;
>
> by :
>
> dbInfo.type             = DatabaseThumbnail::JPEG;
>
> ... and recompile and install digiKam. Re-run maintenance tool and look if
> memory leak still here.
>
> Note, with this change, JPEG will be used instead PGF to store thumbnails in
> DB.
>
> Gilles Caulier
>

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[eldk]

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

--- Comment #27 from [hidden email] ---
Thank you Gilles,

I will try this and the compilation digikam with internal PGF.

Give you the result today or monday.

Greatings,

Eric

Le samedi 26 octobre 2013 à 05:09 +0000, Gilles Caulier a écrit :

> https://bugs.kde.org/show_bug.cgi?id=326525
>
> --- Comment #23 from Gilles Caulier <[hidden email]> ---
> There is a simple test to confirm that memory leak is relevant of PGF codec
> implementation.
>
> In digiKam thumbnails database interface, we have code to change image
> compression format to store in DB. Currently PGF is hardcoded in this line :
>
> https://projects.kde.org/projects/extragear/graphics/digikam/repository/revisions/master/entry/libs/threadimageio/thumbnailcreator.cpp#L687
>
> Just change :
>
> dbInfo.type             = DatabaseThumbnail::PGF;
>
> by :
>
> dbInfo.type             = DatabaseThumbnail::JPEG;
>
> ... and recompile and install digiKam. Re-run maintenance tool and look if
> memory leak still here.
>
> Note, with this change, JPEG will be used instead PGF to store thumbnails in
> DB.
>
> 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

[Marcel Wiesweg]

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

--- Comment #28 from Marcel Wiesweg <[hidden email]> ---
Re Memory leak:
Please use a dedicated thumbnail load thread (*) for the catcher. The logic
depends on a enqueue being called after immediately after requesting a
thumbnail, it breaks if the thread receives requests from many places
concurrently so that the "last request" is undefined when calling enqueue.

Re PGF:
Even if we switch thumbnail creation to another algorithm, we
a) need to continue providing PGF read support for those gigabytes of
thumbnails on our users machines
b) we break backwards compatibility to use a new thumbnail db with an older
version, so it should be done only with a major release

(*)
    ThumbnailLoadThread* thumbnailLoadThread = new ThumbnailLoadThread;
    thumbnailLoadThread->setPixmapRequested(false);
   
thumbnailLoadThread->setThumbnailSize(ThumbnailLoadThread::maximumThumbnailSize());

Note that switching off pixmap generation for this thread also avoids flooding
the cache for the main UI.

--
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=326525

--- Comment #29 from Gilles Caulier <[hidden email]> ---
Git commit 21eb0ed5e895742228d789077d6590af9ff7ab36 by Gilles Caulier.
Committed on 26/10/2013 at 21:18.
Pushed by cgilles into branch 'master'.

Fix memory leak with ThumbnailLoadThread instance passed to
ThumbnailImageCatcher.
Pass a dedicated instace of thread to cacher, following Marcel tips.
FIXED-IN: 4.0.0

M  +6    -4    utilities/maintenance/thumbstask.cpp

http://commits.kde.org/digikam/21eb0ed5e895742228d789077d6590af9ff7ab36

--
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=326525

Gilles Caulier <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Version Fixed In|                            |4.0.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=326525

--- Comment #30 from Gilles Caulier <[hidden email]> ---
Marcel,

Thanks for your tips. Huge memory leak due to ThumbnailImageThread instance is
now fixed.

It still PGF codec memory leak. I will wait feedback of Raphael Schweizer from
LibPGF team before to take a decision about to continue to use or not PGF as
Thumb DB image codec.

I know that a change like this require a backward compatibility until few
release... If PGF implementation can be fixed,, it will be great for the
future. I hope that PGF team is not dead...

Gilles

--
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

[Raphael Schweizer]

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

--- Comment #31 from Raphael Schweizer <[hidden email]> ---
At last, news from the libPGF team: we will immediately look into this memory
leak problem.

@Gilles: please apologize for the long silence. Unlike the coverity reports
your contributions towards CMake and better binary compatibility are not lost
nor forgotten. We started renewed efforts to migrate to CMake last week and
will (hopefully soon) have good news. I'll also check the indicated coverity
reports.

Thanks, Raphael

--
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=326525

--- Comment #32 from Gilles Caulier <[hidden email]> ---
Hi Raphael,

Great to hear you in this room...

I don't know if you have a Coverity Scan account to be able to check reports. I
send you an invitation using your email, like this, you will be able to review
all information from Coverity web interface.

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=326525

--- Comment #33 from Gilles Caulier <[hidden email]> ---
Raphael,

Coverity said "The following email addresses are invalid:
[hidden email]"

Probably it don't like minus in your email domain name...

Please use this page :

https://scan.coverity.com/projects

Search "digiKam" entry and use "Add me to project" link...

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=326525

--- Comment #34 from Gilles Caulier <[hidden email]> ---
Raphael,

About my previous libpgf contributions not yet release, i recommend to use
Cmake port in priority. Forget BC branch for the moment. I will replay my fixes
in this branch later, including these future memory fixes. Also i want to pass
more test about BC code from libpgf.

Cmake branch do not touch in-deep libpgf implementation. Most of code are cmake
scripts. It safe to release. BC branch can come later...

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=326525

--- Comment #35 from Gilles Caulier <[hidden email]> ---
Raphael,

As you can see in comment #13, OpenMp support from libpgf do not work  in
digiKam.

PGF codec in digiKam will run into a separated thread (QThread class :
http://qt-project.org/doc/qt-4.8/qthread.html) and when libpgf paralellize
decoding to get PGF thumbnail from database, it crash violently.

I written simple a code outside wholde digiKam implementation to reproduce the
problem :

https://projects.kde.org/projects/extragear/graphics/digikam/repository/revisions/master/entry/tests/qtpgftest.cpp

When libpgf do not use OpenMp, all work fine.

I can give you GDB backtrace after that you fix memory corruption/leak
previously listed here. Perhaps openmp has rise up some side-effects.

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

[Raphael Schweizer]

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

--- Comment #36 from Raphael Schweizer <[hidden email]> ---
Gilles,

I synced our internal repository with SourceForce, now containing at least a
bunch of ROI related out of bounds errors less. This will, however, not fix the
issue reported here. I'll keep you posted on our progress.

Raphael Schweizer

--
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