memory leak by Mr Valgrind

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

memory leak by Mr Valgrind

Gilles Caulier-4
Francesco,

I found this leak in ICC color management code. I use liblcms version 2.1

==13505== 3,376 bytes in 1 blocks are possibly lost in loss record
9,965 of 10,328
==13505==    at 0x4C256DD: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==13505==    by 0x77049AA: _cmsCreateProfilePlaceholder (in
/usr/lib64/liblcms.so.1.0.19)
==13505==    by 0x7704A0F: _cmsCreateProfileFromMemPlaceholder (in
/usr/lib64/liblcms.so.1.0.19)
==13505==    by 0x77084F5: cmsOpenProfileFromMem (in
/usr/lib64/liblcms.so.1.0.19)
==13505==    by 0x7B52DC7: Digikam::IccProfile::open() (iccprofile.cpp:332)
==13505==    by 0x7B50A6D:
Digikam::IccManager::displayProfile(QWidget*) (iccmanager.cpp:387)
==13505==    by 0x7C90C90:
Digikam::ThumbnailLoadThread::ThumbnailLoadThreadPriv::createLoadingDescription(QString
const&, int, bool) (thumbnailloadthread.cpp:332)
==13505==    by 0x7C91051:
Digikam::ThumbnailLoadThread::ThumbnailLoadThreadPriv::makeDescriptions(QStringList
const&, int) (thumbnailloadthread.cpp:399)
==13505==    by 0x7C91D71:
Digikam::ThumbnailLoadThread::pregenerateGroup(QStringList const&,
int) (thumbnailloadthread.cpp:611)
==13505==    by 0x835365F:
Digikam::ImageThumbnailModel::preloadThumbnails(QList<Digikam::ImageInfo>
const&) (imagethumbnailmodel.cpp:180)
==13505==    by 0x8353894:
Digikam::ImageThumbnailModel::preloadAllThumbnails()
(imagethumbnailmodel.cpp:201)
==13505==    by 0x8352DBF:
Digikam::ImageThumbnailModel::qt_metacall(QMetaObject::Call, int,
void**) (imagethumbnailmodel.moc:97)

Gilles
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel
Reply | Threaded
Open this post in threaded view
|

Re: memory leak by Mr Valgrind

Gilles Caulier-4
Marcel, i found this new allocation from image delegate class not
cleaned in destructor :

==14218== 496 (48 direct, 448 indirect) bytes in 1 blocks are
definitely lost in loss record 9,323 of 10,393
==14218==    at 0x4C251D7: operator new(unsigned long) (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==14218==    by 0x62230A:
Digikam::DigikamImageDelegatePrivate::init(Digikam::DigikamImageDelegate*,
Digikam::ImageCategorizedView*) (digikamimagedelegate.cpp:52)
==14218==    by 0x62240E:
Digikam::DigikamImageDelegate::DigikamImageDelegate(Digikam::ImageCategorizedView*)
(digikamimagedelegate.cpp:64)
==14218==    by 0x61D0DC:
Digikam::DigikamImageView::DigikamImageView(QWidget*)
(digikamimageview.cpp:98)
==14218==    by 0x6772EA: Digikam::StackedView::StackedView(QWidget*)
(stackedview.cpp:101)
==14218==    by 0x67A6B3: Digikam::DigikamView::DigikamView(QWidget*,
Digikam::DigikamModelCollection*) (digikamview.cpp:203)
==14218==    by 0x59145D: Digikam::DigikamApp::setupView() (digikamapp.cpp:517)
==14218==    by 0x58FF9C: Digikam::DigikamApp::DigikamApp() (digikamapp.cpp:257)
==14218==    by 0x6CB5D2: main (main.cpp:188)

Gillles
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel
Reply | Threaded
Open this post in threaded view
|

Re: memory leak by Mr Valgrind

Gilles Caulier-4
Marcel,

Another one in Collection Manager :

==7873== 112 bytes in 2 blocks are possibly lost in loss record 8,145 of 10,147
==7873==    at 0x4C251D7: operator new(unsigned long) (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==7873==    by 0x8260539:
Digikam::CollectionManager::updateLocations()
(collectionmanager.cpp:1559)
==7873==    by 0x825C73C: Digikam::CollectionManager::refresh()
(collectionmanager.cpp:763)
==7873==    by 0x8266F95:
Digikam::DatabaseAccess::checkReadyForUse(Digikam::InitializationObserver*)
(databaseaccess.cpp:314)
==7873==    by 0x5EDE44: Digikam::ScanController::run() (scancontroller.cpp:656)
==7873==    by 0xC6DA1E4: ??? (in /usr/lib64/libQtCore.so.4.7.4)
==7873==    by 0xCB00D24: start_thread (in /lib64/libpthread-2.12.1.so)
==7873==    by 0xDAF423C: clone (in /lib64/libc-2.12.1.so)

Gilles Caulier
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel
Reply | Threaded
Open this post in threaded view
|

Re: memory leak by Mr Valgrind

Gilles Caulier-4
Marcel,

This time, it's under face detection process. I run few few seconds,
some image are parsed. I press cancel in progress manager, and digiKam
crash in thread management classes :

digikam(11291)/digikam (core) Digikam::DMetadata::getIccProfile: Exif
color-space tag is sRGB. Using default sRGB ICC profile.
digikam(11291)/digikam (core) Digikam::DetectionWorker::process: Found
0 faces in "DSC00012.ARW" QSize(1080, 1616) QSize(2858, 4288)
digikam(11291)/digikam (core) Digikam::DetectionWorker::process: Found
0 faces in "DSC00013.ARW" QSize(1080, 1616) QSize(2858, 4288)
digikam(11291)/digikam (core) Digikam::DMetadata::getIccProfile: Exif
color-space tag is sRGB. Using default sRGB ICC profile.
digikam(11291)/digikam (core) Digikam::DetectionWorker::process: Found
1 faces in "DSC00014.ARW" QSize(1616, 1080) QSize(4288, 2858)
digikam(11291)/digikam (core) Digikam::DetectionWorker::process: Found
0 faces in "DSC00015.ARW" QSize(1616, 1080) QSize(4288, 2858)
digikam(11291)/digikam (core)
Digikam::FacePipeline::FacePipelinePriv::checkFinished: Check for
finish:  51 packages, 0 infos to filter, hasFinished() false
==11291== Thread 4:
==11291== Invalid read of size 8
==11291==    at 0xC7D68A0: QObject::moveToThread(QThread*) (in
/usr/lib64/libQtCore.so.4.7.4)
==11291==    by 0x7CBA95B: Digikam::ParkingThread::run() (threadmanager.cpp:130)
==11291==    by 0xC6DA1E4: ??? (in /usr/lib64/libQtCore.so.4.7.4)
==11291==    by 0xCB00D24: start_thread (in /lib64/libpthread-2.12.1.so)
==11291==    by 0xDAF423C: clone (in /lib64/libc-2.12.1.so)
==11291==  Address 0x3c110f68 is 8 bytes inside a block of size 40 free'd
==11291==    at 0x4C244CE: operator delete(void*) (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==11291==    by 0x6BF721: Digikam::DatabaseWriter::~DatabaseWriter()
(facepipeline_p.h:245)
==11291==    by 0x6BD5EB: Digikam::FacePipeline::~FacePipeline()
(facepipeline.cpp:1144)
==11291==    by 0x51DD06:
Digikam::FaceDetector::FaceDetectorPriv::~FaceDetectorPriv() (in
/usr/bin/digikam)
==11291==    by 0x51C9E4: Digikam::FaceDetector::~FaceDetector()
(facedetector.cpp:225)
==11291==    by 0x51CA53: Digikam::FaceDetector::~FaceDetector()
(facedetector.cpp:226)
==11291==    by 0xC7D88E7: QObject::event(QEvent*) (in
/usr/lib64/libQtCore.so.4.7.4)
==11291==    by 0xB44C793:
QApplicationPrivate::notify_helper(QObject*, QEvent*) (in
/usr/lib64/libQtGui.so.4.7.4)
==11291==    by 0xB451369: QApplication::notify(QObject*, QEvent*) (in
/usr/lib64/libQtGui.so.4.7.4)
==11291==    by 0xAE6EE05: KApplication::notify(QObject*, QEvent*) (in
/usr/lib64/libkdeui.so.5.6.0)
==11291==    by 0xC7C431B: QCoreApplication::notifyInternal(QObject*,
QEvent*) (in /usr/lib64/libQtCore.so.4.7.4)
==11291==    by 0xC7C7B24:
QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*)
(in /usr/lib64/libQtCore.so.4.7.4)
==11291==
==11291== Invalid read of size 8
==11291==    at 0xC7D68A4: QObject::moveToThread(QThread*) (in
/usr/lib64/libQtCore.so.4.7.4)
==11291==    by 0x7CBA95B: Digikam::ParkingThread::run() (threadmanager.cpp:130)
==11291==    by 0xC6DA1E4: ??? (in /usr/lib64/libQtCore.so.4.7.4)
==11291==    by 0xCB00D24: start_thread (in /lib64/libpthread-2.12.1.so)
==11291==    by 0xDAF423C: clone (in /lib64/libc-2.12.1.so)
==11291==  Address 0x40 is not stack'd, malloc'd or (recently) free'd
==11291==
KCrash: Application 'digikam' crashing...
KCrash: Attempting to start /usr/lib64/kde4/libexec/drkonqi from kdeinit
sock_file=/home/gilles/.kde4/socket-localhost.localdomain/kdeinit4__0
==11291== Thread 11:
==11291== Invalid read of size 8
==11291==    at 0xC7D54B0: QObject::thread() const (in
/usr/lib64/libQtCore.so.4.7.4)
==11291==    by 0x7CBA7F9:
Digikam::ParkingThread::moveToCurrentThread(QObject*)
(threadmanager.cpp:98)
==11291==    by 0x7CB9D2B: Digikam::WorkerObjectRunnable::run()
(threadmanager.cpp:178)
==11291==    by 0xC6CF057: ??? (in /usr/lib64/libQtCore.so.4.7.4)
==11291==    by 0xC6DA1E4: ??? (in /usr/lib64/libQtCore.so.4.7.4)
==11291==    by 0xCB00D24: start_thread (in /lib64/libpthread-2.12.1.so)
==11291==    by 0xDAF423C: clone (in /lib64/libc-2.12.1.so)
==11291==  Address 0x3c110f68 is 8 bytes inside a block of size 40 free'd
==11291==    at 0x4C244CE: operator delete(void*) (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==11291==    by 0x6BF721: Digikam::DatabaseWriter::~DatabaseWriter()
(facepipeline_p.h:245)
==11291==    by 0x6BD5EB: Digikam::FacePipeline::~FacePipeline()
(facepipeline.cpp:1144)
==11291==    by 0x51DD06:
Digikam::FaceDetector::FaceDetectorPriv::~FaceDetectorPriv() (in
/usr/bin/digikam)
==11291==    by 0x51C9E4: Digikam::FaceDetector::~FaceDetector()
(facedetector.cpp:225)
==11291==    by 0x51CA53: Digikam::FaceDetector::~FaceDetector()
(facedetector.cpp:226)
==11291==    by 0xC7D88E7: QObject::event(QEvent*) (in
/usr/lib64/libQtCore.so.4.7.4)
==11291==    by 0xB44C793:
QApplicationPrivate::notify_helper(QObject*, QEvent*) (in
/usr/lib64/libQtGui.so.4.7.4)
==11291==    by 0xB451369: QApplication::notify(QObject*, QEvent*) (in
/usr/lib64/libQtGui.so.4.7.4)
==11291==    by 0xAE6EE05: KApplication::notify(QObject*, QEvent*) (in
/usr/lib64/libkdeui.so.5.6.0)
==11291==    by 0xC7C431B: QCoreApplication::notifyInternal(QObject*,
QEvent*) (in /usr/lib64/libQtCore.so.4.7.4)
==11291==    by 0xC7C7B24:
QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*)
(in /usr/lib64/libQtCore.so.4.7.4)
==11291==
==11291== Invalid read of size 8
==11291==    at 0xC7D54B4: QObject::thread() const (in
/usr/lib64/libQtCore.so.4.7.4)
==11291==    by 0x7CBA7F9:
Digikam::ParkingThread::moveToCurrentThread(QObject*)
(threadmanager.cpp:98)
==11291==    by 0x7CB9D2B: Digikam::WorkerObjectRunnable::run()
(threadmanager.cpp:178)
==11291==    by 0xC6CF057: ??? (in /usr/lib64/libQtCore.so.4.7.4)
==11291==    by 0xC6DA1E4: ??? (in /usr/lib64/libQtCore.so.4.7.4)
==11291==    by 0xCB00D24: start_thread (in /lib64/libpthread-2.12.1.so)
==11291==    by 0xDAF423C: clone (in /lib64/libc-2.12.1.so)
==11291==  Address 0x40 is not stack'd, malloc'd or (recently) free'd
==11291==
Unable to start Dr. Konqi

Gilles Caulier
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel
Reply | Threaded
Open this post in threaded view
|

Re: memory leak by Mr Valgrind

Gilles Caulier-4
Andi,

In AdvanceRename, 3 new allocations are not deleted :

==11291== 24 bytes in 1 blocks are possibly lost in loss record 20,227
of 107,031
==11291==    at 0x4C251D7: operator new(unsigned long) (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==11291==    by 0x6EE226:
Digikam::DatabaseOption::registerKeysCollection()
(databaseoption.cpp:98)
==11291==    by 0x6EE075: Digikam::DatabaseOption::DatabaseOption()
(databaseoption.cpp:88)
==11291==    by 0x6D6239: Digikam::Parser::Parser() (parser.cpp:76)
==11291==    by 0x6DC71F:
Digikam::DefaultRenameParser::DefaultRenameParser()
(defaultrenameparser.cpp:31)
==11291==    by 0x6D1237:
Digikam::AdvancedRenameManager::setParserType(Digikam::AdvancedRenameManager::ParserType)
(advancedrenamemanager.cpp:178)
==11291==    by 0x6D119B:
Digikam::AdvancedRenameManager::setWidget(Digikam::AdvancedRenameWidget*)
(advancedrenamemanager.cpp:165)
==11291==    by 0x71FD94:
Digikam::QueueSettingsView::QueueSettingsView(QWidget*)
(queuesettingsview.cpp:156)
==11291==    by 0x704A5D: Digikam::QueueMgrWindow::setupUserArea()
(queuemgrwindow.cpp:223)
==11291==    by 0x7042EC: Digikam::QueueMgrWindow::QueueMgrWindow()
(queuemgrwindow.cpp:149)
==11291==    by 0x703B14:
Digikam::QueueMgrWindow::queueManagerWindow() (queuemgrwindow.cpp:107)
==11291==    by 0x596EA6: Digikam::DigikamApp::setupActions()
(digikamapp.cpp:914)
==11291==
==11291== 24 bytes in 1 blocks are possibly lost in loss record 20,228
of 107,031
==11291==    at 0x4C251D7: operator new(unsigned long) (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==11291==    by 0x6EE253:
Digikam::DatabaseOption::registerKeysCollection()
(databaseoption.cpp:99)
==11291==    by 0x6EE075: Digikam::DatabaseOption::DatabaseOption()
(databaseoption.cpp:88)
==11291==    by 0x6D6239: Digikam::Parser::Parser() (parser.cpp:76)
==11291==    by 0x6DC71F:
Digikam::DefaultRenameParser::DefaultRenameParser()
(defaultrenameparser.cpp:31)
==11291==    by 0x6D1237:
Digikam::AdvancedRenameManager::setParserType(Digikam::AdvancedRenameManager::ParserType)
(advancedrenamemanager.cpp:178)
==11291==    by 0x6D119B:
Digikam::AdvancedRenameManager::setWidget(Digikam::AdvancedRenameWidget*)
(advancedrenamemanager.cpp:165)
==11291==    by 0x71FD94:
Digikam::QueueSettingsView::QueueSettingsView(QWidget*)
(queuesettingsview.cpp:156)
==11291==    by 0x704A5D: Digikam::QueueMgrWindow::setupUserArea()
(queuemgrwindow.cpp:223)
==11291==    by 0x7042EC: Digikam::QueueMgrWindow::QueueMgrWindow()
(queuemgrwindow.cpp:149)
==11291==    by 0x703B14:
Digikam::QueueMgrWindow::queueManagerWindow() (queuemgrwindow.cpp:107)
==11291==    by 0x596EA6: Digikam::DigikamApp::setupActions()
(digikamapp.cpp:914)
==11291==
==11291== 24 bytes in 1 blocks are possibly lost in loss record 20,229
of 107,031
==11291==    at 0x4C251D7: operator new(unsigned long) (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==11291==    by 0x6EE280:
Digikam::DatabaseOption::registerKeysCollection()
(databaseoption.cpp:100)
==11291==    by 0x6EE075: Digikam::DatabaseOption::DatabaseOption()
(databaseoption.cpp:88)
==11291==    by 0x6D6239: Digikam::Parser::Parser() (parser.cpp:76)
==11291==    by 0x6DC71F:
Digikam::DefaultRenameParser::DefaultRenameParser()
(defaultrenameparser.cpp:31)
==11291==    by 0x6D1237:
Digikam::AdvancedRenameManager::setParserType(Digikam::AdvancedRenameManager::ParserType)
(advancedrenamemanager.cpp:178)
==11291==    by 0x6D119B:
Digikam::AdvancedRenameManager::setWidget(Digikam::AdvancedRenameWidget*)
(advancedrenamemanager.cpp:165)
==11291==    by 0x71FD94:
Digikam::QueueSettingsView::QueueSettingsView(QWidget*)
(queuesettingsview.cpp:156)
==11291==    by 0x704A5D: Digikam::QueueMgrWindow::setupUserArea()
(queuemgrwindow.cpp:223)
==11291==    by 0x7042EC: Digikam::QueueMgrWindow::QueueMgrWindow()
(queuemgrwindow.cpp:149)
==11291==    by 0x703B14:
Digikam::QueueMgrWindow::queueManagerWindow() (queuemgrwindow.cpp:107)
==11291==    by 0x596EA6: Digikam::DigikamApp::setupActions()
(digikamapp.cpp:914)

Gilles Caulier
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel
Reply | Threaded
Open this post in threaded view
|

Re: memory leak by Mr Valgrind

Marcel Wiesweg
In reply to this post by Gilles Caulier-4

> Marcel, i found this new allocation from image delegate class not
> cleaned in destructor :
>
> ==14218== 496 (48 direct, 448 indirect) bytes in 1 blocks are
> definitely lost in loss record 9,323 of 10,393
> ==14218==    at 0x4C251D7: operator new(unsigned long) (in
> /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==14218==    by 0x62230A:
> Digikam::DigikamImageDelegatePrivate::init(Digikam::DigikamImageDelegate*,
> Digikam::ImageCategorizedView*) (digikamimagedelegate.cpp:52)
> ==14218==    by 0x62240E:
> Digikam::DigikamImageDelegate::DigikamImageDelegate(Digikam::ImageCategoriz
> edView*) (digikamimagedelegate.cpp:64)

Yes I know, this is an obvious leak, but:
Look at ImageDelegate::~ImageDelegate(). This destruction was crashing for a
lot of people sometime last year. Crash was gone when we just leaked it. Not a
satisfying solution, I have no idea why it crashed, it never did for me.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel
Reply | Threaded
Open this post in threaded view
|

Re: memory leak by Mr Valgrind

Gilles Caulier-4
Yes, i remember crash report...

Gilles

2012/3/14 Marcel Wiesweg <[hidden email]>:

>
>> Marcel, i found this new allocation from image delegate class not
>> cleaned in destructor :
>>
>> ==14218== 496 (48 direct, 448 indirect) bytes in 1 blocks are
>> definitely lost in loss record 9,323 of 10,393
>> ==14218==    at 0x4C251D7: operator new(unsigned long) (in
>> /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
>> ==14218==    by 0x62230A:
>> Digikam::DigikamImageDelegatePrivate::init(Digikam::DigikamImageDelegate*,
>> Digikam::ImageCategorizedView*) (digikamimagedelegate.cpp:52)
>> ==14218==    by 0x62240E:
>> Digikam::DigikamImageDelegate::DigikamImageDelegate(Digikam::ImageCategoriz
>> edView*) (digikamimagedelegate.cpp:64)
>
> Yes I know, this is an obvious leak, but:
> Look at ImageDelegate::~ImageDelegate(). This destruction was crashing for a
> lot of people sometime last year. Crash was gone when we just leaked it. Not a
> satisfying solution, I have no idea why it crashed, it never did for me.
> _______________________________________________
> Digikam-devel mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-devel
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel
Reply | Threaded
Open this post in threaded view
|

Re: memory leak by Mr Valgrind

Marcel Wiesweg
In reply to this post by Gilles Caulier-4

> This time, it's under face detection process. I run few few seconds,
> some image are parsed. I press cancel in progress manager, and digiKam
> crash in thread management classes :

This is probably a true race condition where a thread was still started while
the whole framework is shutting down; when the object is accessed, it is
already deleted.
I assume this is not reproducible, in real execution or under valgrind?

Marcel
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel
Reply | Threaded
Open this post in threaded view
|

Re: memory leak by Mr Valgrind

Gilles Caulier-4
2012/3/14 Marcel Wiesweg <[hidden email]>:
>
>> This time, it's under face detection process. I run few few seconds,
>> some image are parsed. I press cancel in progress manager, and digiKam
>> crash in thread management classes :
>
> This is probably a true race condition where a thread was still started while
> the whole framework is shutting down; when the object is accessed, it is
> already deleted.
> I assume this is not reproducible, in real execution or under valgrind?

I don't know how to check this situation outside valgrind.

How i check digiKam under valgrind : i run albumgui, and i switch
between sidebar tab from left and right side. That all.

I plan to run valgrind in more situation, for ex with plugin, image
editor, light table etc. It's take time, but my computer is very fast
and as SSD and 16Gb of RAM.

Gilles
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel
Reply | Threaded
Open this post in threaded view
|

Re: memory leak by Mr Valgrind

Andi Clemens
In reply to this post by Gilles Caulier-4
Not sure why this is happening. Cleanup happens in  
unregisterKeysCollection() ...


On Tue, 13 Mar 2012 23:52:35 +0100, Gilles Caulier  
<[hidden email]> wrote:

> registerKeysCollection


_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel
Reply | Threaded
Open this post in threaded view
|

Re: memory leak by Mr Valgrind

Gilles Caulier-4
Hi Andi,

Can you reproduce the leak on your computer ?

Gilles

2012/3/14 Andi Clemens <[hidden email]>:

> Not sure why this is happening. Cleanup happens in
> unregisterKeysCollection() ...
>
>
> On Tue, 13 Mar 2012 23:52:35 +0100, Gilles Caulier
> <[hidden email]> wrote:
>
>> registerKeysCollection
>
>
>
> _______________________________________________
> Digikam-devel mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-devel
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel
Reply | Threaded
Open this post in threaded view
|

Re: memory leak by Mr Valgrind

Andi Clemens
need to check later on....

On Thu, 15 Mar 2012 07:23:45 +0100, Gilles Caulier  
<[hidden email]> wrote:

> Hi Andi,
>
> Can you reproduce the leak on your computer ?
>
> Gilles
>
> 2012/3/14 Andi Clemens <[hidden email]>:
>> Not sure why this is happening. Cleanup happens in
>> unregisterKeysCollection() ...
>>
>>
>> On Tue, 13 Mar 2012 23:52:35 +0100, Gilles Caulier
>> <[hidden email]> wrote:
>>
<snip>

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


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