Digikam memory usage

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

Digikam memory usage

Alberto Ferrante
Dear all,
in the latest days I have tried to import my collection of photos into
Digikam. Unfortunately I was not able: Digikam seems to require too
much memory to import even not so big albums. For example, to import a
folder with 3'000 picture Digikam used about 15GB of RAM (8 of RAM +
swap). I was not able to import other larger folders (with more than
10Kphotos) as Digikam was terminated after having filled all the
available memory (about 20GB).
I do not want to criticize this software (that looks very promising),
but I feel like a tool like this becomes really useful if you have a
large collection of photos (and this is why I would like to use it!).
Therefore, it should be designed to handle this situation. Probably
the computations after the collection read should be split in small
chunks to avoid this huge memory usage.

Any suggestion on how to make it work (besides using smaller
collections, that is not viable for me)?

Best regards,
        Alberto

--
Home page: http://www.alari.ch/people/alberto
Photo galleries : http://albertoferrante.name
Public key: http://www.alari.ch/people/alberto/keys/yahoo.asc
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users
Reply | Threaded
Open this post in threaded view
|

Re: Digikam memory usage

Gilles Caulier-4
Which version you use ?

Since 2.2.0 i work on import tool to limit memory consumption due to thumbnail processing. There is a cache interface now. Also, before this version, all thumbs from camera been processed. Now, only item displaed in icon view are processed on the fly.

I recommend to use 2.3.0. There is a little bug in this cache interface which can crash digiKam with AVI file. Marcel has fixed it with 2.3.0 release.

Best

Gilles Caulier

2011/11/13 Alberto Ferrante <[hidden email]>
Dear all,
in the latest days I have tried to import my collection of photos into
Digikam. Unfortunately I was not able: Digikam seems to require too
much memory to import even not so big albums. For example, to import a
folder with 3'000 picture Digikam used about 15GB of RAM (8 of RAM +
swap). I was not able to import other larger folders (with more than
10Kphotos) as Digikam was terminated after having filled all the
available memory (about 20GB).
I do not want to criticize this software (that looks very promising),
but I feel like a tool like this becomes really useful if you have a
large collection of photos (and this is why I would like to use it!).
Therefore, it should be designed to handle this situation. Probably
the computations after the collection read should be split in small
chunks to avoid this huge memory usage.

Any suggestion on how to make it work (besides using smaller
collections, that is not viable for me)?

Best regards,
       Alberto

--
Home page: http://www.alari.ch/people/alberto
Photo galleries : http://albertoferrante.name
Public key: http://www.alari.ch/people/alberto/keys/yahoo.asc
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users


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

Re: Digikam memory usage

Alberto Ferrante
In reply to this post by Alberto Ferrante
Thanks for your reply, Gilles.
I use version 2.3 (on Fedora 16, 64 bit). I now use MySQL as DB.

Is there any way (e.g. any setting) to improve memory consumption?

Regards,
        Alberto Ferrante


> Which version you use ?
>
> Since 2.2.0 i work on import tool to limit memory consumption due
> to thumbnail processing. There is a cache interface now. Also,
> before this version, all thumbs from camera been processed. Now,
> only item displaed in icon view are processed on the fly.
>
> I recommend to use 2.3.0. There is a little bug in this cache
> interface which can crash digiKam with AVI file. Marcel has fixed
> it with 2.3.0 release.
>
> Best
>
> Gilles Caulier



On 11/13/2011 05:22 PM, Alberto Ferrante wrote:

> in the latest days I have tried to import my collection of photos
> into Digikam. Unfortunately I was not able: Digikam seems to
> require too much memory to import even not so big albums. For
> example, to import a folder with 3'000 picture Digikam used about
> 15GB of RAM (8 of RAM + swap). I was not able to import other
> larger folders (with more than 10Kphotos) as Digikam was terminated
> after having filled all the available memory (about 20GB). I do not
> want to criticize this software (that looks very promising), but I
> feel like a tool like this becomes really useful if you have a
> large collection of photos (and this is why I would like to use
> it!). Therefore, it should be designed to handle this situation.
> Probably the computations after the collection read should be split
> in small chunks to avoid this huge memory usage.


--
Home page: http://www.alari.ch/people/alberto
Photo galleries : http://albertoferrante.name
Public key: http://www.alari.ch/people/alberto/keys/yahoo.asc
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users
Reply | Threaded
Open this post in threaded view
|

Re: Digikam memory usage

Gilles Caulier-4
In first, we must identify where memory is lost.

Run digiKam through valgrind from a console, an report the trace here.

For details, look here :


Gilles Caulier




2011/11/13 Alberto Ferrante <[hidden email]>
Thanks for your reply, Gilles.
I use version 2.3 (on Fedora 16, 64 bit). I now use MySQL as DB.

Is there any way (e.g. any setting) to improve memory consumption?

Regards,
       Alberto Ferrante


> Which version you use ?
>
> Since 2.2.0 i work on import tool to limit memory consumption due
> to thumbnail processing. There is a cache interface now. Also,
> before this version, all thumbs from camera been processed. Now,
> only item displaed in icon view are processed on the fly.
>
> I recommend to use 2.3.0. There is a little bug in this cache
> interface which can crash digiKam with AVI file. Marcel has fixed
> it with 2.3.0 release.
>
> Best
>
> Gilles Caulier



On 11/13/2011 05:22 PM, Alberto Ferrante wrote:
> in the latest days I have tried to import my collection of photos
> into Digikam. Unfortunately I was not able: Digikam seems to
> require too much memory to import even not so big albums. For
> example, to import a folder with 3'000 picture Digikam used about
> 15GB of RAM (8 of RAM + swap). I was not able to import other
> larger folders (with more than 10Kphotos) as Digikam was terminated
> after having filled all the available memory (about 20GB). I do not
> want to criticize this software (that looks very promising), but I
> feel like a tool like this becomes really useful if you have a
> large collection of photos (and this is why I would like to use
> it!). Therefore, it should be designed to handle this situation.
> Probably the computations after the collection read should be split
> in small chunks to avoid this huge memory usage.


--
Home page: http://www.alari.ch/people/alberto
Photo galleries : http://albertoferrante.name
Public key: http://www.alari.ch/people/alberto/keys/yahoo.asc
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users


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

Re: Digikam memory usage

Alberto Ferrante
In reply to this post by Alberto Ferrante
Dear Gilles,
attached to this message you can find the log. As you can see at the end
the program was terminated after having filled all the available memory
(20GB!) after having read 4'600 jpgs. The "invalid read" you see in the
report are generated at the beginning of the execution, before starting
to import a collection.

I do not think that one solution would be to divide the processing of
data in "chunks": the program should not wait at the end of the scan to
do all the processing, it should do it after it read X (100?) files.

Regards,
        Alberto


> In first, we must identify where memory is lost.
>
> Run digiKam through valgrind from a console, an report the trace here.
>
> For details, look here :
>
> https://projects.kde.org/projects/extragear/graphics/digikam/repository/revisions/master/entry/HACKING#L281
>
> Gilles Caulier

--
Home page: http://www.alari.ch/people/alberto
Photo galleries : http://albertoferrante.name
Public key: http://www.alari.ch/people/alberto/keys/yahoo.asc

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

digikam.log (40K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Digikam memory usage

Alberto Ferrante
Sorry, the attachment was filtered out. The text of the log is now
online in the message:

==4709== Memcheck, a memory error detector
==4709== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==4709== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
==4709== Command: digikam
==4709==
==4709== Invalid read of size 4
==4709==    at 0x3FD0208083: ??? (in /usr/lib64/libfontconfig.so.1.4.4)
==4709==    by 0x3FD020A447: FcConfigFilename (in
/usr/lib64/libfontconfig.so.1.4.4)
==4709==    by 0x3FD021D965: FcConfigParseAndLoad (in
/usr/lib64/libfontconfig.so.1.4.4)
==4709==    by 0x3FD02130C6: FcInitLoadConfig (in
/usr/lib64/libfontconfig.so.1.4.4)
==4709==    by 0x3FD02131B5: FcInitLoadConfigAndFonts (in
/usr/lib64/libfontconfig.so.1.4.4)
==4709==    by 0x3FD02133D4: FcInit (in /usr/lib64/libfontconfig.so.1.4.4)
==4709==    by 0x3FD744217A: ??? (in /usr/lib64/libQtGui.so.4.8.0)
==4709==    by 0x3FD73D0783: QApplicationPrivate::construct(_XDisplay*,
unsigned long, unsigned long) (in /usr/lib64/libQtGui.so.4.8.0)
==4709==    by 0x3FD73D0EC9: QApplication::QApplication(int&, char**,
bool, int) (in /usr/lib64/libQtGui.so.4.8.0)
==4709==    by 0x37EF253126: KApplication::KApplication(bool) (in
/usr/lib64/libkdeui.so.5.7.0)
==4709==    by 0x48AE42: ??? (in /usr/bin/digikam)
==4709==    by 0x3FC9E2169C: (below main) (in /lib64/libc-2.14.90.so)
==4709==  Address 0x4dc56b4 is 20 bytes inside a block of size 22 alloc'd
==4709==    at 0x4A074CD: malloc (vg_replace_malloc.c:236)
==4709==    by 0x3FD0207FDC: ??? (in /usr/lib64/libfontconfig.so.1.4.4)
==4709==    by 0x3FD020A447: FcConfigFilename (in
/usr/lib64/libfontconfig.so.1.4.4)
==4709==    by 0x3FD021D965: FcConfigParseAndLoad (in
/usr/lib64/libfontconfig.so.1.4.4)
==4709==    by 0x3FD02130C6: FcInitLoadConfig (in
/usr/lib64/libfontconfig.so.1.4.4)
==4709==    by 0x3FD02131B5: FcInitLoadConfigAndFonts (in
/usr/lib64/libfontconfig.so.1.4.4)
==4709==    by 0x3FD02133D4: FcInit (in /usr/lib64/libfontconfig.so.1.4.4)
==4709==    by 0x3FD744217A: ??? (in /usr/lib64/libQtGui.so.4.8.0)
==4709==    by 0x3FD73D0783: QApplicationPrivate::construct(_XDisplay*,
unsigned long, unsigned long) (in /usr/lib64/libQtGui.so.4.8.0)
==4709==    by 0x3FD73D0EC9: QApplication::QApplication(int&, char**,
bool, int) (in /usr/lib64/libQtGui.so.4.8.0)
==4709==    by 0x37EF253126: KApplication::KApplication(bool) (in
/usr/lib64/libkdeui.so.5.7.0)
==4709==    by 0x48AE42: ??? (in /usr/bin/digikam)
==4709==
==4709== Invalid read of size 4
==4709==    at 0x3FD0208098: ??? (in /usr/lib64/libfontconfig.so.1.4.4)
==4709==    by 0x3FD020A447: FcConfigFilename (in
/usr/lib64/libfontconfig.so.1.4.4)
==4709==    by 0x3FD021D965: FcConfigParseAndLoad (in
/usr/lib64/libfontconfig.so.1.4.4)
==4709==    by 0x3FD021E04D: ??? (in /usr/lib64/libfontconfig.so.1.4.4)
==4709==    by 0x3FCF60A68A: ??? (in /lib64/libexpat.so.1.5.2)
==4709==    by 0x3FCF60B8CD: ??? (in /lib64/libexpat.so.1.5.2)
==4709==    by 0x3FCF60878E: ??? (in /lib64/libexpat.so.1.5.2)
==4709==    by 0x3FCF60A11A: ??? (in /lib64/libexpat.so.1.5.2)
==4709==    by 0x3FCF60D6E1: XML_ParseBuffer (in /lib64/libexpat.so.1.5.2)
==4709==    by 0x3FD021DAC0: FcConfigParseAndLoad (in
/usr/lib64/libfontconfig.so.1.4.4)
==4709==    by 0x3FD02130C6: FcInitLoadConfig (in
/usr/lib64/libfontconfig.so.1.4.4)
==4709==    by 0x3FD02131B5: FcInitLoadConfigAndFonts (in
/usr/lib64/libfontconfig.so.1.4.4)
==4709==  Address 0x4dcda00 is 16 bytes inside a block of size 18 alloc'd
==4709==    at 0x4A074CD: malloc (vg_replace_malloc.c:236)
==4709==    by 0x3FD0207FDC: ??? (in /usr/lib64/libfontconfig.so.1.4.4)
==4709==    by 0x3FD020A447: FcConfigFilename (in
/usr/lib64/libfontconfig.so.1.4.4)
==4709==    by 0x3FD021D965: FcConfigParseAndLoad (in
/usr/lib64/libfontconfig.so.1.4.4)
==4709==    by 0x3FD021E04D: ??? (in /usr/lib64/libfontconfig.so.1.4.4)
==4709==    by 0x3FCF60A68A: ??? (in /lib64/libexpat.so.1.5.2)
==4709==    by 0x3FCF60B8CD: ??? (in /lib64/libexpat.so.1.5.2)
==4709==    by 0x3FCF60878E: ??? (in /lib64/libexpat.so.1.5.2)
==4709==    by 0x3FCF60A11A: ??? (in /lib64/libexpat.so.1.5.2)
==4709==    by 0x3FCF60D6E1: XML_ParseBuffer (in /lib64/libexpat.so.1.5.2)
==4709==    by 0x3FD021DAC0: FcConfigParseAndLoad (in
/usr/lib64/libfontconfig.so.1.4.4)
==4709==    by 0x3FD02130C6: FcInitLoadConfig (in
/usr/lib64/libfontconfig.so.1.4.4)
==4709==
==4709== Invalid read of size 4
==4709==    at 0x3FD0208098: ??? (in /usr/lib64/libfontconfig.so.1.4.4)
==4709==    by 0x3FD021D965: FcConfigParseAndLoad (in
/usr/lib64/libfontconfig.so.1.4.4)
==4709==    by 0x3FD021DDC7: FcConfigParseAndLoad (in
/usr/lib64/libfontconfig.so.1.4.4)
==4709==    by 0x3FD021E04D: ??? (in /usr/lib64/libfontconfig.so.1.4.4)
==4709==    by 0x3FCF60A68A: ??? (in /lib64/libexpat.so.1.5.2)
==4709==    by 0x3FCF60B8CD: ??? (in /lib64/libexpat.so.1.5.2)
==4709==    by 0x3FCF60878E: ??? (in /lib64/libexpat.so.1.5.2)
==4709==    by 0x3FCF60A11A: ??? (in /lib64/libexpat.so.1.5.2)
==4709==    by 0x3FCF60D6E1: XML_ParseBuffer (in /lib64/libexpat.so.1.5.2)
==4709==    by 0x3FD021DAC0: FcConfigParseAndLoad (in
/usr/lib64/libfontconfig.so.1.4.4)
==4709==    by 0x3FD02130C6: FcInitLoadConfig (in
/usr/lib64/libfontconfig.so.1.4.4)
==4709==    by 0x3FD02131B5: FcInitLoadConfigAndFonts (in
/usr/lib64/libfontconfig.so.1.4.4)
==4709==  Address 0x4e183c8 is 40 bytes inside a block of size 43 alloc'd
==4709==    at 0x4A074CD: malloc (vg_replace_malloc.c:236)
==4709==    by 0x3FD0207FDC: ??? (in /usr/lib64/libfontconfig.so.1.4.4)
==4709==    by 0x3FD021D965: FcConfigParseAndLoad (in
/usr/lib64/libfontconfig.so.1.4.4)
==4709==    by 0x3FD021DDC7: FcConfigParseAndLoad (in
/usr/lib64/libfontconfig.so.1.4.4)
==4709==    by 0x3FD021E04D: ??? (in /usr/lib64/libfontconfig.so.1.4.4)
==4709==    by 0x3FCF60A68A: ??? (in /lib64/libexpat.so.1.5.2)
==4709==    by 0x3FCF60B8CD: ??? (in /lib64/libexpat.so.1.5.2)
==4709==    by 0x3FCF60878E: ??? (in /lib64/libexpat.so.1.5.2)
==4709==    by 0x3FCF60A11A: ??? (in /lib64/libexpat.so.1.5.2)
==4709==    by 0x3FCF60D6E1: XML_ParseBuffer (in /lib64/libexpat.so.1.5.2)
==4709==    by 0x3FD021DAC0: FcConfigParseAndLoad (in
/usr/lib64/libfontconfig.so.1.4.4)
==4709==    by 0x3FD02130C6: FcInitLoadConfig (in
/usr/lib64/libfontconfig.so.1.4.4)
==4709==
==4709== Invalid read of size 4
==4709==    at 0x3FD0208083: ??? (in /usr/lib64/libfontconfig.so.1.4.4)
==4709==    by 0x3FD021D965: FcConfigParseAndLoad (in
/usr/lib64/libfontconfig.so.1.4.4)
==4709==    by 0x3FD021DDC7: FcConfigParseAndLoad (in
/usr/lib64/libfontconfig.so.1.4.4)
==4709==    by 0x3FD021E04D: ??? (in /usr/lib64/libfontconfig.so.1.4.4)
==4709==    by 0x3FCF60A68A: ??? (in /lib64/libexpat.so.1.5.2)
==4709==    by 0x3FCF60B8CD: ??? (in /lib64/libexpat.so.1.5.2)
==4709==    by 0x3FCF60878E: ??? (in /lib64/libexpat.so.1.5.2)
==4709==    by 0x3FCF60A11A: ??? (in /lib64/libexpat.so.1.5.2)
==4709==    by 0x3FCF60D6E1: XML_ParseBuffer (in /lib64/libexpat.so.1.5.2)
==4709==    by 0x3FD021DAC0: FcConfigParseAndLoad (in
/usr/lib64/libfontconfig.so.1.4.4)
==4709==    by 0x3FD02130C6: FcInitLoadConfig (in
/usr/lib64/libfontconfig.so.1.4.4)
==4709==    by 0x3FD02131B5: FcInitLoadConfigAndFonts (in
/usr/lib64/libfontconfig.so.1.4.4)
==4709==  Address 0x4e2afb4 is 36 bytes inside a block of size 39 alloc'd
==4709==    at 0x4A074CD: malloc (vg_replace_malloc.c:236)
==4709==    by 0x3FD0207FDC: ??? (in /usr/lib64/libfontconfig.so.1.4.4)
==4709==    by 0x3FD021D965: FcConfigParseAndLoad (in
/usr/lib64/libfontconfig.so.1.4.4)
==4709==    by 0x3FD021DDC7: FcConfigParseAndLoad (in
/usr/lib64/libfontconfig.so.1.4.4)
==4709==    by 0x3FD021E04D: ??? (in /usr/lib64/libfontconfig.so.1.4.4)
==4709==    by 0x3FCF60A68A: ??? (in /lib64/libexpat.so.1.5.2)
==4709==    by 0x3FCF60B8CD: ??? (in /lib64/libexpat.so.1.5.2)
==4709==    by 0x3FCF60878E: ??? (in /lib64/libexpat.so.1.5.2)
==4709==    by 0x3FCF60A11A: ??? (in /lib64/libexpat.so.1.5.2)
==4709==    by 0x3FCF60D6E1: XML_ParseBuffer (in /lib64/libexpat.so.1.5.2)
==4709==    by 0x3FD021DAC0: FcConfigParseAndLoad (in
/usr/lib64/libfontconfig.so.1.4.4)
==4709==    by 0x3FD02130C6: FcInitLoadConfig (in
/usr/lib64/libfontconfig.so.1.4.4)
==4709==
==4709== Invalid read of size 4
==4709==    at 0x3FD0208098: ??? (in /usr/lib64/libfontconfig.so.1.4.4)
==4709==    by 0x3FD021D965: FcConfigParseAndLoad (in
/usr/lib64/libfontconfig.so.1.4.4)
==4709==    by 0x3FD021E04D: ??? (in /usr/lib64/libfontconfig.so.1.4.4)
==4709==    by 0x3FCF60A68A: ??? (in /lib64/libexpat.so.1.5.2)
==4709==    by 0x3FCF60B8CD: ??? (in /lib64/libexpat.so.1.5.2)
==4709==    by 0x3FCF60878E: ??? (in /lib64/libexpat.so.1.5.2)
==4709==    by 0x3FCF60A11A: ??? (in /lib64/libexpat.so.1.5.2)
==4709==    by 0x3FCF60D6E1: XML_ParseBuffer (in /lib64/libexpat.so.1.5.2)
==4709==    by 0x3FD021DAC0: FcConfigParseAndLoad (in
/usr/lib64/libfontconfig.so.1.4.4)
==4709==    by 0x3FD021DDC7: FcConfigParseAndLoad (in
/usr/lib64/libfontconfig.so.1.4.4)
==4709==    by 0x3FD021E04D: ??? (in /usr/lib64/libfontconfig.so.1.4.4)
==4709==    by 0x3FCF60A68A: ??? (in /lib64/libexpat.so.1.5.2)
==4709==  Address 0x4e58aa8 is 24 bytes inside a block of size 27 alloc'd
==4709==    at 0x4A074CD: malloc (vg_replace_malloc.c:236)
==4709==    by 0x3FD0207FDC: ??? (in /usr/lib64/libfontconfig.so.1.4.4)
==4709==    by 0x3FD021D965: FcConfigParseAndLoad (in
/usr/lib64/libfontconfig.so.1.4.4)
==4709==    by 0x3FD021E04D: ??? (in /usr/lib64/libfontconfig.so.1.4.4)
==4709==    by 0x3FCF60A68A: ??? (in /lib64/libexpat.so.1.5.2)
==4709==    by 0x3FCF60B8CD: ??? (in /lib64/libexpat.so.1.5.2)
==4709==    by 0x3FCF60878E: ??? (in /lib64/libexpat.so.1.5.2)
==4709==    by 0x3FCF60A11A: ??? (in /lib64/libexpat.so.1.5.2)
==4709==    by 0x3FCF60D6E1: XML_ParseBuffer (in /lib64/libexpat.so.1.5.2)
==4709==    by 0x3FD021DAC0: FcConfigParseAndLoad (in
/usr/lib64/libfontconfig.so.1.4.4)
==4709==    by 0x3FD021DDC7: FcConfigParseAndLoad (in
/usr/lib64/libfontconfig.so.1.4.4)
==4709==    by 0x3FD021E04D: ??? (in /usr/lib64/libfontconfig.so.1.4.4)
==4709==
==4709== Invalid read of size 4
==4709==    at 0x3FD0208083: ??? (in /usr/lib64/libfontconfig.so.1.4.4)
==4709==    by 0x3FD020A447: FcConfigFilename (in
/usr/lib64/libfontconfig.so.1.4.4)
==4709==    by 0x3FD021D965: FcConfigParseAndLoad (in
/usr/lib64/libfontconfig.so.1.4.4)
==4709==    by 0x3FD021E04D: ??? (in /usr/lib64/libfontconfig.so.1.4.4)
==4709==    by 0x3FCF60A68A: ??? (in /lib64/libexpat.so.1.5.2)
==4709==    by 0x3FCF60B8CD: ??? (in /lib64/libexpat.so.1.5.2)
==4709==    by 0x3FCF60878E: ??? (in /lib64/libexpat.so.1.5.2)
==4709==    by 0x3FCF60A11A: ??? (in /lib64/libexpat.so.1.5.2)
==4709==    by 0x3FCF60D6E1: XML_ParseBuffer (in /lib64/libexpat.so.1.5.2)
==4709==    by 0x3FD021DAC0: FcConfigParseAndLoad (in
/usr/lib64/libfontconfig.so.1.4.4)
==4709==    by 0x3FD021DDC7: FcConfigParseAndLoad (in
/usr/lib64/libfontconfig.so.1.4.4)
==4709==    by 0x3FD021E04D: ??? (in /usr/lib64/libfontconfig.so.1.4.4)
==4709==  Address 0x4e69254 is 20 bytes inside a block of size 22 alloc'd
==4709==    at 0x4A074CD: malloc (vg_replace_malloc.c:236)
==4709==    by 0x3FD0207FDC: ??? (in /usr/lib64/libfontconfig.so.1.4.4)
==4709==    by 0x3FD020A447: FcConfigFilename (in
/usr/lib64/libfontconfig.so.1.4.4)
==4709==    by 0x3FD021D965: FcConfigParseAndLoad (in
/usr/lib64/libfontconfig.so.1.4.4)
==4709==    by 0x3FD021E04D: ??? (in /usr/lib64/libfontconfig.so.1.4.4)
==4709==    by 0x3FCF60A68A: ??? (in /lib64/libexpat.so.1.5.2)
==4709==    by 0x3FCF60B8CD: ??? (in /lib64/libexpat.so.1.5.2)
==4709==    by 0x3FCF60878E: ??? (in /lib64/libexpat.so.1.5.2)
==4709==    by 0x3FCF60A11A: ??? (in /lib64/libexpat.so.1.5.2)
==4709==    by 0x3FCF60D6E1: XML_ParseBuffer (in /lib64/libexpat.so.1.5.2)
==4709==    by 0x3FD021DAC0: FcConfigParseAndLoad (in
/usr/lib64/libfontconfig.so.1.4.4)
==4709==    by 0x3FD021DDC7: FcConfigParseAndLoad (in
/usr/lib64/libfontconfig.so.1.4.4)
==4709==
QSqlDatabasePrivate::removeDatabase: connection 'ConnectionTest' is
still in use, all queries will cease to work.
==4709== Invalid read of size 8
==4709==    at 0x3FD73C194A: ??? (in /usr/lib64/libQtGui.so.4.8.0)
==4709==    by 0x3FD758D453: ??? (in /usr/lib64/libQtGui.so.4.8.0)
==4709==    by 0x3FD759814D: ??? (in /usr/lib64/libQtGui.so.4.8.0)
==4709==    by 0x3FD7519A5E: QPainter::drawPixmap(QPointF const&,
QPixmap const&) (in /usr/lib64/libQtGui.so.4.8.0)
==4709==    by 0xBFB2796: ??? (in /usr/lib64/kde4/plugins/styles/oxygen.so)
==4709==    by 0xBFA5732: ??? (in /usr/lib64/kde4/plugins/styles/oxygen.so)
==4709==    by 0x3FD437F8A0: QMetaMethod::invoke(QObject*,
Qt::ConnectionType, QGenericReturnArgument, QGenericArgument,
QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument,
QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument,
QGenericArgument) const (in /usr/lib64/libQtCore.so.4.8.0)
==4709==    by 0x3FD4381BAF: QMetaObject::invokeMethod(QObject*, char
const*, Qt::ConnectionType, QGenericReturnArgument, QGenericArgument,
QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument,
QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument,
QGenericArgument) (in /usr/lib64/libQtCore.so.4.8.0)
==4709==    by 0x3FD76C5850:
QStyle::standardIcon(QStyle::StandardPixmap, QStyleOption const*,
QWidget const*) const (in /usr/lib64/libQtGui.so.4.8.0)
==4709==    by 0x3FD77BE068: ??? (in /usr/lib64/libQtGui.so.4.8.0)
==4709==    by 0x3FD77C00EF: ??? (in /usr/lib64/libQtGui.so.4.8.0)
==4709==    by 0x3FD77C038F: QDockWidget::QDockWidget(QWidget*,
QFlags<Qt::WindowType>) (in /usr/lib64/libQtGui.so.4.8.0)
==4709==  Address 0xc753ee0 is 896 bytes inside a block of size 900 alloc'd
==4709==    at 0x4A074CD: malloc (vg_replace_malloc.c:236)
==4709==    by 0x3FD7481B75: QImageData::create(QSize const&,
QImage::Format, int) (in /usr/lib64/libQtGui.so.4.8.0)
==4709==    by 0x3FD7482CEA: QImage::QImage(int, int, QImage::Format)
(in /usr/lib64/libQtGui.so.4.8.0)
==4709==    by 0x3FD74A9D64: QRasterPixmapData::resize(int, int) (in
/usr/lib64/libQtGui.so.4.8.0)
==4709==    by 0x3FD74A254D: QPixmapData::create(int, int,
QPixmapData::PixelType) (in /usr/lib64/libQtGui.so.4.8.0)
==4709==    by 0x3FD749AC96: QPixmap::init(int, int, int) (in
/usr/lib64/libQtGui.so.4.8.0)
==4709==    by 0x3FD749BFAC: QPixmap::QPixmap(int, int) (in
/usr/lib64/libQtGui.so.4.8.0)
==4709==    by 0xBFC925A: ??? (in /usr/lib64/kde4/plugins/styles/oxygen.so)
==4709==    by 0xBFB275A: ??? (in /usr/lib64/kde4/plugins/styles/oxygen.so)
==4709==    by 0xBFA5732: ??? (in /usr/lib64/kde4/plugins/styles/oxygen.so)
==4709==    by 0x3FD437F8A0: QMetaMethod::invoke(QObject*,
Qt::ConnectionType, QGenericReturnArgument, QGenericArgument,
QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument,
QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument,
QGenericArgument) const (in /usr/lib64/libQtCore.so.4.8.0)
==4709==    by 0x3FD4381BAF: QMetaObject::invokeMethod(QObject*, char
const*, Qt::ConnectionType, QGenericReturnArgument, QGenericArgument,
QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument,
QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument,
QGenericArgument) (in /usr/lib64/libQtCore.so.4.8.0)
==4709==
==4709== Invalid write of size 1
==4709==    at 0x3FC9F03DFC: __vsprintf_chk (in /lib64/libc-2.14.90.so)
==4709==    by 0x3FC9F03D3C: __sprintf_chk (in /lib64/libc-2.14.90.so)
==4709==    by 0x1EB89859: orc_code_region_allocate_codemem_dual_map (in
/usr/lib64/liborc-0.4.so.0.16.0)
==4709==    by 0x1EB89B16: orc_code_region_allocate_codemem (in
/usr/lib64/liborc-0.4.so.0.16.0)
==4709==    by 0x1EB89BD4: orc_code_region_new (in
/usr/lib64/liborc-0.4.so.0.16.0)
==4709==    by 0x1EB89C93: orc_code_region_get_free_chunk (in
/usr/lib64/liborc-0.4.so.0.16.0)
==4709==    by 0x1EB89D53: orc_code_allocate_codemem (in
/usr/lib64/liborc-0.4.so.0.16.0)
==4709==    by 0x1EB8D811: orc_program_compile_full (in
/usr/lib64/liborc-0.4.so.0.16.0)
==4709==    by 0x1E96EE9A: ??? (in
/usr/lib64/gstreamer-0.10/libgstaudioconvert.so)
==4709==    by 0x1E96C7D8: ??? (in
/usr/lib64/gstreamer-0.10/libgstaudioconvert.so)
==4709==    by 0x3FEB063BD7: ??? (in /usr/lib64/libgstreamer-0.10.so.0.29.0)
==4709==    by 0x3FEB064E6A: gst_plugin_load_file (in
/usr/lib64/libgstreamer-0.10.so.0.29.0)
==4709==  Address 0x4faa989 is 0 bytes after a block of size 9 alloc'd
==4709==    at 0x4A074CD: malloc (vg_replace_malloc.c:236)
==4709==    by 0x1EB89836: orc_code_region_allocate_codemem_dual_map (in
/usr/lib64/liborc-0.4.so.0.16.0)
==4709==    by 0x1EB89B16: orc_code_region_allocate_codemem (in
/usr/lib64/liborc-0.4.so.0.16.0)
==4709==    by 0x1EB89BD4: orc_code_region_new (in
/usr/lib64/liborc-0.4.so.0.16.0)
==4709==    by 0x1EB89C93: orc_code_region_get_free_chunk (in
/usr/lib64/liborc-0.4.so.0.16.0)
==4709==    by 0x1EB89D53: orc_code_allocate_codemem (in
/usr/lib64/liborc-0.4.so.0.16.0)
==4709==    by 0x1EB8D811: orc_program_compile_full (in
/usr/lib64/liborc-0.4.so.0.16.0)
==4709==    by 0x1E96EE9A: ??? (in
/usr/lib64/gstreamer-0.10/libgstaudioconvert.so)
==4709==    by 0x1E96C7D8: ??? (in
/usr/lib64/gstreamer-0.10/libgstaudioconvert.so)
==4709==    by 0x3FEB063BD7: ??? (in /usr/lib64/libgstreamer-0.10.so.0.29.0)
==4709==    by 0x3FEB064E6A: gst_plugin_load_file (in
/usr/lib64/libgstreamer-0.10.so.0.29.0)
==4709==    by 0x3FEB065CF2: gst_plugin_load_by_name (in
/usr/lib64/libgstreamer-0.10.so.0.29.0)
==4709==
==4709== Syscall param stat(file_name) points to unaddressable byte(s)
==4709==    at 0x3FC9EE1965: _xstat (in /lib64/libc-2.14.90.so)
==4709==    by 0x1EB89869: orc_code_region_allocate_codemem_dual_map (in
/usr/lib64/liborc-0.4.so.0.16.0)
==4709==    by 0x1EB89B16: orc_code_region_allocate_codemem (in
/usr/lib64/liborc-0.4.so.0.16.0)
==4709==    by 0x1EB89BD4: orc_code_region_new (in
/usr/lib64/liborc-0.4.so.0.16.0)
==4709==    by 0x1EB89C93: orc_code_region_get_free_chunk (in
/usr/lib64/liborc-0.4.so.0.16.0)
==4709==    by 0x1EB89D53: orc_code_allocate_codemem (in
/usr/lib64/liborc-0.4.so.0.16.0)
==4709==    by 0x1EB8D811: orc_program_compile_full (in
/usr/lib64/liborc-0.4.so.0.16.0)
==4709==    by 0x1E96EE9A: ??? (in
/usr/lib64/gstreamer-0.10/libgstaudioconvert.so)
==4709==    by 0x1E96C7D8: ??? (in
/usr/lib64/gstreamer-0.10/libgstaudioconvert.so)
==4709==    by 0x3FEB063BD7: ??? (in /usr/lib64/libgstreamer-0.10.so.0.29.0)
==4709==    by 0x3FEB064E6A: gst_plugin_load_file (in
/usr/lib64/libgstreamer-0.10.so.0.29.0)
==4709==    by 0x3FEB065CF2: gst_plugin_load_by_name (in
/usr/lib64/libgstreamer-0.10.so.0.29.0)
==4709==  Address 0x4faa989 is 0 bytes after a block of size 9 alloc'd
==4709==    at 0x4A074CD: malloc (vg_replace_malloc.c:236)
==4709==    by 0x1EB89836: orc_code_region_allocate_codemem_dual_map (in
/usr/lib64/liborc-0.4.so.0.16.0)
==4709==    by 0x1EB89B16: orc_code_region_allocate_codemem (in
/usr/lib64/liborc-0.4.so.0.16.0)
==4709==    by 0x1EB89BD4: orc_code_region_new (in
/usr/lib64/liborc-0.4.so.0.16.0)
==4709==    by 0x1EB89C93: orc_code_region_get_free_chunk (in
/usr/lib64/liborc-0.4.so.0.16.0)
==4709==    by 0x1EB89D53: orc_code_allocate_codemem (in
/usr/lib64/liborc-0.4.so.0.16.0)
==4709==    by 0x1EB8D811: orc_program_compile_full (in
/usr/lib64/liborc-0.4.so.0.16.0)
==4709==    by 0x1E96EE9A: ??? (in
/usr/lib64/gstreamer-0.10/libgstaudioconvert.so)
==4709==    by 0x1E96C7D8: ??? (in
/usr/lib64/gstreamer-0.10/libgstaudioconvert.so)
==4709==    by 0x3FEB063BD7: ??? (in /usr/lib64/libgstreamer-0.10.so.0.29.0)
==4709==    by 0x3FEB064E6A: gst_plugin_load_file (in
/usr/lib64/libgstreamer-0.10.so.0.29.0)
==4709==    by 0x3FEB065CF2: gst_plugin_load_by_name (in
/usr/lib64/libgstreamer-0.10.so.0.29.0)
==4709==
==4709== Invalid read of size 4
==4709==    at 0x1EB898A7: orc_code_region_allocate_codemem_dual_map (in
/usr/lib64/liborc-0.4.so.0.16.0)
==4709==    by 0x1EB89B16: orc_code_region_allocate_codemem (in
/usr/lib64/liborc-0.4.so.0.16.0)
==4709==    by 0x1EB89BD4: orc_code_region_new (in
/usr/lib64/liborc-0.4.so.0.16.0)
==4709==    by 0x1EB89C93: orc_code_region_get_free_chunk (in
/usr/lib64/liborc-0.4.so.0.16.0)
==4709==    by 0x1EB89D53: orc_code_allocate_codemem (in
/usr/lib64/liborc-0.4.so.0.16.0)
==4709==    by 0x1EB8D811: orc_program_compile_full (in
/usr/lib64/liborc-0.4.so.0.16.0)
==4709==    by 0x1E96EE9A: ??? (in
/usr/lib64/gstreamer-0.10/libgstaudioconvert.so)
==4709==    by 0x1E96C7D8: ??? (in
/usr/lib64/gstreamer-0.10/libgstaudioconvert.so)
==4709==    by 0x3FEB063BD7: ??? (in /usr/lib64/libgstreamer-0.10.so.0.29.0)
==4709==    by 0x3FEB064E6A: gst_plugin_load_file (in
/usr/lib64/libgstreamer-0.10.so.0.29.0)
==4709==    by 0x3FEB065CF2: gst_plugin_load_by_name (in
/usr/lib64/libgstreamer-0.10.so.0.29.0)
==4709==    by 0x3FEB0666ED: gst_plugin_feature_load (in
/usr/lib64/libgstreamer-0.10.so.0.29.0)
==4709==  Address 0x4faa988 is 8 bytes inside a block of size 9 alloc'd
==4709==    at 0x4A074CD: malloc (vg_replace_malloc.c:236)
==4709==    by 0x1EB89836: orc_code_region_allocate_codemem_dual_map (in
/usr/lib64/liborc-0.4.so.0.16.0)
==4709==    by 0x1EB89B16: orc_code_region_allocate_codemem (in
/usr/lib64/liborc-0.4.so.0.16.0)
==4709==    by 0x1EB89BD4: orc_code_region_new (in
/usr/lib64/liborc-0.4.so.0.16.0)
==4709==    by 0x1EB89C93: orc_code_region_get_free_chunk (in
/usr/lib64/liborc-0.4.so.0.16.0)
==4709==    by 0x1EB89D53: orc_code_allocate_codemem (in
/usr/lib64/liborc-0.4.so.0.16.0)
==4709==    by 0x1EB8D811: orc_program_compile_full (in
/usr/lib64/liborc-0.4.so.0.16.0)
==4709==    by 0x1E96EE9A: ??? (in
/usr/lib64/gstreamer-0.10/libgstaudioconvert.so)
==4709==    by 0x1E96C7D8: ??? (in
/usr/lib64/gstreamer-0.10/libgstaudioconvert.so)
==4709==    by 0x3FEB063BD7: ??? (in /usr/lib64/libgstreamer-0.10.so.0.29.0)
==4709==    by 0x3FEB064E6A: gst_plugin_load_file (in
/usr/lib64/libgstreamer-0.10.so.0.29.0)
==4709==    by 0x3FEB065CF2: gst_plugin_load_by_name (in
/usr/lib64/libgstreamer-0.10.so.0.29.0)
==4709==
==4709== Invalid read of size 1
==4709==    at 0x3FC9E4A2B4: vfprintf (in /lib64/libc-2.14.90.so)
==4709==    by 0x3FC9F03DF6: __vsprintf_chk (in /lib64/libc-2.14.90.so)
==4709==    by 0x3FC9F03D3C: __sprintf_chk (in /lib64/libc-2.14.90.so)
==4709==    by 0x1EB898F2: orc_code_region_allocate_codemem_dual_map (in
/usr/lib64/liborc-0.4.so.0.16.0)
==4709==    by 0x1EB89B16: orc_code_region_allocate_codemem (in
/usr/lib64/liborc-0.4.so.0.16.0)
==4709==    by 0x1EB89BD4: orc_code_region_new (in
/usr/lib64/liborc-0.4.so.0.16.0)
==4709==    by 0x1EB89C93: orc_code_region_get_free_chunk (in
/usr/lib64/liborc-0.4.so.0.16.0)
==4709==    by 0x1EB89D53: orc_code_allocate_codemem (in
/usr/lib64/liborc-0.4.so.0.16.0)
==4709==    by 0x1EB8D811: orc_program_compile_full (in
/usr/lib64/liborc-0.4.so.0.16.0)
==4709==    by 0x1E96EE9A: ??? (in
/usr/lib64/gstreamer-0.10/libgstaudioconvert.so)
==4709==    by 0x1E96C7D8: ??? (in
/usr/lib64/gstreamer-0.10/libgstaudioconvert.so)
==4709==    by 0x3FEB063BD7: ??? (in /usr/lib64/libgstreamer-0.10.so.0.29.0)
==4709==  Address 0x4faa989 is 0 bytes after a block of size 9 alloc'd
==4709==    at 0x4A074CD: malloc (vg_replace_malloc.c:236)
==4709==    by 0x1EB89836: orc_code_region_allocate_codemem_dual_map (in
/usr/lib64/liborc-0.4.so.0.16.0)
==4709==    by 0x1EB89B16: orc_code_region_allocate_codemem (in
/usr/lib64/liborc-0.4.so.0.16.0)
==4709==    by 0x1EB89BD4: orc_code_region_new (in
/usr/lib64/liborc-0.4.so.0.16.0)
==4709==    by 0x1EB89C93: orc_code_region_get_free_chunk (in
/usr/lib64/liborc-0.4.so.0.16.0)
==4709==    by 0x1EB89D53: orc_code_allocate_codemem (in
/usr/lib64/liborc-0.4.so.0.16.0)
==4709==    by 0x1EB8D811: orc_program_compile_full (in
/usr/lib64/liborc-0.4.so.0.16.0)
==4709==    by 0x1E96EE9A: ??? (in
/usr/lib64/gstreamer-0.10/libgstaudioconvert.so)
==4709==    by 0x1E96C7D8: ??? (in
/usr/lib64/gstreamer-0.10/libgstaudioconvert.so)
==4709==    by 0x3FEB063BD7: ??? (in /usr/lib64/libgstreamer-0.10.so.0.29.0)
==4709==    by 0x3FEB064E6A: gst_plugin_load_file (in
/usr/lib64/libgstreamer-0.10.so.0.29.0)
==4709==    by 0x3FEB065CF2: gst_plugin_load_by_name (in
/usr/lib64/libgstreamer-0.10.so.0.29.0)
==4709==
digikam(4709) KWidgetItemDelegateEventListener::eventFilter: User of
KWidgetItemDelegate should not delete widgets created by createItemWidgets!
digikam(4709) KWidgetItemDelegateEventListener::eventFilter: User of
KWidgetItemDelegate should not delete widgets created by createItemWidgets!
digikam(4709) KWidgetItemDelegateEventListener::eventFilter: User of
KWidgetItemDelegate should not delete widgets created by createItemWidgets!
digikam(4709) KWidgetItemDelegateEventListener::eventFilter: User of
KWidgetItemDelegate should not delete widgets created by createItemWidgets!
digikam(4709) KWidgetItemDelegateEventListener::eventFilter: User of
KWidgetItemDelegate should not delete widgets created by createItemWidgets!
digikam(4709) KWidgetItemDelegateEventListener::eventFilter: User of
KWidgetItemDelegate should not delete widgets created by createItemWidgets!
digikam(4709) KWidgetItemDelegateEventListener::eventFilter: User of
KWidgetItemDelegate should not delete widgets created by createItemWidgets!
digikam(4709) KWidgetItemDelegateEventListener::eventFilter: User of
KWidgetItemDelegate should not delete widgets created by createItemWidgets!
==4709== Invalid read of size 1
==4709==    at 0x3FD784D9BA:
QToolButton::mouseReleaseEvent(QMouseEvent*) (in
/usr/lib64/libQtGui.so.4.8.0)
==4709==    by 0x3FD7419D89: QWidget::event(QEvent*) (in
/usr/lib64/libQtGui.so.4.8.0)
==4709==    by 0x3FD73C96F3:
QApplicationPrivate::notify_helper(QObject*, QEvent*) (in
/usr/lib64/libQtGui.so.4.8.0)
==4709==    by 0x3FD73CEE42: QApplication::notify(QObject*, QEvent*) (in
/usr/lib64/libQtGui.so.4.8.0)
==4709==    by 0x37EF250395: KApplication::notify(QObject*, QEvent*) (in
/usr/lib64/libkdeui.so.5.7.0)
==4709==    by 0x3FD4377B4B: QCoreApplication::notifyInternal(QObject*,
QEvent*) (in /usr/lib64/libQtCore.so.4.8.0)
==4709==    by 0x3FD73CA6C1:
QApplicationPrivate::sendMouseEvent(QWidget*, QMouseEvent*, QWidget*,
QWidget*, QWidget**, QPointer<QWidget>&, bool) (in
/usr/lib64/libQtGui.so.4.8.0)
==4709==    by 0x3FD7446044: ??? (in /usr/lib64/libQtGui.so.4.8.0)
==4709==    by 0x3FD7444F09: QApplication::x11ProcessEvent(_XEvent*) (in
/usr/lib64/libQtGui.so.4.8.0)
==4709==    by 0x3FD746C74B: ??? (in /usr/lib64/libQtGui.so.4.8.0)
==4709==    by 0x3FC9A44A7C: g_main_context_dispatch (in
/lib64/libglib-2.0.so.0.3000.1)
==4709==    by 0x3FC9A45277: ??? (in /lib64/libglib-2.0.so.0.3000.1)
==4709==  Address 0x1fb3637c is 620 bytes inside a block of size 648 free'd
==4709==    at 0x4A062BC: operator delete(void*) (vg_replace_malloc.c:387)
==4709==    by 0x3FD439016F: QObject::~QObject() (in
/usr/lib64/libQtCore.so.4.8.0)
==4709==    by 0x3FD741446C: QWidget::~QWidget() (in
/usr/lib64/libQtGui.so.4.8.0)
==4709==    by 0x3FD784D938: QToolButton::~QToolButton() (in
/usr/lib64/libQtGui.so.4.8.0)
==4709==    by 0x37EF2308A8: ??? (in /usr/lib64/libkdeui.so.5.7.0)
==4709==    by 0x3FD438B7D0: QMetaObject::activate(QObject*, QMetaObject
const*, int, void**) (in /usr/lib64/libQtCore.so.4.8.0)
==4709==    by 0x3FD43D76A3:
QAbstractItemModel::rowsAboutToBeRemoved(QModelIndex const&, int, int)
(in /usr/lib64/libQtCore.so.4.8.0)
==4709==    by 0x3FD4371BD7:
QAbstractItemModel::beginRemoveRows(QModelIndex const&, int, int) (in
/usr/lib64/libQtCore.so.4.8.0)
==4709==    by 0x4C4D6D: ??? (in /usr/bin/digikam)
==4709==    by 0x3FD438B7D0: QMetaObject::activate(QObject*, QMetaObject
const*, int, void**) (in /usr/lib64/libQtCore.so.4.8.0)
==4709==    by 0x4C257E: ??? (in /usr/bin/digikam)
==4709==    by 0x3FD438B7D0: QMetaObject::activate(QObject*, QMetaObject
const*, int, void**) (in /usr/lib64/libQtCore.so.4.8.0)
==4709==
digikam(4709) KWidgetItemDelegateEventListener::eventFilter: User of
KWidgetItemDelegate should not delete widgets created by createItemWidgets!
digikam(4709) KWidgetItemDelegateEventListener::eventFilter: User of
KWidgetItemDelegate should not delete widgets created by createItemWidgets!
digikam(4709) KWidgetItemDelegateEventListener::eventFilter: User of
KWidgetItemDelegate should not delete widgets created by createItemWidgets!
digikam(4709) KWidgetItemDelegateEventListener::eventFilter: User of
KWidgetItemDelegate should not delete widgets created by createItemWidgets!
digikam(4709) KWidgetItemDelegateEventListener::eventFilter: User of
KWidgetItemDelegate should not delete widgets created by createItemWidgets!
digikam(4709) KWidgetItemDelegateEventListener::eventFilter: User of
KWidgetItemDelegate should not delete widgets created by createItemWidgets!
digikam(4709) KWidgetItemDelegateEventListener::eventFilter: User of
KWidgetItemDelegate should not delete widgets created by createItemWidgets!
digikam(4709) KWidgetItemDelegateEventListener::eventFilter: User of
KWidgetItemDelegate should not delete widgets created by createItemWidgets!
digikam(4709) KWidgetItemDelegateEventListener::eventFilter: User of
KWidgetItemDelegate should not delete widgets created by createItemWidgets!
digikam(4709) KWidgetItemDelegateEventListener::eventFilter: User of
KWidgetItemDelegate should not delete widgets created by createItemWidgets!
digikam(4709) KWidgetItemDelegateEventListener::eventFilter: User of
KWidgetItemDelegate should not delete widgets created by createItemWidgets!
digikam(4709) KWidgetItemDelegateEventListener::eventFilter: User of
KWidgetItemDelegate should not delete widgets created by createItemWidgets!
digikam(4709) KWidgetItemDelegateEventListener::eventFilter: User of
KWidgetItemDelegate should not delete widgets created by createItemWidgets!
digikam(4709) KWidgetItemDelegateEventListener::eventFilter: User of
KWidgetItemDelegate should not delete widgets created by createItemWidgets!
digikam(4709) KWidgetItemDelegateEventListener::eventFilter: User of
KWidgetItemDelegate should not delete widgets created by createItemWidgets!
digikam(4709) KWidgetItemDelegateEventListener::eventFilter: User of
KWidgetItemDelegate should not delete widgets created by createItemWidgets!
digikam(4709) KWidgetItemDelegateEventListener::eventFilter: User of
KWidgetItemDelegate should not delete widgets created by createItemWidgets!
digikam(4709) KWidgetItemDelegateEventListener::eventFilter: User of
KWidgetItemDelegate should not delete widgets created by createItemWidgets!
digikam(4709) KWidgetItemDelegateEventListener::eventFilter: User of
KWidgetItemDelegate should not delete widgets created by createItemWidgets!
digikam(4709) KWidgetItemDelegateEventListener::eventFilter: User of
KWidgetItemDelegate should not delete widgets created by createItemWidgets!
digikam(4709) KWidgetItemDelegateEventListener::eventFilter: User of
KWidgetItemDelegate should not delete widgets created by createItemWidgets!
digikam(4709) KWidgetItemDelegateEventListener::eventFilter: User of
KWidgetItemDelegate should not delete widgets created by createItemWidgets!
digikam(4709) KWidgetItemDelegateEventListener::eventFilter: User of
KWidgetItemDelegate should not delete widgets created by createItemWidgets!
digikam(4709) KWidgetItemDelegateEventListener::eventFilter: User of
KWidgetItemDelegate should not delete widgets created by createItemWidgets!
digikam(4709) KWidgetItemDelegateEventListener::eventFilter: User of
KWidgetItemDelegate should not delete widgets created by createItemWidgets!
digikam(4709) KWidgetItemDelegateEventListener::eventFilter: User of
KWidgetItemDelegate should not delete widgets created by createItemWidgets!
digikam(4709) KWidgetItemDelegateEventListener::eventFilter: User of
KWidgetItemDelegate should not delete widgets created by createItemWidgets!
digikam(4709) KWidgetItemDelegateEventListener::eventFilter: User of
KWidgetItemDelegate should not delete widgets created by createItemWidgets!
digikam(4709) KWidgetItemDelegateEventListener::eventFilter: User of
KWidgetItemDelegate should not delete widgets created by createItemWidgets!
digikam(4709) KWidgetItemDelegateEventListener::eventFilter: User of
KWidgetItemDelegate should not delete widgets created by createItemWidgets!
digikam(4709) KWidgetItemDelegateEventListener::eventFilter: User of
KWidgetItemDelegate should not delete widgets created by createItemWidgets!
digikam(4709) KWidgetItemDelegateEventListener::eventFilter: User of
KWidgetItemDelegate should not delete widgets created by createItemWidgets!
digikam(4709) KWidgetItemDelegateEventListener::eventFilter: User of
KWidgetItemDelegate should not delete widgets created by createItemWidgets!
digikam(4709) KWidgetItemDelegateEventListener::eventFilter: User of
KWidgetItemDelegate should not delete widgets created by createItemWidgets!
digikam(4709) KWidgetItemDelegateEventListener::eventFilter: User of
KWidgetItemDelegate should not delete widgets created by createItemWidgets!
digikam(4709) KWidgetItemDelegateEventListener::eventFilter: User of
KWidgetItemDelegate should not delete widgets created by createItemWidgets!
digikam(4709) KWidgetItemDelegateEventListener::eventFilter: User of
KWidgetItemDelegate should not delete widgets created by createItemWidgets!
digikam(4709) KWidgetItemDelegateEventListener::eventFilter: User of
KWidgetItemDelegate should not delete widgets created by createItemWidgets!
digikam(4709) KWidgetItemDelegateEventListener::eventFilter: User of
KWidgetItemDelegate should not delete widgets created by createItemWidgets!
digikam(4709) KWidgetItemDelegateEventListener::eventFilter: User of
KWidgetItemDelegate should not delete widgets created by createItemWidgets!
digikam(4709) KWidgetItemDelegateEventListener::eventFilter: User of
KWidgetItemDelegate should not delete widgets created by createItemWidgets!
digikam(4709) KWidgetItemDelegateEventListener::eventFilter: User of
KWidgetItemDelegate should not delete widgets created by createItemWidgets!
digikam(4709) KWidgetItemDelegateEventListener::eventFilter: User of
KWidgetItemDelegate should not delete widgets created by createItemWidgets!
digikam(4709) KWidgetItemDelegateEventListener::eventFilter: User of
KWidgetItemDelegate should not delete widgets created by createItemWidgets!
digikam(4709) KWidgetItemDelegateEventListener::eventFilter: User of
KWidgetItemDelegate should not delete widgets created by createItemWidgets!
digikam(4709) KWidgetItemDelegateEventListener::eventFilter: User of
KWidgetItemDelegate should not delete widgets created by createItemWidgets!
digikam(4709) KWidgetItemDelegateEventListener::eventFilter: User of
KWidgetItemDelegate should not delete widgets created by createItemWidgets!
digikam(4709) KWidgetItemDelegateEventListener::eventFilter: User of
KWidgetItemDelegate should not delete widgets created by createItemWidgets!
digikam(4709) KWidgetItemDelegateEventListener::eventFilter: User of
KWidgetItemDelegate should not delete widgets created by createItemWidgets!
digikam(4709) KWidgetItemDelegateEventListener::eventFilter: User of
KWidgetItemDelegate should not delete widgets created by createItemWidgets!
digikam(4709) KWidgetItemDelegateEventListener::eventFilter: User of
KWidgetItemDelegate should not delete widgets created by createItemWidgets!
digikam(4709) KWidgetItemDelegateEventListener::eventFilter: User of
KWidgetItemDelegate should not delete widgets created by createItemWidgets!
digikam(4709) KWidgetItemDelegateEventListener::eventFilter: User of
KWidgetItemDelegate should not delete widgets created by createItemWidgets!
digikam(4709) KWidgetItemDelegateEventListener::eventFilter: User of
KWidgetItemDelegate should not delete widgets created by createItemWidgets!
digikam(4709) KWidgetItemDelegateEventListener::eventFilter: User of
KWidgetItemDelegate should not delete widgets created by createItemWidgets!
digikam(4709) KWidgetItemDelegateEventListener::eventFilter: User of
KWidgetItemDelegate should not delete widgets created by createItemWidgets!
digikam(4709) KWidgetItemDelegateEventListener::eventFilter: User of
KWidgetItemDelegate should not delete widgets created by createItemWidgets!
digikam(4709) KWidgetItemDelegateEventListener::eventFilter: User of
KWidgetItemDelegate should not delete widgets created by createItemWidgets!
digikam(4709) KWidgetItemDelegateEventListener::eventFilter: User of
KWidgetItemDelegate should not delete widgets created by createItemWidgets!
digikam(4709) KWidgetItemDelegateEventListener::eventFilter: User of
KWidgetItemDelegate should not delete widgets created by createItemWidgets!
digikam(4709) KWidgetItemDelegateEventListener::eventFilter: User of
KWidgetItemDelegate should not delete widgets created by createItemWidgets!
digikam(4709) KWidgetItemDelegateEventListener::eventFilter: User of
KWidgetItemDelegate should not delete widgets created by createItemWidgets!
digikam(4709) KWidgetItemDelegateEventListener::eventFilter: User of
KWidgetItemDelegate should not delete widgets created by createItemWidgets!
digikam(4709) KWidgetItemDelegateEventListener::eventFilter: User of
KWidgetItemDelegate should not delete widgets created by createItemWidgets!
digikam(4709) KWidgetItemDelegateEventListener::eventFilter: User of
KWidgetItemDelegate should not delete widgets created by createItemWidgets!
digikam(4709) KWidgetItemDelegateEventListener::eventFilter: User of
KWidgetItemDelegate should not delete widgets created by createItemWidgets!
digikam(4709) KWidgetItemDelegateEventListener::eventFilter: User of
KWidgetItemDelegate should not delete widgets created by createItemWidgets!
digikam(4709) KWidgetItemDelegateEventListener::eventFilter: User of
KWidgetItemDelegate should not delete widgets created by createItemWidgets!
digikam(4709) KWidgetItemDelegateEventListener::eventFilter: User of
KWidgetItemDelegate should not delete widgets created by createItemWidgets!
digikam(4709) KWidgetItemDelegateEventListener::eventFilter: User of
KWidgetItemDelegate should not delete widgets created by createItemWidgets!
digikam(4709) KWidgetItemDelegateEventListener::eventFilter: User of
KWidgetItemDelegate should not delete widgets created by createItemWidgets!
digikam(4709) KWidgetItemDelegateEventListener::eventFilter: User of
KWidgetItemDelegate should not delete widgets created by createItemWidgets!
digikam(4709) KWidgetItemDelegateEventListener::eventFilter: User of
KWidgetItemDelegate should not delete widgets created by createItemWidgets!
digikam(4709) KWidgetItemDelegateEventListener::eventFilter: User of
KWidgetItemDelegate should not delete widgets created by createItemWidgets!
digikam(4709) KWidgetItemDelegateEventListener::eventFilter: User of
KWidgetItemDelegate should not delete widgets created by createItemWidgets!
digikam(4709) KWidgetItemDelegateEventListener::eventFilter: User of
KWidgetItemDelegate should not delete widgets created by createItemWidgets!
digikam(4709) KWidgetItemDelegateEventListener::eventFilter: User of
KWidgetItemDelegate should not delete widgets created by createItemWidgets!
digikam(4709) KWidgetItemDelegateEventListener::eventFilter: User of
KWidgetItemDelegate should not delete widgets created by createItemWidgets!
digikam(4709) KWidgetItemDelegateEventListener::eventFilter: User of
KWidgetItemDelegate should not delete widgets created by createItemWidgets!
digikam(4709) KWidgetItemDelegateEventListener::eventFilter: User of
KWidgetItemDelegate should not delete widgets created by createItemWidgets!
digikam(4709) KWidgetItemDelegateEventListener::eventFilter: User of
KWidgetItemDelegate should not delete widgets created by createItemWidgets!
digikam(4709) KWidgetItemDelegateEventListener::eventFilter: User of
KWidgetItemDelegate should not delete widgets created by createItemWidgets!
digikam(4709) KWidgetItemDelegateEventListener::eventFilter: User of
KWidgetItemDelegate should not delete widgets created by createItemWidgets!
digikam(4709) KWidgetItemDelegateEventListener::eventFilter: User of
KWidgetItemDelegate should not delete widgets created by createItemWidgets!
digikam(4709) KWidgetItemDelegateEventListener::eventFilter: User of
KWidgetItemDelegate should not delete widgets created by createItemWidgets!
digikam(4709) KWidgetItemDelegateEventListener::eventFilter: User of
KWidgetItemDelegate should not delete widgets created by createItemWidgets!
digikam(4709) KWidgetItemDelegateEventListener::eventFilter: User of
KWidgetItemDelegate should not delete widgets created by createItemWidgets!
digikam(4709) KWidgetItemDelegateEventListener::eventFilter: User of
KWidgetItemDelegate should not delete widgets created by createItemWidgets!
digikam(4709) KWidgetItemDelegateEventListener::eventFilter: User of
KWidgetItemDelegate should not delete widgets created by createItemWidgets!
digikam(4709) KWidgetItemDelegateEventListener::eventFilter: User of
KWidgetItemDelegate should not delete widgets created by createItemWidgets!
digikam(4709) KWidgetItemDelegateEventListener::eventFilter: User of
KWidgetItemDelegate should not delete widgets created by createItemWidgets!
digikam(4709) KWidgetItemDelegateEventListener::eventFilter: User of
KWidgetItemDelegate should not delete widgets created by createItemWidgets!
--4709:0:aspacem  Valgrind: FATAL: VG_N_SEGMENTS is too low.
--4709:0:aspacem    Increase it and rebuild.  Exiting now.


On 11/14/2011 11:38 PM, Alberto Ferrante wrote:

> Dear Gilles,
> attached to this message you can find the log. As you can see at the end
> the program was terminated after having filled all the available memory
> (20GB!) after having read 4'600 jpgs. The "invalid read" you see in the
> report are generated at the beginning of the execution, before starting
> to import a collection.
>
> I do not think that one solution would be to divide the processing of
> data in "chunks": the program should not wait at the end of the scan to
> do all the processing, it should do it after it read X (100?) files.

--
Home page: http://www.alari.ch/people/alberto
Photo galleries : http://albertoferrante.name
Public key: http://www.alari.ch/people/alberto/keys/yahoo.asc
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users
Reply | Threaded
Open this post in threaded view
|

Re: Digikam memory usage

Erick Moreno
Alberto, next time, you can use http://pastebin.com. This is always a good practice.

Cheers
Erick Moreno

On Mon, Nov 14, 2011 at 7:41 PM, Alberto Ferrante <[hidden email]> wrote:
Sorry, the attachment was filtered out. The text of the log is now
online in the message:--

 
Erick Moreno
profiles.google.com/erickmoreno


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

Re: Digikam memory usage

Gilles Caulier-4
In reply to this post by Alberto Ferrante


2011/11/14 Alberto Ferrante <[hidden email]>
Dear Gilles,
attached to this message you can find the log. As you can see at the end
the program was terminated after having filled all the available memory
(20GB!) after having read 4'600 jpgs. The "invalid read" you see in the
report are generated at the beginning of the execution, before starting
to import a collection.

I do not think that one solution would be to divide the processing of
data in "chunks": the program should not wait at the end of the scan to
do all the processing, it should do it after it read X (100?) files.

But it do not scan whole memory card with your 4600 JPG !

Look in digiKam setup dialog, there is an option in Camera configuration. open Behavior tab and look if The first option is selected or not (Use date from metadata to sort...)

If yes, disable it and try again. 
 
Gilles Caulier

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

Re: Digikam memory usage

Gilles Caulier-4
In reply to this post by Alberto Ferrante
What is that :

KWidgetItemDelegate should not delete widgets created by createItemWidgets!
digikam(4709) KWidgetItemDelegateEventListener::eventFilter: User of
...

Sound like message generated by KDELibs. It's not reproducible here. Perhaps it's the problem. Which KDE version you use ? Can you copy and paste here the "Help/Components Info" dialog contents here ?

Best

Gilles Caulier


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

Re: Digikam memory usage

Alberto Ferrante
In reply to this post by Alberto Ferrante
Dear Gilles,

> What is that :
> KWidgetItemDelegate should not delete widgets created by createItemWidgets!
> digikam(4709) KWidgetItemDelegateEventListener::eventFilter: User of
> ...
>
> Sound like message generated by KDELibs. It's not reproducible here.
> Perhaps it's the problem. Which KDE version you use ? Can you copy and
> paste here the "Help/Components Info" dialog contents here ?

I don't know what is this, I will try to dig into this problem later.

KDE is the one shipped with Fedora 16 that is 4.7.3.
Here follow the component info (standard component from Fedora 16):
digiKam version 2.3.0
Exiv2 can write to Jp2: Yes
Exiv2 can write to Jpeg: Yes
Exiv2 can write to Pgf: Yes
Exiv2 can write to Png: Yes
Exiv2 can write to Tiff: Yes
Exiv2 supports XMP metadata: Yes
LibCImg: 130
LibClapack: internal library
LibExiv2: 0.21.1
LibJPEG: 62
LibJasper: 1.900.1
LibKDE: 4.7.3 (4.7.3)
LibKExiv2: 2.0.0
LibKGeoMap: 2.0.0
LibKdcraw: 2.0.0
LibLCMS: 119
LibPGF: 6.11.42 - internal library
LibPNG: 1.2.46
LibQt: 4.8.0
LibRaw: 0.13.5
LibTIFF: LIBTIFF, Version 3.9.5 Copyright (c) 1988-1996 Sam Leffler
Copyright (c) 1991-1996 Silicon Graphics, Inc.
Marble Widget: 0.12.0 (stable release)
Parallelized demosaicing: Yes
Database backend: QMYSQL
Database internal server: No
LibGphoto2: 2.4.11
LibKface: 2.0.0
LibKipi: 1.2.0
LibOpenCV: 2.3.1
Libface: 0.2


> But it do not scan whole memory card with your 4600 JPG !

I was *not* importing from a memory card, but a folder from my
collection. What I see is that digikam scans the whole folder and then
it does some processing (I did not check the code, it is the behavior I
see). In that second phase it uses an enormous amount of memory.

> Look in digiKam setup dialog, there is an option in Camera configuration.
> open Behavior tab and look if The first option is selected or not (Use date
> from metadata to sort...)

It is *not* enabled (and anyway I was not importing from camera).
At the moment I am reading jpgs only (I disabled raw and tif files).

Best,
        Alberto

--
Home page: http://www.alari.ch/people/alberto
Photo galleries : http://albertoferrante.name
Public key: http://www.alari.ch/people/alberto/keys/yahoo.asc
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users
Reply | Threaded
Open this post in threaded view
|

Re: Digikam memory usage

Alberto Ferrante
Dear Gilles,

>> Sound like message generated by KDELibs. It's not reproducible here.
>> Perhaps it's the problem. Which KDE version you use ? Can you copy and
>> paste here the "Help/Components Info" dialog contents here ?
>
> I don't know what is this, I will try to dig into this problem later.

I think this is related to some dialog used by Digikam. I get this error
also in other cases (e.g., after the removal of a collection). It sounds
like it is connected with the confirmation dialog even if I am not sure
about that.

Searching on the Internet about this error I found some other error logs
belonging to Digikam (as well as other application) with this error, so
it happens to other users too.

Regards,
        Alberto

--
Home page: http://www.alari.ch/people/alberto
Photo galleries : http://albertoferrante.name
Public key: http://www.alari.ch/people/alberto/keys/yahoo.asc
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users
Reply | Threaded
Open this post in threaded view
|

Re: Digikam memory usage

Gilles Caulier-4
In reply to this post by Alberto Ferrante
If you don't import from a card, which operation you do exactly, step by step ?

How do you import album into digiKam collection ?

Gilles Caulier

2011/11/15 Alberto Ferrante <[hidden email]>
Dear Gilles,

> What is that :
> KWidgetItemDelegate should not delete widgets created by createItemWidgets!
> digikam(4709) KWidgetItemDelegateEventListener::eventFilter: User of
> ...
>
> Sound like message generated by KDELibs. It's not reproducible here.
> Perhaps it's the problem. Which KDE version you use ? Can you copy and
> paste here the "Help/Components Info" dialog contents here ?

I don't know what is this, I will try to dig into this problem later.

KDE is the one shipped with Fedora 16 that is 4.7.3.
Here follow the component info (standard component from Fedora 16):
digiKam version 2.3.0
Exiv2 can write to Jp2: Yes
Exiv2 can write to Jpeg: Yes
Exiv2 can write to Pgf: Yes
Exiv2 can write to Png: Yes
Exiv2 can write to Tiff: Yes
Exiv2 supports XMP metadata: Yes
LibCImg: 130
LibClapack: internal library
LibExiv2: 0.21.1
LibJPEG: 62
LibJasper: 1.900.1
LibKDE: 4.7.3 (4.7.3)
LibKExiv2: 2.0.0
LibKGeoMap: 2.0.0
LibKdcraw: 2.0.0
LibLCMS: 119
LibPGF: 6.11.42 - internal library
LibPNG: 1.2.46
LibQt: 4.8.0
LibRaw: 0.13.5
LibTIFF: LIBTIFF, Version 3.9.5 Copyright (c) 1988-1996 Sam Leffler
Copyright (c) 1991-1996 Silicon Graphics, Inc.
Marble Widget: 0.12.0 (stable release)
Parallelized demosaicing: Yes
Database backend: QMYSQL
Database internal server: No
LibGphoto2: 2.4.11
LibKface: 2.0.0
LibKipi: 1.2.0
LibOpenCV: 2.3.1
Libface: 0.2


> But it do not scan whole memory card with your 4600 JPG !

I was *not* importing from a memory card, but a folder from my
collection. What I see is that digikam scans the whole folder and then
it does some processing (I did not check the code, it is the behavior I
see). In that second phase it uses an enormous amount of memory.

> Look in digiKam setup dialog, there is an option in Camera configuration.
> open Behavior tab and look if The first option is selected or not (Use date
> from metadata to sort...)

It is *not* enabled (and anyway I was not importing from camera).
At the moment I am reading jpgs only (I disabled raw and tif files).

Best,
       Alberto

--
Home page: http://www.alari.ch/people/alberto
Photo galleries : http://albertoferrante.name
Public key: http://www.alari.ch/people/alberto/keys/yahoo.asc
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users


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

Re: Digikam memory usage

Alberto Ferrante
In reply to this post by Alberto Ferrante
Dear Gilles,
what I do is:
Settings-> configure digikam-> Collections-> Add collection
and then I choose a folder on my hard drive.

Best,
        Alberto

> If you don't import from a card, which operation you do exactly, step by
> step ?
>
> How do you import album into digiKam collection ?


--
Home page: http://www.alari.ch/people/alberto
Photo galleries : http://albertoferrante.name
Public key: http://www.alari.ch/people/alberto/keys/yahoo.asc
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users
Reply | Threaded
Open this post in threaded view
|

Re: Digikam memory usage

Gilles Caulier-4
Ok, it's fully different way...

Now, open a console and start digiKam into gdb until it crash, and report trace.

Look here for details: 


Gilles Caulier

2011/11/15 Alberto Ferrante <[hidden email]>
Dear Gilles,
what I do is:
Settings-> configure digikam-> Collections-> Add collection
and then I choose a folder on my hard drive.

Best,
       Alberto

> If you don't import from a card, which operation you do exactly, step by
> step ?
>
> How do you import album into digiKam collection ?


--
Home page: http://www.alari.ch/people/alberto
Photo galleries : http://albertoferrante.name
Public key: http://www.alari.ch/people/alberto/keys/yahoo.asc
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users


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

Re: Digikam memory usage

Alberto Ferrante
In reply to this post by Alberto Ferrante
Gilles,
I do not think I will be able to do that soon, it takes time and I do
not have much at the moment. We anyway know already why it crashes: it
fills up all the available memory (8GB of RAM +14 of swap) and it gets
terminated. I monitored memory usage and this is what happens.
I can tell that the memory use increases with the number of images. It
is "acceptable" below 1-2'000 images; it becomes unacceptable above that
threshold.

If you can, please try importing a folder with, say, 10'000 images...
Are you able? How much memory is it using after the folder scan phase?

Regards,
        Alberto


> Ok, it's fully different way...
>
> Now, open a console and start digiKam into gdb until it crash, and report
> trace.
>
> Look here for details:
>
> https://projects.kde.org/projects/extragear/graphics/digikam/repository/revisions/master/entry/HACKING#L251

--
Home page: http://www.alari.ch/people/alberto
Photo galleries : http://albertoferrante.name
Public key: http://www.alari.ch/people/alberto/keys/yahoo.asc
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users
Reply | Threaded
Open this post in threaded view
|

Re: Digikam memory usage

Gilles Caulier-4


2011/11/15 Alberto Ferrante <[hidden email]>
Gilles,
I do not think I will be able to do that soon, it takes time and I do
not have much at the moment. We anyway know already why it crashes: it
fills up all the available memory (8GB of RAM +14 of swap) and it gets
terminated. I monitored memory usage and this is what happens.
I can tell that the memory use increases with the number of images. It
is "acceptable" below 1-2'000 images; it becomes unacceptable above that
threshold.

If you can, please try importing a folder with, say, 10'000 images...
Are you able? How much memory is it using after the folder scan phase?

yes, i can import 4000 image from my external HDD. No crash here. Both on my desktop (8Gb) and my laptop (3Gb). I can follow memory allocation without to see any memory leak.

So i suspect something wrong into an external dependency of digiKam, as libraw (if you import RAW file), or libexiv2 to read metadata and fill DB.

The valgrind trace is not enough informative.

To you import only JPEG, or RAW, or RAW+JPEG ?

Gilles Caulier

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

Re: Digikam memory usage

Alberto Ferrante
In reply to this post by Alberto Ferrante
Dear Gilles,

> yes, i can import 4000 image from my external HDD. No crash here. Both on
> my desktop (8Gb) and my laptop (3Gb). I can follow memory allocation
> without to see any memory leak.

OK.

> So i suspect something wrong into an external dependency of digiKam, as
> libraw (if you import RAW file), or libexiv2 to read metadata and fill DB.

I also suspect there is something wrong on Fedora with Digikam. There is
also a problem with MySQL (Digikam cannot create tables in the DB... I
had to create the DB by using Digikam in a virtual machine with Ubuntu,
export the DB and import it in my installation of MySQL). I opened a bug
on the Fedora bug tracking system (as it seems a distribution-related
problem) for that, but I had no replies so far.
In any case, I had the same problems when using SQLite (and this is one
of the reasons why I tried to move to MySQL).

> To you import only JPEG, or RAW, or RAW+JPEG ?

I import only JPEG images, no RAW and no TIFF.

Best regards,
        Alberto

--
Home page: http://www.alari.ch/people/alberto
Photo galleries : http://albertoferrante.name
Public key: http://www.alari.ch/people/alberto/keys/yahoo.asc
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users
Reply | Threaded
Open this post in threaded view
|

Re: Digikam memory usage

Alberto Ferrante
In reply to this post by Alberto Ferrante
Dear Gilles,
at the end I tried running Digikam through gdb (report below).
Unfortunately it does not show much useful information: the program is
not really crashing, as I said it is terminated after having filled all
the available memory.
I discovered one thing: besides my desktop PC, I have a laptop, also
with Fedora 16 64 bit installed. On that machine Digikam behavior seems
to be different. The memory usage seems reasonable there. It is pretty
strange as both machines have pretty standard installations of Fedora,
both of them with the proprietary Nvidia drivers. Is there any library
in particular that I should check?
I am wondering if it could be anything related to the number of cores in
the CPU... How many threads digikam starts while doing an import?

Regards,
    Alberto

======================================================================
gdb output (the backtrace was not available as the program did not crash):
======================================================================
Starting program: /usr/bin/digikam
warning: "/usr/lib/debug/usr/lib64/libQt3Support.so.4.8.0.debug":
separate debug info file has no debug info
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
[New Thread 0x7fffedcbf700 (LWP 22633)]
[New Thread 0x7fffed4be700 (LWP 22634)]
[New Thread 0x7fffe7fff700 (LWP 22635)]
[New Thread 0x7fffe77fe700 (LWP 22636)]
[Thread 0x7fffe77fe700 (LWP 22636) exited]
QSqlDatabasePrivate::removeDatabase: connection 'ConnectionTest' is
still in use, all queries will cease to work.
[Thread 0x7fffe7fff700 (LWP 22635) exited]
[New Thread 0x7fffe7fff700 (LWP 22638)]
[Thread 0x7fffe7fff700 (LWP 22638) exited]
[New Thread 0x7fffe7fff700 (LWP 22643)]
[New Thread 0x7fffe77fe700 (LWP 22644)]
[Thread 0x7fffe77fe700 (LWP 22644) exited]
[New Thread 0x7fffe77fe700 (LWP 22645)]
[New Thread 0x7fffcb7c7700 (LWP 22646)]
[Thread 0x7fffe77fe700 (LWP 22645) exited]
[Thread 0x7fffcb7c7700 (LWP 22646) exited]
[New Thread 0x7fffcb7c7700 (LWP 22654)]
[New Thread 0x7fffe77fe700 (LWP 22663)]
[New Thread 0x7fffcde98700 (LWP 22664)]
[New Thread 0x7fffcd697700 (LWP 22667)]
[New Thread 0x7fffc9c45700 (LWP 22675)]
Detaching after fork from child process 22676.
Detaching after fork from child process 22677.
[Thread 0x7fffcb7c7700 (LWP 22654) exited]
[Thread 0x7fffcd697700 (LWP 22667) exited]
[Thread 0x7fffe77fe700 (LWP 22663) exited]
[Thread 0x7fffcde98700 (LWP 22664) exited]
[New Thread 0x7fffcde98700 (LWP 22684)]
[Thread 0x7fffcde98700 (LWP 22684) exited]
[Thread 0x7fffc9c45700 (LWP 22675) exited]
[Thread 0x7fffed4be700 (LWP 22634) exited]
[Thread 0x7fffedcbf700 (LWP 22633) exited]
[Thread 0x7fffe7fff700 (LWP 22643) exited]

Program terminated with signal SIGKILL, Killed.
The program no longer exists.
======================================================================
======================================================================


On 11/15/2011 06:36 PM, Alberto Ferrante wrote:

> Gilles,
> I do not think I will be able to do that soon, it takes time and I do
> not have much at the moment. We anyway know already why it crashes: it
> fills up all the available memory (8GB of RAM +14 of swap) and it gets
> terminated. I monitored memory usage and this is what happens.
> I can tell that the memory use increases with the number of images. It
> is "acceptable" below 1-2'000 images; it becomes unacceptable above that
> threshold.
>
> If you can, please try importing a folder with, say, 10'000 images...
> Are you able? How much memory is it using after the folder scan phase?

--
Home page: http://www.alari.ch/people/alberto
Photo galleries : http://albertoferrante.name
Public key: http://www.alari.ch/people/alberto/keys/yahoo.asc
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users
Reply | Threaded
Open this post in threaded view
|

Re: Digikam memory usage

Alberto Ferrante
I tried to run digikam by setting a limit for data and for virtual
memory to 5GB and digikam crashed. Here follow the trace:

Application: digiKam (digikam), signal: Aborted
Using host libthread_db library "/lib64/libthread_db.so.1".
82 T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS)
[Current thread is 1 (Thread 0x7f7516b8da40 (LWP 23237))]

Thread 5 (Thread 0x7f750c8cc700 (LWP 23238)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at
../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:165
#1  0x00000031f407c02b in wait (time=18446744073709551615,
this=0x1999440) at thread/qwaitcondition_unix.cpp:86
#2  QWaitCondition::wait (this=<optimized out>, mutex=0x1999338,
time=18446744073709551615) at thread/qwaitcondition_unix.cpp:158
#3  0x00000000005c5d30 in Digikam::ScanController::run (this=0x19990d0)
at /usr/src/debug/digikam-2.3.0/core/digikam/database/scancontroller.cpp:647
#4  0x00000031f407bb1b in QThreadPrivate::start (arg=0x19990d0) at
thread/qthread_unix.cpp:298
#5  0x00000031ea007d90 in start_thread (arg=0x7f750c8cc700) at
pthread_create.c:309
#6  0x00000031e98eed0d in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:115

Thread 4 (Thread 0x7f7507fff700 (LWP 23239)):
#0  0x00000031ea009dd5 in __pthread_mutex_lock (mutex=0x7f75000009a8) at
pthread_mutex_lock.c:65
#1  0x00000031eb845064 in ?? () from /lib64/libglib-2.0.so.0
#2  0x00000031eb84544c in g_main_context_iteration () from
/lib64/libglib-2.0.so.0
#3  0x00000031f41a6896 in QEventDispatcherGlib::processEvents
(this=0x7f75000008c0, flags=<optimized out>) at
kernel/qeventdispatcher_glib.cpp:426
#4  0x00000031f4176c82 in QEventLoop::processEvents (this=<optimized
out>, flags=...) at kernel/qeventloop.cpp:149
#5  0x00000031f4176ed7 in QEventLoop::exec (this=0x7f7507ffeb10,
flags=...) at kernel/qeventloop.cpp:204
#6  0x00000031f4078ad7 in QThread::exec (this=<optimized out>) at
thread/qthread.cpp:501
#7  0x00000031f4156a5f in QInotifyFileSystemWatcherEngine::run
(this=0x198c1d0) at io/qfilesystemwatcher_inotify.cpp:248
#8  0x00000031f407bb1b in QThreadPrivate::start (arg=0x198c1d0) at
thread/qthread_unix.cpp:298
#9  0x00000031ea007d90 in start_thread (arg=0x7f7507fff700) at
pthread_create.c:309
#10 0x00000031e98eed0d in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:115

Thread 3 (Thread 0x7f75077fe700 (LWP 23248)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at
../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:165
#1  0x00000031f407c02b in wait (time=18446744073709551615,
this=0x1be9210) at thread/qwaitcondition_unix.cpp:86
#2  QWaitCondition::wait (this=<optimized out>, mutex=0x1be8f78,
time=18446744073709551615) at thread/qwaitcondition_unix.cpp:158
#3  0x00000039d47416a9 in Digikam::ParkingThread::run (this=0x1be8f60)
at /usr/src/debug/digikam-2.3.0/core/libs/threads/threadmanager.cpp:119
#4  0x00000031f407bb1b in QThreadPrivate::start (arg=0x1be8f60) at
thread/qthread_unix.cpp:298
#5  0x00000031ea007d90 in start_thread (arg=0x7f75077fe700) at
pthread_create.c:309
#6  0x00000031e98eed0d in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:115

Thread 2 (Thread 0x7f7506914700 (LWP 23289)):
#0  qt_qimageScaleAARGBA (isi=<optimized out>, dest=<optimized out>,
dxx=0, dyy=<optimized out>, dx=<optimized out>, dy=<optimized out>,
dw=256, dh=170, dow=256, sow=320) at painting/qimagescale.cpp:595
#1  0x00000031f73bb8d9 in qSmoothScaleImage (src=<optimized out>,
dw=256, dh=170) at painting/qimagescale.cpp:1025
#2  0x00000031f7286454 in smoothScaled (source=<optimized out>, w=256,
h=170) at image/qimage.cpp:6393
#3  0x00000031f72890a5 in QImage::transformed (this=0x7f7506913340,
matrix=<optimized out>, mode=Qt::SmoothTransformation) at
image/qimage.cpp:6585
#4  0x00000031f72894d4 in QImage::scaled (this=0x7f7506913340,
s=<optimized out>, aspectMode=Qt::KeepAspectRatio,
mode=Qt::SmoothTransformation) at image/qimage.cpp:4463
#5  0x00000039d4724153 in scaled (mode=Qt::SmoothTransformation,
aspectMode=Qt::KeepAspectRatio, h=256, w=<optimized out>,
this=0x7f7506913340) at /usr/include/QtGui/qimage.h:234
#6  Digikam::ThumbnailCreator::scaleForStorage (this=0x267c0b0,
qimage=..., isFace=<optimized out>) at
/usr/src/debug/digikam-2.3.0/core/libs/threadimageio/thumbnailcreator.cpp:321
#7  0x00000039d47292b1 in Digikam::ThumbnailCreator::createThumbnail
(this=0x267c0b0, info=<optimized out>, detailRect=<optimized out>,
isFace=false) at
/usr/src/debug/digikam-2.3.0/core/libs/threadimageio/thumbnailcreator.cpp:541
#8  0x00000039d4729cf0 in Digikam::ThumbnailCreator::load
(this=0x267c0b0, path=..., rect=..., pregenerate=false) at
/usr/src/debug/digikam-2.3.0/core/libs/threadimageio/thumbnailcreator.cpp:257
#9  0x00000039d472abc2 in Digikam::ThumbnailCreator::load
(this=<optimized out>, path=<optimized out>) at
/usr/src/debug/digikam-2.3.0/core/libs/threadimageio/thumbnailcreator.cpp:196
#10 0x00000039d4739d87 in Digikam::ThumbnailLoadingTask::execute
(this=0xc413a0c0) at
/usr/src/debug/digikam-2.3.0/core/libs/threadimageio/thumbnailtask.cpp:169
#11 0x00000039d4709efe in Digikam::LoadSaveThread::run (this=0x267c040)
at
/usr/src/debug/digikam-2.3.0/core/libs/threadimageio/loadsavethread.cpp:118
#12 0x00000039d474357e in Digikam::DynamicThread::DynamicThreadPriv::run
(this=0x267be60) at
/usr/src/debug/digikam-2.3.0/core/libs/threads/dynamicthread.cpp:328
#13 0x00000031f406f492 in QThreadPoolThread::run (this=0x6e89930) at
concurrent/qthreadpool.cpp:107
#14 0x00000031f407bb1b in QThreadPrivate::start (arg=0x6e89930) at
thread/qthread_unix.cpp:298
#15 0x00000031ea007d90 in start_thread (arg=0x7f7506914700) at
pthread_create.c:309
#16 0x00000031e98eed0d in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:115

Thread 1 (Thread 0x7f7516b8da40 (LWP 23237)):
[KCrash Handler]
#6  0x00000031e9836285 in __GI_raise (sig=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64
#7  0x00000031e9837b9b in __GI_abort () at abort.c:91
#8  0x00000031eccbbf8d in __gnu_cxx::__verbose_terminate_handler () at
../../../../libstdc++-v3/libsupc++/vterminate.cc:95
#9  0x00000031eccba146 in __cxxabiv1::__terminate (handler=<optimized
out>) at ../../../../libstdc++-v3/libsupc++/eh_terminate.cc:40
#10 0x00000031eccba173 in std::terminate () at
../../../../libstdc++-v3/libsupc++/eh_terminate.cc:50
#11 0x00000031eccba2b6 in __cxxabiv1::__cxa_rethrow () at
../../../../libstdc++-v3/libsupc++/eh_throw.cc:116
#12 0x00000031f417716c in QEventLoop::exec (this=<optimized out>,
flags=<optimized out>) at kernel/qeventloop.cpp:218
#13 0x00000031f417b8d5 in QCoreApplication::exec () at
kernel/qcoreapplication.cpp:1148
#14 0x000000000048b93d in main (argc=1, argv=<optimized out>) at
/usr/src/debug/digikam-2.3.0/core/digikam/main/main.cpp:232


On 12/03/2011 12:32 PM, Alberto Ferrante wrote:

> Dear Gilles,
> at the end I tried running Digikam through gdb (report below).
> Unfortunately it does not show much useful information: the program is
> not really crashing, as I said it is terminated after having filled all
> the available memory.
> I discovered one thing: besides my desktop PC, I have a laptop, also
> with Fedora 16 64 bit installed. On that machine Digikam behavior seems
> to be different. The memory usage seems reasonable there. It is pretty
> strange as both machines have pretty standard installations of Fedora,
> both of them with the proprietary Nvidia drivers. Is there any library
> in particular that I should check?
> I am wondering if it could be anything related to the number of cores in
> the CPU... How many threads digikam starts while doing an import?


--
Home page: http://www.alari.ch/people/alberto
Photo galleries : http://albertoferrante.name
Public key: http://www.alari.ch/people/alberto/keys/yahoo.asc
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users
Reply | Threaded
Open this post in threaded view
|

Re: Digikam memory usage

Gilles Caulier-4
Instead GDB, it's better to run digiKam through valgrind to see memory
leak, like it's explained here :

https://projects.kde.org/projects/extragear/graphics/digikam/repository/revisions/master/entry/HACKING#L281

Gilles Caulier

2011/12/3 Alberto Ferrante <[hidden email]>:

> I tried to run digikam by setting a limit for data and for virtual
> memory to 5GB and digikam crashed. Here follow the trace:
>
> Application: digiKam (digikam), signal: Aborted
> Using host libthread_db library "/lib64/libthread_db.so.1".
> 82      T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS)
> [Current thread is 1 (Thread 0x7f7516b8da40 (LWP 23237))]
>
> Thread 5 (Thread 0x7f750c8cc700 (LWP 23238)):
> #0  pthread_cond_wait@@GLIBC_2.3.2 () at
> ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:165
> #1  0x00000031f407c02b in wait (time=18446744073709551615,
> this=0x1999440) at thread/qwaitcondition_unix.cpp:86
> #2  QWaitCondition::wait (this=<optimized out>, mutex=0x1999338,
> time=18446744073709551615) at thread/qwaitcondition_unix.cpp:158
> #3  0x00000000005c5d30 in Digikam::ScanController::run (this=0x19990d0)
> at /usr/src/debug/digikam-2.3.0/core/digikam/database/scancontroller.cpp:647
> #4  0x00000031f407bb1b in QThreadPrivate::start (arg=0x19990d0) at
> thread/qthread_unix.cpp:298
> #5  0x00000031ea007d90 in start_thread (arg=0x7f750c8cc700) at
> pthread_create.c:309
> #6  0x00000031e98eed0d in clone () at
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:115
>
> Thread 4 (Thread 0x7f7507fff700 (LWP 23239)):
> #0  0x00000031ea009dd5 in __pthread_mutex_lock (mutex=0x7f75000009a8) at
> pthread_mutex_lock.c:65
> #1  0x00000031eb845064 in ?? () from /lib64/libglib-2.0.so.0
> #2  0x00000031eb84544c in g_main_context_iteration () from
> /lib64/libglib-2.0.so.0
> #3  0x00000031f41a6896 in QEventDispatcherGlib::processEvents
> (this=0x7f75000008c0, flags=<optimized out>) at
> kernel/qeventdispatcher_glib.cpp:426
> #4  0x00000031f4176c82 in QEventLoop::processEvents (this=<optimized
> out>, flags=...) at kernel/qeventloop.cpp:149
> #5  0x00000031f4176ed7 in QEventLoop::exec (this=0x7f7507ffeb10,
> flags=...) at kernel/qeventloop.cpp:204
> #6  0x00000031f4078ad7 in QThread::exec (this=<optimized out>) at
> thread/qthread.cpp:501
> #7  0x00000031f4156a5f in QInotifyFileSystemWatcherEngine::run
> (this=0x198c1d0) at io/qfilesystemwatcher_inotify.cpp:248
> #8  0x00000031f407bb1b in QThreadPrivate::start (arg=0x198c1d0) at
> thread/qthread_unix.cpp:298
> #9  0x00000031ea007d90 in start_thread (arg=0x7f7507fff700) at
> pthread_create.c:309
> #10 0x00000031e98eed0d in clone () at
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:115
>
> Thread 3 (Thread 0x7f75077fe700 (LWP 23248)):
> #0  pthread_cond_wait@@GLIBC_2.3.2 () at
> ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:165
> #1  0x00000031f407c02b in wait (time=18446744073709551615,
> this=0x1be9210) at thread/qwaitcondition_unix.cpp:86
> #2  QWaitCondition::wait (this=<optimized out>, mutex=0x1be8f78,
> time=18446744073709551615) at thread/qwaitcondition_unix.cpp:158
> #3  0x00000039d47416a9 in Digikam::ParkingThread::run (this=0x1be8f60)
> at /usr/src/debug/digikam-2.3.0/core/libs/threads/threadmanager.cpp:119
> #4  0x00000031f407bb1b in QThreadPrivate::start (arg=0x1be8f60) at
> thread/qthread_unix.cpp:298
> #5  0x00000031ea007d90 in start_thread (arg=0x7f75077fe700) at
> pthread_create.c:309
> #6  0x00000031e98eed0d in clone () at
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:115
>
> Thread 2 (Thread 0x7f7506914700 (LWP 23289)):
> #0  qt_qimageScaleAARGBA (isi=<optimized out>, dest=<optimized out>,
> dxx=0, dyy=<optimized out>, dx=<optimized out>, dy=<optimized out>,
> dw=256, dh=170, dow=256, sow=320) at painting/qimagescale.cpp:595
> #1  0x00000031f73bb8d9 in qSmoothScaleImage (src=<optimized out>,
> dw=256, dh=170) at painting/qimagescale.cpp:1025
> #2  0x00000031f7286454 in smoothScaled (source=<optimized out>, w=256,
> h=170) at image/qimage.cpp:6393
> #3  0x00000031f72890a5 in QImage::transformed (this=0x7f7506913340,
> matrix=<optimized out>, mode=Qt::SmoothTransformation) at
> image/qimage.cpp:6585
> #4  0x00000031f72894d4 in QImage::scaled (this=0x7f7506913340,
> s=<optimized out>, aspectMode=Qt::KeepAspectRatio,
> mode=Qt::SmoothTransformation) at image/qimage.cpp:4463
> #5  0x00000039d4724153 in scaled (mode=Qt::SmoothTransformation,
> aspectMode=Qt::KeepAspectRatio, h=256, w=<optimized out>,
> this=0x7f7506913340) at /usr/include/QtGui/qimage.h:234
> #6  Digikam::ThumbnailCreator::scaleForStorage (this=0x267c0b0,
> qimage=..., isFace=<optimized out>) at
> /usr/src/debug/digikam-2.3.0/core/libs/threadimageio/thumbnailcreator.cpp:321
> #7  0x00000039d47292b1 in Digikam::ThumbnailCreator::createThumbnail
> (this=0x267c0b0, info=<optimized out>, detailRect=<optimized out>,
> isFace=false) at
> /usr/src/debug/digikam-2.3.0/core/libs/threadimageio/thumbnailcreator.cpp:541
> #8  0x00000039d4729cf0 in Digikam::ThumbnailCreator::load
> (this=0x267c0b0, path=..., rect=..., pregenerate=false) at
> /usr/src/debug/digikam-2.3.0/core/libs/threadimageio/thumbnailcreator.cpp:257
> #9  0x00000039d472abc2 in Digikam::ThumbnailCreator::load
> (this=<optimized out>, path=<optimized out>) at
> /usr/src/debug/digikam-2.3.0/core/libs/threadimageio/thumbnailcreator.cpp:196
> #10 0x00000039d4739d87 in Digikam::ThumbnailLoadingTask::execute
> (this=0xc413a0c0) at
> /usr/src/debug/digikam-2.3.0/core/libs/threadimageio/thumbnailtask.cpp:169
> #11 0x00000039d4709efe in Digikam::LoadSaveThread::run (this=0x267c040)
> at
> /usr/src/debug/digikam-2.3.0/core/libs/threadimageio/loadsavethread.cpp:118
> #12 0x00000039d474357e in Digikam::DynamicThread::DynamicThreadPriv::run
> (this=0x267be60) at
> /usr/src/debug/digikam-2.3.0/core/libs/threads/dynamicthread.cpp:328
> #13 0x00000031f406f492 in QThreadPoolThread::run (this=0x6e89930) at
> concurrent/qthreadpool.cpp:107
> #14 0x00000031f407bb1b in QThreadPrivate::start (arg=0x6e89930) at
> thread/qthread_unix.cpp:298
> #15 0x00000031ea007d90 in start_thread (arg=0x7f7506914700) at
> pthread_create.c:309
> #16 0x00000031e98eed0d in clone () at
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:115
>
> Thread 1 (Thread 0x7f7516b8da40 (LWP 23237)):
> [KCrash Handler]
> #6  0x00000031e9836285 in __GI_raise (sig=6) at
> ../nptl/sysdeps/unix/sysv/linux/raise.c:64
> #7  0x00000031e9837b9b in __GI_abort () at abort.c:91
> #8  0x00000031eccbbf8d in __gnu_cxx::__verbose_terminate_handler () at
> ../../../../libstdc++-v3/libsupc++/vterminate.cc:95
> #9  0x00000031eccba146 in __cxxabiv1::__terminate (handler=<optimized
> out>) at ../../../../libstdc++-v3/libsupc++/eh_terminate.cc:40
> #10 0x00000031eccba173 in std::terminate () at
> ../../../../libstdc++-v3/libsupc++/eh_terminate.cc:50
> #11 0x00000031eccba2b6 in __cxxabiv1::__cxa_rethrow () at
> ../../../../libstdc++-v3/libsupc++/eh_throw.cc:116
> #12 0x00000031f417716c in QEventLoop::exec (this=<optimized out>,
> flags=<optimized out>) at kernel/qeventloop.cpp:218
> #13 0x00000031f417b8d5 in QCoreApplication::exec () at
> kernel/qcoreapplication.cpp:1148
> #14 0x000000000048b93d in main (argc=1, argv=<optimized out>) at
> /usr/src/debug/digikam-2.3.0/core/digikam/main/main.cpp:232
>
>
> On 12/03/2011 12:32 PM, Alberto Ferrante wrote:
>> Dear Gilles,
>> at the end I tried running Digikam through gdb (report below).
>> Unfortunately it does not show much useful information: the program is
>> not really crashing, as I said it is terminated after having filled all
>> the available memory.
>> I discovered one thing: besides my desktop PC, I have a laptop, also
>> with Fedora 16 64 bit installed. On that machine Digikam behavior seems
>> to be different. The memory usage seems reasonable there. It is pretty
>> strange as both machines have pretty standard installations of Fedora,
>> both of them with the proprietary Nvidia drivers. Is there any library
>> in particular that I should check?
>> I am wondering if it could be anything related to the number of cores in
>> the CPU... How many threads digikam starts while doing an import?
>
>
> --
> Home page: http://www.alari.ch/people/alberto
> Photo galleries : http://albertoferrante.name
> Public key: http://www.alari.ch/people/alberto/keys/yahoo.asc
> _______________________________________________
> Digikam-users mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-users
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users
12