|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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: >> >> >> >> >> _______________________________________________ >> 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 |
| Free forum by Nabble | Edit this page |
