memory leak in trunk...

[Gilles Caulier-4]

Hi all,

I review trunk with valgrind. Look like i can see in the console :

Marcel :

==1995== 32 bytes in 1 blocks are possibly lost in loss record 4,123 of 7,413
==1995==    at 0x40244F0: operator new(unsigned int) (vg_replace_malloc.c:214)
==1995==    by 0x52F456B:
Digikam::CollectionManager::updateLocations()
(collectionmanager.cpp:1520)
==1995==    by 0x52F09D5: Digikam::CollectionManager::refresh()
(collectionmanager.cpp:740)
==1995==    by 0x52F9F30:
Digikam::DatabaseAccess::checkReadyForUse(Digikam::InitializationObserver*)
(databaseaccess.cpp:303)
==1995==    by 0x8260598: Digikam::ScanController::run()
(scancontroller.cpp:580)
==1995==    by 0x6D84FCE: ??? (in /usr/lib/libQtCore.so.4.6.2)
==1995==    by 0x726603D: clone (in /lib/i686/libc-2.11.1.so)

Relevant of this allocation :
http://lxr.kde.org/source/extragear/graphics/digikam/libs/database/collectionmanager.cpp#1520

There is also a lots of report about databaseurl :

==1995== 42 bytes in 1 blocks are definitely lost in loss record 4,659 of 7,413
==1995==    at 0x4023D7C: malloc (vg_replace_malloc.c:195)
==1995==    by 0x6D7F63A: qMalloc(unsigned int) (in /usr/lib/libQtCore.so.4.6.2)
==1995==    by 0x5303F29: Digikam::DatabaseUrl::fromTagIds(QList<int>
const&, Digikam::DatabaseParameters const&) (databaseurl.cpp:104)
==1995==    by 0x81B25C7: Digikam::AlbumManager::getTagItemsCount()
(albummanager.cpp:1662)
==1995==    by 0x81B24A9: Digikam::AlbumManager::scanTAlbums()
(albummanager.cpp:1642)
==1995==    by 0x81B07D1: Digikam::AlbumManager::refresh()
(albummanager.cpp:1235)
==1995==    by 0x81B0188: Digikam::AlbumManager::startScan()
(albummanager.cpp:1140)
==1995==    by 0x81F2286: Digikam::DigikamApp::DigikamApp() (digikamapp.cpp:257)
==1995==    by 0x82A883D: main (main.cpp:177)

==1995== 44 bytes in 1 blocks are definitely lost in loss record 4,690 of 7,413
==1995==    at 0x4023D7C: malloc (vg_replace_malloc.c:195)
==1995==    by 0x6D7F63A: qMalloc(unsigned int) (in /usr/lib/libQtCore.so.4.6.2)
==1995==    by 0x53040C9:
Digikam::DatabaseUrl::dateUrl(Digikam::DatabaseParameters const&)
(databaseurl.cpp:118)
==1995==    by 0x81B2F6F: Digikam::AlbumManager::scanDAlbums()
(albummanager.cpp:1764)
==1995==    by 0x81B07E7: Digikam::AlbumManager::refresh()
(albummanager.cpp:1237)
==1995==    by 0x81B0188: Digikam::AlbumManager::startScan()
(albummanager.cpp:1140)
==1995==    by 0x81F2286: Digikam::DigikamApp::DigikamApp() (digikamapp.cpp:257)
==1995==    by 0x82A883D: main (main.cpp:177)

==1995== 46 bytes in 1 blocks are definitely lost in loss record 4,758 of 7,413
==1995==    at 0x4023D7C: malloc (vg_replace_malloc.c:195)
==1995==    by 0x6D7F63A: qMalloc(unsigned int) (in /usr/lib/libQtCore.so.4.6.2)
==1995==    by 0x5303BF9:
Digikam::DatabaseUrl::fromAlbumAndName(QString const&, QString const&,
KUrl const&, int, Digikam::DatabaseParameters const&)
(databaseurl.cpp:80)
==1995==    by 0x819E002: Digikam::PAlbum::databaseUrl() const (album.cpp:379)
==1995==    by 0x818A576: Digikam::ImageAlbumModel::refresh()
(imagealbummodel.cpp:188)
==1995==    by 0x818A4DF:
Digikam::ImageAlbumModel::openAlbum(Digikam::Album*)
(imagealbummodel.cpp:163)
==1995==    by 0x8228C83:
Digikam::ImageCategorizedView::openAlbum(Digikam::Album*)
(imagecategorizedview.cpp:339)
==1995==    by 0x8217962:
Digikam::DigikamView::slotAlbumSelected(Digikam::Album*)
(digikamview.cpp:984)
==1995==    by 0x82123BC:
Digikam::DigikamView::qt_metacall(QMetaObject::Call, int, void**)
(digikamview.moc:302)
==1995==    by 0x6E93DEC: QMetaObject::metacall(QObject*,
QMetaObject::Call, int, void**) (in /usr/lib/libQtCore.so.4.6.2)

==1995== 46 bytes in 1 blocks are definitely lost in loss record 4,759 of 7,413
==1995==    at 0x4023D7C: malloc (vg_replace_malloc.c:195)
==1995==    by 0x6D7F63A: qMalloc(unsigned int) (in /usr/lib/libQtCore.so.4.6.2)
==1995==    by 0x5303E81:
Digikam::DatabaseUrl::albumUrl(Digikam::DatabaseParameters const&)
(databaseurl.cpp:95)
==1995==    by 0x81B193B: Digikam::AlbumManager::getAlbumItemsCount()
(albummanager.cpp:1489)
==1995==    by 0x81A7540:
Digikam::AlbumManager::qt_metacall(QMetaObject::Call, int, void**)
(albummanager.moc:197)
==1995==    by 0x6E93DEC: QMetaObject::metacall(QObject*,
QMetaObject::Call, int, void**) (in /usr/lib/libQtCore.so.4.6.2)


------------------------------------------------------------------------------------------------------------------------------------------

Andi :

==1995== 20 bytes in 1 blocks are definitely lost in loss record 3,520 of 7,413
==1995==    at 0x40244F0: operator new(unsigned int) (vg_replace_malloc.c:214)
==1995==    by 0x826EC95:
Digikam::TagFilterSideBarWidget::TagFilterSideBarWidget(QWidget*,
Digikam::TagModel*) (tagfiltersidebarwidget.cpp:191)
==1995==    by 0x821459B: Digikam::DigikamView::DigikamView(QWidget*,
Digikam::DigikamModelCollection*) (digikamview.cpp:250)
==1995==    by 0x81F3582: Digikam::DigikamApp::setupView() (digikamapp.cpp:512)
==1995==    by 0x81F20F0: Digikam::DigikamApp::DigikamApp() (digikamapp.cpp:234)
==1995==    by 0x82A883D: main (main.cpp:177)

Relevant of this assignation :
http://lxr.kde.org/source/extragear/graphics/digikam/digikam/tagfiltersidebarwidget.cpp#196

Note : LXR is not yet updated against trunk. line differ here...

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

[Marcel Wiesweg]

> 7,413 ==1995==    at 0x40244F0: operator new(unsigned int)
> (vg_replace_malloc.c:214) ==1995==    by 0x52F456B:
> Digikam::CollectionManager::updateLocations()
> (collectionmanager.cpp:1520)
> ==1995==    by 0x52F09D5: Digikam::CollectionManager::refresh()

Should be fixed in SVN. Missing delete only at destruction.

>
> There is also a lots of report about databaseurl :
>
> ==1995== 42 bytes in 1 blocks are definitely lost in loss record 4,659 of
> 7,413 ==1995==    at 0x4023D7C: malloc (vg_replace_malloc.c:195)
> ==1995==    by 0x6D7F63A: qMalloc(unsigned int) (in
> /usr/lib/libQtCore.so.4.6.2) ==1995==    by 0x5303F29:
> Digikam::DatabaseUrl::fromTagIds(QList<int> const&,
> Digikam::DatabaseParameters const&) (databaseurl.cpp:104)

DatabaseUrl is a KUrl, which is a QUrl, which is implicitly shared, so it's
passed by value and we dont do any new/delete.
I suspect that the Urls are kept somewhere inside KIO when they are passed to
the IOSlaves, but I dont know. It's difficult but not impossible to lose an
implicitly shared object's data...

Marcel

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

[Gilles Caulier-4]

Thanks Marcel

I will continue to use digiKam through valgrind and report memory leak
issue if necessary...

Gilles

2010/11/30 Marcel Wiesweg <[hidden email]>:

>> 7,413 ==1995==    at 0x40244F0: operator new(unsigned int)
>> (vg_replace_malloc.c:214) ==1995==    by 0x52F456B:
>> Digikam::CollectionManager::updateLocations()
>> (collectionmanager.cpp:1520)
>> ==1995==    by 0x52F09D5: Digikam::CollectionManager::refresh()
>
> Should be fixed in SVN. Missing delete only at destruction.
>
>>
>> There is also a lots of report about databaseurl :
>>
>> ==1995== 42 bytes in 1 blocks are definitely lost in loss record 4,659 of
>> 7,413 ==1995==    at 0x4023D7C: malloc (vg_replace_malloc.c:195)
>> ==1995==    by 0x6D7F63A: qMalloc(unsigned int) (in
>> /usr/lib/libQtCore.so.4.6.2) ==1995==    by 0x5303F29:
>> Digikam::DatabaseUrl::fromTagIds(QList<int> const&,
>> Digikam::DatabaseParameters const&) (databaseurl.cpp:104)
>
> DatabaseUrl is a KUrl, which is a QUrl, which is implicitly shared, so it's
> passed by value and we dont do any new/delete.
> I suspect that the Urls are kept somewhere inside KIO when they are passed to
> the IOSlaves, but I dont know. It's difficult but not impossible to lose an
> implicitly shared object's data...
>
> Marcel
>
> _______________________________________________
> 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

[Gilles Caulier-4]

Marcel,

This one is really huge :

==14101== 1,390,426 (20 direct, 1,390,406 indirect) bytes in 1 blocks
are definitely lost in loss record 6,807 of 6,808
==14101==    at 0x40244F0: operator new(unsigned int) (vg_replace_malloc.c:214)
==14101==    by 0x820FFB9:
Digikam::DigikamImageDelegate::DigikamImageDelegate(Digikam::ImageCategorizedView*)
(digikamimagedelegate.cpp:62)
==14101==    by 0x820D491:
Digikam::DigikamImageView::DigikamImageView(QWidget*)
(digikamimageview.cpp:82)
==14101==    by 0x81E0BD8:
Digikam::AlbumWidgetStack::AlbumWidgetStack(QWidget*)
(albumwidgetstack.cpp:96)
==14101==    by 0x8213E19: Digikam::DigikamView::DigikamView(QWidget*,
Digikam::DigikamModelCollection*) (digikamview.cpp:183)
==14101==    by 0x81F357E: Digikam::DigikamApp::setupView() (digikamapp.cpp:512)
==14101==    by 0x81F20EC: Digikam::DigikamApp::DigikamApp()
(digikamapp.cpp:234)
==14101==    by 0x82A8865: main (main.cpp:177)

I know the problem in sourec code. But it becaome really unacceptable...

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

[Gilles Caulier-4]

Andi,

New one :

==14101== 1,390,426 (20 direct, 1,390,406 indirect) bytes in 1 blocks
are definitely lost in loss record 6,807 of 6,808
==14101==    at 0x40244F0: operator new(unsigned int) (vg_replace_malloc.c:214)
==14101==    by 0x820FFB9:
Digikam::DigikamImageDelegate::DigikamImageDelegate(Digikam::ImageCategorizedView*)
(digikamimagedelegate.cpp:62)
==14101==    by 0x820D491:
Digikam::DigikamImageView::DigikamImageView(QWidget*)
(digikamimageview.cpp:82)
==14101==    by 0x81E0BD8:
Digikam::AlbumWidgetStack::AlbumWidgetStack(QWidget*)
(albumwidgetstack.cpp:96)
==14101==    by 0x8213E19: Digikam::DigikamView::DigikamView(QWidget*,
Digikam::DigikamModelCollection*) (digikamview.cpp:183)
==14101==    by 0x81F357E: Digikam::DigikamApp::setupView() (digikamapp.cpp:512)
==14101==    by 0x81F20EC: Digikam::DigikamApp::DigikamApp()
(digikamapp.cpp:234)
==14101==    by 0x82A8865: main (main.cpp:177)


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

[Gilles Caulier-4]

Another one :

==14101== 56 bytes in 1 blocks are possibly lost in loss record 4,745 of 6,808
==14101==    at 0x4023D7C: malloc (vg_replace_malloc.c:195)
==14101==    by 0x6D8063A: qMalloc(unsigned int) (in
/usr/lib/libQtCore.so.4.6.2)
==14101==    by 0x6DD260E: QString::realloc(int) (in
/usr/lib/libQtCore.so.4.6.2)
==14101==    by 0x6DD2D3C: QString::append(QString const&) (in
/usr/lib/libQtCore.so.4.6.2)
==14101==    by 0x52D9996: operator+(QString const&, QString const&)
(qstring.h:1010)
==14101==    by 0x52F4B4A:
Digikam::CollectionManager::updateLocations()
(collectionmanager.cpp:1563)
==14101==    by 0x52F0AB3: Digikam::CollectionManager::refresh()
(collectionmanager.cpp:741)
==14101==    by 0x52FA518:
Digikam::DatabaseAccess::checkReadyForUse(Digikam::InitializationObserver*)
(databaseaccess.cpp:303)
==14101==    by 0x8260594: Digikam::ScanController::run()
(scancontroller.cpp:580)
==14101==    by 0x6D85FCE: ??? (in /usr/lib/libQtCore.so.4.6.2)
==14101==    by 0x726703D: clone (in /lib/i686/libc-2.11.1.so)

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

[Gilles Caulier-4]

Andi,

Sorry, the right one :

==14101== 7,872 (196 direct, 7,676 indirect) bytes in 1 blocks are
definitely lost in loss record 6,726 of 6,808
==14101==    at 0x40244F0: operator new(unsigned int) (vg_replace_malloc.c:214)
==14101==    by 0x5FBD041: QAction::QAction(QObject*) (in
/usr/lib/libQtGui.so.4.6.2)
==14101==    by 0x647467E: ??? (in /usr/lib/libQtGui.so.4.6.2)
==14101==    by 0x6474A4A: QMenu::QMenu(QWidget*) (in
/usr/lib/libQtGui.so.4.6.2)
==14101==    by 0x82B324C: QMenu*
Digikam::AdvancedRenameWidget::createControlsMenu<Digikam::Modifier>(QList<Digikam::Modifier*>&)
(advancedrenamewidget.cpp:212)
==14101==    by 0x82B1A53:
Digikam::AdvancedRenameWidget::registerParserControls()
(advancedrenamewidget.cpp:274)
==14101==    by 0x82B1B34:
Digikam::AdvancedRenameWidget::calculateLayout()
(advancedrenamewidget.cpp:306)
==14101==    by 0x82B1B1E:
Digikam::AdvancedRenameWidget::setParser(Digikam::Parser*)
(advancedrenamewidget.cpp:301)
==14101==    by 0x82AD54D:
Digikam::AdvancedRenameManager::setParserType(Digikam::AdvancedRenameManager::ParserType)
(advancedrenamemanager.cpp:160)
==14101==    by 0x82AD452:
Digikam::AdvancedRenameManager::setWidget(Digikam::AdvancedRenameWidget*)
(advancedrenamemanager.cpp:137)
==14101==    by 0x82F0470:
Digikam::QueueSettingsView::QueueSettingsView(QWidget*)
(queuesettingsview.cpp:156)
==14101==    by 0x82E4167: Digikam::QueueMgrWindow::setupUserArea()
(queuemgrwindow.cpp:222)

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

[Marcel Wiesweg]

> ==14101== 1,390,426 (20 direct, 1,390,406 indirect) bytes in 1 blocks
> are definitely lost in loss record 6,807 of 6,808
> ==14101==    at 0x40244F0: operator new(unsigned int)
> (vg_replace_malloc.c:214) ==14101==    by 0x820FFB9:
> Digikam::DigikamImageDelegate::DigikamImageDelegate(Digikam::ImageCategoriz
> edView*) (digikamimagedelegate.cpp:62)

I dont understand that. "1 block" means that this is one single allocation,
doesnt it? The size of ImageCategoryDrawer, one d-pointer in
ImageCategoryDrawer, one d-pointer in KCategoryDrawer, should be
2*sizeof(void*), 16 bytes, not 1.3MB!
And there is not more than one such object per digikam application, only the
main icon view uses it.

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

[Gilles Caulier-4]

I agree with you.

What do you see in your computer with valgrind ? the same size ?

Gilles

2010/12/1 Marcel Wiesweg <[hidden email]>:

>
>> ==14101== 1,390,426 (20 direct, 1,390,406 indirect) bytes in 1 blocks
>> are definitely lost in loss record 6,807 of 6,808
>> ==14101==    at 0x40244F0: operator new(unsigned int)
>> (vg_replace_malloc.c:214) ==14101==    by 0x820FFB9:
>> Digikam::DigikamImageDelegate::DigikamImageDelegate(Digikam::ImageCategoriz
>> edView*) (digikamimagedelegate.cpp:62)
>
> I dont understand that. "1 block" means that this is one single allocation,
> doesnt it? The size of ImageCategoryDrawer, one d-pointer in
> ImageCategoryDrawer, one d-pointer in KCategoryDrawer, should be
> 2*sizeof(void*), 16 bytes, not 1.3MB!
> And there is not more than one such object per digikam application, only the
> main icon view uses it.
>
> Marcel
> _______________________________________________
> 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

It should be mentioned that valgrind isn't always right, I had situations were
it complained about not freed memory, although it definetly has been freed.
This happens especially when using threads.

Andi Clemens
-----------------
www.digikam.org

On Wednesday 01 December 2010 11:50:27 Gilles Caulier wrote:

> I agree with you.
>
> What do you see in your computer with valgrind ? the same size ?
>
> Gilles
>
> 2010/12/1 Marcel Wiesweg <[hidden email]>:
> >> ==14101== 1,390,426 (20 direct, 1,390,406 indirect) bytes in 1 blocks
> >> are definitely lost in loss record 6,807 of 6,808
> >> ==14101==    at 0x40244F0: operator new(unsigned int)
> >> (vg_replace_malloc.c:214) ==14101==    by 0x820FFB9:
> >> Digikam::DigikamImageDelegate::DigikamImageDelegate(Digikam::ImageCatego
> >> riz edView*) (digikamimagedelegate.cpp:62)
> >
> > I dont understand that. "1 block" means that this is one single
> > allocation, doesnt it? The size of ImageCategoryDrawer, one d-pointer in
> > ImageCategoryDrawer, one d-pointer in KCategoryDrawer, should be
> > 2*sizeof(void*), 16 bytes, not 1.3MB!
> > And there is not more than one such object per digikam application, only
> > the main icon view uses it.
> >
> > Marcel
> > _______________________________________________
> > 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

Hmm I don't understand this.
The QMenu is assigned to the parent menu:

QMenu* menu = new QMenu(parent);

This line:

action = parent->addMenu(menu);

says (according to the Qt docs) that addMenu will NOT take ownership of
"menu", but since "menu" has the parent already set in the constructor, this
shouldn't be the problem.

Andi Clemens
-----------------
www.digikam.org

On Wednesday 01 December 2010 11:40:49 Gilles Caulier wrote:

> Andi,
>
> Sorry, the right one :
>
> ==14101== 7,872 (196 direct, 7,676 indirect) bytes in 1 blocks are
> definitely lost in loss record 6,726 of 6,808
> ==14101==    at 0x40244F0: operator new(unsigned int)
> (vg_replace_malloc.c:214) ==14101==    by 0x5FBD041:
> QAction::QAction(QObject*) (in
> /usr/lib/libQtGui.so.4.6.2)
> ==14101==    by 0x647467E: ??? (in /usr/lib/libQtGui.so.4.6.2)
> ==14101==    by 0x6474A4A: QMenu::QMenu(QWidget*) (in
> /usr/lib/libQtGui.so.4.6.2)
> ==14101==    by 0x82B324C: QMenu*
> Digikam::AdvancedRenameWidget::createControlsMenu<Digikam::Modifier>(QList<
> Digikam::Modifier*>&) (advancedrenamewidget.cpp:212)
> ==14101==    by 0x82B1A53:
> Digikam::AdvancedRenameWidget::registerParserControls()
> (advancedrenamewidget.cpp:274)
> ==14101==    by 0x82B1B34:
> Digikam::AdvancedRenameWidget::calculateLayout()
> (advancedrenamewidget.cpp:306)
> ==14101==    by 0x82B1B1E:
> Digikam::AdvancedRenameWidget::setParser(Digikam::Parser*)
> (advancedrenamewidget.cpp:301)
> ==14101==    by 0x82AD54D:
> Digikam::AdvancedRenameManager::setParserType(Digikam::AdvancedRenameManage
> r::ParserType) (advancedrenamemanager.cpp:160)
> ==14101==    by 0x82AD452:
> Digikam::AdvancedRenameManager::setWidget(Digikam::AdvancedRenameWidget*)
> (advancedrenamemanager.cpp:137)
> ==14101==    by 0x82F0470:
> Digikam::QueueSettingsView::QueueSettingsView(QWidget*)
> (queuesettingsview.cpp:156)
> ==14101==    by 0x82E4167: Digikam::QueueMgrWindow::setupUserArea()
> (queuemgrwindow.cpp:222)
>
> Gilles
> _______________________________________________
> 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

A different question:

What on earth are we allocating on startup?
A fresh digiKam start shows 240MB RAM that are owned by digiKam.
This is insane :-)
There isn't even thumbnails in the iconview, I just display the welcome
screen.


Andi Clemens
-----------------
www.digikam.org

On Tuesday 30 November 2010 15:20:45 Gilles Caulier wrote:

> Hi all,
>
> I review trunk with valgrind. Look like i can see in the console :
>
> Marcel :
>
> ==1995== 32 bytes in 1 blocks are possibly lost in loss record 4,123 of
> 7,413 ==1995==    at 0x40244F0: operator new(unsigned int)
> (vg_replace_malloc.c:214) ==1995==    by 0x52F456B:
> Digikam::CollectionManager::updateLocations()
> (collectionmanager.cpp:1520)
> ==1995==    by 0x52F09D5: Digikam::CollectionManager::refresh()
> (collectionmanager.cpp:740)
> ==1995==    by 0x52F9F30:
> Digikam::DatabaseAccess::checkReadyForUse(Digikam::InitializationObserver*)
> (databaseaccess.cpp:303)
> ==1995==    by 0x8260598: Digikam::ScanController::run()
> (scancontroller.cpp:580)
> ==1995==    by 0x6D84FCE: ??? (in /usr/lib/libQtCore.so.4.6.2)
> ==1995==    by 0x726603D: clone (in /lib/i686/libc-2.11.1.so)
>
> Relevant of this allocation :
> http://lxr.kde.org/source/extragear/graphics/digikam/libs/database/collecti
> onmanager.cpp#1520
>
> There is also a lots of report about databaseurl :
>
> ==1995== 42 bytes in 1 blocks are definitely lost in loss record 4,659 of
> 7,413 ==1995==    at 0x4023D7C: malloc (vg_replace_malloc.c:195)
> ==1995==    by 0x6D7F63A: qMalloc(unsigned int) (in
> /usr/lib/libQtCore.so.4.6.2) ==1995==    by 0x5303F29:
> Digikam::DatabaseUrl::fromTagIds(QList<int> const&,
> Digikam::DatabaseParameters const&) (databaseurl.cpp:104)
> ==1995==    by 0x81B25C7: Digikam::AlbumManager::getTagItemsCount()
> (albummanager.cpp:1662)
> ==1995==    by 0x81B24A9: Digikam::AlbumManager::scanTAlbums()
> (albummanager.cpp:1642)
> ==1995==    by 0x81B07D1: Digikam::AlbumManager::refresh()
> (albummanager.cpp:1235)
> ==1995==    by 0x81B0188: Digikam::AlbumManager::startScan()
> (albummanager.cpp:1140)
> ==1995==    by 0x81F2286: Digikam::DigikamApp::DigikamApp()
> (digikamapp.cpp:257) ==1995==    by 0x82A883D: main (main.cpp:177)
>
> ==1995== 44 bytes in 1 blocks are definitely lost in loss record 4,690 of
> 7,413 ==1995==    at 0x4023D7C: malloc (vg_replace_malloc.c:195)
> ==1995==    by 0x6D7F63A: qMalloc(unsigned int) (in
> /usr/lib/libQtCore.so.4.6.2) ==1995==    by 0x53040C9:
> Digikam::DatabaseUrl::dateUrl(Digikam::DatabaseParameters const&)
> (databaseurl.cpp:118)
> ==1995==    by 0x81B2F6F: Digikam::AlbumManager::scanDAlbums()
> (albummanager.cpp:1764)
> ==1995==    by 0x81B07E7: Digikam::AlbumManager::refresh()
> (albummanager.cpp:1237)
> ==1995==    by 0x81B0188: Digikam::AlbumManager::startScan()
> (albummanager.cpp:1140)
> ==1995==    by 0x81F2286: Digikam::DigikamApp::DigikamApp()
> (digikamapp.cpp:257) ==1995==    by 0x82A883D: main (main.cpp:177)
>
> ==1995== 46 bytes in 1 blocks are definitely lost in loss record 4,758 of
> 7,413 ==1995==    at 0x4023D7C: malloc (vg_replace_malloc.c:195)
> ==1995==    by 0x6D7F63A: qMalloc(unsigned int) (in
> /usr/lib/libQtCore.so.4.6.2) ==1995==    by 0x5303BF9:
> Digikam::DatabaseUrl::fromAlbumAndName(QString const&, QString const&,
> KUrl const&, int, Digikam::DatabaseParameters const&)
> (databaseurl.cpp:80)
> ==1995==    by 0x819E002: Digikam::PAlbum::databaseUrl() const
> (album.cpp:379) ==1995==    by 0x818A576:
> Digikam::ImageAlbumModel::refresh()
> (imagealbummodel.cpp:188)
> ==1995==    by 0x818A4DF:
> Digikam::ImageAlbumModel::openAlbum(Digikam::Album*)
> (imagealbummodel.cpp:163)
> ==1995==    by 0x8228C83:
> Digikam::ImageCategorizedView::openAlbum(Digikam::Album*)
> (imagecategorizedview.cpp:339)
> ==1995==    by 0x8217962:
> Digikam::DigikamView::slotAlbumSelected(Digikam::Album*)
> (digikamview.cpp:984)
> ==1995==    by 0x82123BC:
> Digikam::DigikamView::qt_metacall(QMetaObject::Call, int, void**)
> (digikamview.moc:302)
> ==1995==    by 0x6E93DEC: QMetaObject::metacall(QObject*,
> QMetaObject::Call, int, void**) (in /usr/lib/libQtCore.so.4.6.2)
>
> ==1995== 46 bytes in 1 blocks are definitely lost in loss record 4,759 of
> 7,413 ==1995==    at 0x4023D7C: malloc (vg_replace_malloc.c:195)
> ==1995==    by 0x6D7F63A: qMalloc(unsigned int) (in
> /usr/lib/libQtCore.so.4.6.2) ==1995==    by 0x5303E81:
> Digikam::DatabaseUrl::albumUrl(Digikam::DatabaseParameters const&)
> (databaseurl.cpp:95)
> ==1995==    by 0x81B193B: Digikam::AlbumManager::getAlbumItemsCount()
> (albummanager.cpp:1489)
> ==1995==    by 0x81A7540:
> Digikam::AlbumManager::qt_metacall(QMetaObject::Call, int, void**)
> (albummanager.moc:197)
> ==1995==    by 0x6E93DEC: QMetaObject::metacall(QObject*,
> QMetaObject::Call, int, void**) (in /usr/lib/libQtCore.so.4.6.2)
>
>
> ---------------------------------------------------------------------------
> ---------------------------------------------------------------
>
> Andi :
>
> ==1995== 20 bytes in 1 blocks are definitely lost in loss record 3,520 of
> 7,413 ==1995==    at 0x40244F0: operator new(unsigned int)
> (vg_replace_malloc.c:214) ==1995==    by 0x826EC95:
> Digikam::TagFilterSideBarWidget::TagFilterSideBarWidget(QWidget*,
> Digikam::TagModel*) (tagfiltersidebarwidget.cpp:191)
> ==1995==    by 0x821459B: Digikam::DigikamView::DigikamView(QWidget*,
> Digikam::DigikamModelCollection*) (digikamview.cpp:250)
> ==1995==    by 0x81F3582: Digikam::DigikamApp::setupView()
> (digikamapp.cpp:512) ==1995==    by 0x81F20F0:
> Digikam::DigikamApp::DigikamApp() (digikamapp.cpp:234) ==1995==    by
> 0x82A883D: main (main.cpp:177)
>
> Relevant of this assignation :
> http://lxr.kde.org/source/extragear/graphics/digikam/digikam/tagfiltersideb
> arwidget.cpp#196
>
> Note : LXR is not yet updated against trunk. line differ here...
>
> Gilles
> _______________________________________________
> 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

[Marcel Wiesweg]

> A different question:
>
> What on earth are we allocating on startup?
> A fresh digiKam start shows 240MB RAM that are owned by digiKam.
> This is insane :-)
> There isn't even thumbnails in the iconview, I just display the welcome
> screen.

Massif can tell us more about this:

http://img252.imageshack.us/my.php?image=plasmadesktopjn1911.png
http://img252.imageshack.us/my.php?image=plasmadesktopdw1911.png

- there are about eight single entries resulting from marble, summing to 60
MB. This is quite a lot obviously. It may be related to the fact that we use
multiple marble instances (this is GSoc branch), I dont know if Marble is
ready to share internal memory between instances
- there are 2*30 MB due to the ICC profiles on my system. I may have installed
a lot of them. And it's a bug that they are kept loaded, I meant to drop this
memory but somehow it does not work
- roughly 10 MB in khtml / kjs. This may be the welcome screen, or
libkmap/Google Maps backend
- 3 MB for the KCompletion in tree view search lines. Potential for sharing.
- 4 MB from libxine. The future is VLC Phonon backend anyway.
- 41 MB below the threshold
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Michael G. Hansen]

On 12/02/2010 10:40 AM, Marcel Wiesweg wrote:

>> A different question:
>>
>> What on earth are we allocating on startup?
>> A fresh digiKam start shows 240MB RAM that are owned by digiKam.
>> This is insane :-)
>> There isn't even thumbnails in the iconview, I just display the welcome
>> screen.
>
> Massif can tell us more about this:
>
> http://img252.imageshack.us/my.php?image=plasmadesktopjn1911.png
> http://img252.imageshack.us/my.php?image=plasmadesktopdw1911.png
>
> - there are about eight single entries resulting from marble, summing to 60
> MB. This is quite a lot obviously. It may be related to the fact that we use
> multiple marble instances (this is GSoc branch), I dont know if Marble is
> ready to share internal memory between instances

Wow, that's a lot! I plan to modify libkmap to only create Marble
instances once a view is activated. Maybe we should talk to the Marble
devs about which components of Marble can be reused in other instances.

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