[Digikam-devel] [CRASH] writing a png crashs digikam-SVN

Hi,

I have a problem with current SVN:

I display a JPG-image in IE, use the save as dialog to save this image as png.
This crashs digikam :-(
I do not get
[...]
kio (KTrader): query for ThumbCreator : returning 13 offers
kio (KTrader): query for ThumbCreator : returning 13 offers
kfile (kdelibs): Figure out an extension:
kfile (kdelibs):        getExtension (*.png,*.PNG)
kfile (kdelibs):                try: '*.png'
kfile (kdelibs):        setMimeFilter-style: pattern ext='.png'
kdecore (KAcceleratorManager): KAcceleratorManager::manage
kdecore (KAcceleratorManager): findAccelerators
kdecore (KAcceleratorManager): KAcceleratorManager::manage
kdecore (KAcceleratorManager): findAccelerators
kfile (kdelibs): slotOK
kio (KIOJob): stat file:///home/schnebeck/EOS/einTest/IMG_4876.png
kio (KIOJob): error 11 /home/schnebeck/EOS/einTest/IMG_4876.png
kfile (kdelibs): slotStatResult
kfile (kdelibs): ::urls()
kfile (kdelibs): ::urls()
kfile (kdelibs): KRecentDocument::add for
file:///home/schnebeck/EOS/einTest/IMG_4876.png
kio (KDirLister): [virtual void KDirLister::stop()]
kio (KDirListerCache): [void KDirListerCache::stop(KDirLister*)] lister:
0x20a9f310
digikam: Saving to :/home/schnebeck/EOS/einTest/BdFfxa.digikamtempfile.tmp
(png)
digikam: (800x533) JPEG image preview size: 31895 bytes
digikam: Writing Raw profile: type=exif, length=6327
==16944==
==16944== Thread 2:
==16944== Conditional jump or move depends on uninitialised value(s)
==16944==    at 0x1B90A4C5: strlen (mac_replace_strmem.c:189)
==16944==    by 0x1BC01E44:
Digikam::PNGLoader::writeRawProfile(png_struct_def*, png_info_struct*, char*,
char*, unsigned long) (in /usr/kde/3.5/lib/libdigikam.so.0.0.0)
digikam: Writing Raw profile: type=iptc, length=31940
==16944==
==16944== Invalid read of size 1
==16944==    at 0x1D4A15C0: adler32 (in /lib/libz.so.1.2.3)
==16944==  Address 0x20CE6320 is 0 bytes after a block of size 2032 alloc'd
==16944==    at 0x1B9092C5: malloc (vg_replace_malloc.c:130)
==16944==    by 0x1D3384DD: png_malloc_default
(in /usr/lib/libpng12.so.0.13.0)
==16944==
==16944== Invalid read of size 1
==16944==    at 0x1D4A15C3: adler32 (in /lib/libz.so.1.2.3)
==16944==  Address 0x20CE6321 is 1 bytes after a block of size 2032 alloc'd
==16944==    at 0x1B9092C5: malloc (vg_replace_malloc.c:130)
==16944==    by 0x1D3384DD: png_malloc_default
(in /usr/lib/libpng12.so.0.13.0)
==16944==
==16944== Invalid read of size 1
==16944==    at 0x1D4A15D0: adler32 (in /lib/libz.so.1.2.3)
==16944==  Address 0x20CE6322 is 2 bytes after a block of size 2032 alloc'd
==16944==    at 0x1B9092C5: malloc (vg_replace_malloc.c:130)
==16944==    by 0x1D3384DD: png_malloc_default
(in /usr/lib/libpng12.so.0.13.0)
==16944==
==16944== Invalid read of size 1
==16944==    at 0x1D4A15D8: adler32 (in /lib/libz.so.1.2.3)
==16944==  Address 0x20CE6323 is 3 bytes after a block of size 2032 alloc'd
==16944==    at 0x1B9092C5: malloc (vg_replace_malloc.c:130)
==16944==    by 0x1D3384DD: png_malloc_default
(in /usr/lib/libpng12.so.0.13.0)
==16944==
==16944== Invalid read of size 1
==16944==    at 0x1D4A15E0: adler32 (in /lib/libz.so.1.2.3)
==16944==  Address 0x20CE6324 is 4 bytes after a block of size 2032 alloc'd
==16944==    at 0x1B9092C5: malloc (vg_replace_malloc.c:130)
==16944==    by 0x1D3384DD: png_malloc_default
(in /usr/lib/libpng12.so.0.13.0)
==16944==
==16944== Invalid read of size 1
==16944==    at 0x1D4A15E8: adler32 (in /lib/libz.so.1.2.3)
==16944==  Address 0x20CE6325 is 5 bytes after a block of size 2032 alloc'd
==16944==    at 0x1B9092C5: malloc (vg_replace_malloc.c:130)
==16944==    by 0x1D3384DD: png_malloc_default
(in /usr/lib/libpng12.so.0.13.0)
==16944==
==16944== Invalid read of size 1
==16944==    at 0x1D4A15F0: adler32 (in /lib/libz.so.1.2.3)
==16944==  Address 0x20CE6326 is 6 bytes after a block of size 2032 alloc'd
==16944==    at 0x1B9092C5: malloc (vg_replace_malloc.c:130)
==16944==    by 0x1D3384DD: png_malloc_default
(in /usr/lib/libpng12.so.0.13.0)
==16944==
==16944== Invalid read of size 1
==16944==    at 0x1D4A15F8: adler32 (in /lib/libz.so.1.2.3)
==16944==  Address 0x20CE6327 is 7 bytes after a block of size 2032 alloc'd
==16944==    at 0x1B9092C5: malloc (vg_replace_malloc.c:130)
==16944==    by 0x1D3384DD: png_malloc_default
(in /usr/lib/libpng12.so.0.13.0)
==16944==
==16944== Invalid read of size 1
==16944==    at 0x1D4A1600: adler32 (in /lib/libz.so.1.2.3)
==16944==  Address 0x20CE6328 is 8 bytes after a block of size 2032 alloc'd
==16944==    at 0x1B9092C5: malloc (vg_replace_malloc.c:130)
==16944==    by 0x1D3384DD: png_malloc_default
(in /usr/lib/libpng12.so.0.13.0)
==16944==
==16944== Invalid read of size 1
==16944==    at 0x1D4A1608: adler32 (in /lib/libz.so.1.2.3)
==16944==  Address 0x20CE6329 is 9 bytes after a block of size 2032 alloc'd
==16944==    at 0x1B9092C5: malloc (vg_replace_malloc.c:130)
==16944==    by 0x1D3384DD: png_malloc_default
(in /usr/lib/libpng12.so.0.13.0)
==16944==
==16944== Invalid read of size 1
==16944==    at 0x1D4A1610: adler32 (in /lib/libz.so.1.2.3)
==16944==  Address 0x20CE632A is 10 bytes after a block of size 2032 alloc'd
==16944==    at 0x1B9092C5: malloc (vg_replace_malloc.c:130)
==16944==    by 0x1D3384DD: png_malloc_default
(in /usr/lib/libpng12.so.0.13.0)
==16944==
==16944== Invalid read of size 1
==16944==    at 0x1D4A1618: adler32 (in /lib/libz.so.1.2.3)
==16944==  Address 0x20CE632B is 11 bytes after a block of size 2032 alloc'd
==16944==    at 0x1B9092C5: malloc (vg_replace_malloc.c:130)
==16944==    by 0x1D3384DD: png_malloc_default
(in /usr/lib/libpng12.so.0.13.0)
==16944==
==16944== Invalid read of size 1
==16944==    at 0x1D4A1620: adler32 (in /lib/libz.so.1.2.3)
==16944==  Address 0x20CE632C is 12 bytes after a block of size 2032 alloc'd
==16944==    at 0x1B9092C5: malloc (vg_replace_malloc.c:130)
==16944==    by 0x1D3384DD: png_malloc_default
(in /usr/lib/libpng12.so.0.13.0)
==16944==
==16944== Invalid read of size 1
==16944==    at 0x1D4A1628: adler32 (in /lib/libz.so.1.2.3)
==16944==  Address 0x20CE632D is 13 bytes after a block of size 2032 alloc'd
==16944==    at 0x1B9092C5: malloc (vg_replace_malloc.c:130)
==16944==    by 0x1D3384DD: png_malloc_default
(in /usr/lib/libpng12.so.0.13.0)
==16944==
==16944== Invalid read of size 1
==16944==    at 0x1D4A1630: adler32 (in /lib/libz.so.1.2.3)
==16944==  Address 0x20CE632E is 14 bytes after a block of size 2032 alloc'd
==16944==    at 0x1B9092C5: malloc (vg_replace_malloc.c:130)
==16944==    by 0x1D3384DD: png_malloc_default
(in /usr/lib/libpng12.so.0.13.0)
==16944==
==16944== Invalid read of size 1
==16944==    at 0x1D4A1638: adler32 (in /lib/libz.so.1.2.3)
==16944==  Address 0x20CE632F is 15 bytes after a block of size 2032 alloc'd
==16944==    at 0x1B9092C5: malloc (vg_replace_malloc.c:130)
==16944==    by 0x1D3384DD: png_malloc_default
(in /usr/lib/libpng12.so.0.13.0)
==16944== Stack overflow in thread 2: can't grow stack to 0x20CE7000
KCrash: crashing... crashRecursionCounter = 2
KCrash: Application Name = digikam path = <unknown> pid = 16944
kio (KDirLister): -KDirLister
kio (KDirLister): [virtual void KDirLister::stop()]
kio (KDirListerCache): [void KDirListerCache::stop(KDirLister*)] lister:
0x20a9f310
kio (KDirListerCache): [void KDirListerCache::forgetDirs(KDirLister*)]
0x20a9f310
kio (KDirListerCache): [void KDirListerCache::forgetDirs(KDirLister*, const
KURL&, bool)] 0x20a9f310 _url: file:///home/schnebeck/EOS/einTest
kio (KDirListerCache): [void KDirListerCache::forgetDirs(KDirLister*, const
KURL&, bool)] 0x20a9f310 item moved into cache:
file:///home/schnebeck/EOS/einTest
ICE default IO error handler doing an exit(), pid = 16944, errno = 9
kio (KDirWatch): KDirWatchPrivate::removeEntry
for '/home/schnebeck/EOS/einTest' sub_entry: (nil)
kio (KDirWatch): removeEntry:
unwatched /home/schnebeck/EOS/einTest /home/schnebeck/EOS/einTest
kio (KDirListerCache): -KDirListerCache
==16944==
==16944== ERROR SUMMARY: 3342 errors from 27 contexts (suppressed: 7 from 1)
==16944== malloc/free: in use at exit: 63457601 bytes in 351298 blocks.
==16944== malloc/free: 2729509 allocs, 2378211 frees, 265248832 bytes
allocated.
==16944== For counts of detected errors, rerun with: -v
==16944== searching for pointers to 351298 not-freed blocks.
==16944== checked 82747112 bytes.
==16944==
==16944==
==16944== 288 bytes in 2 blocks are possibly lost in loss record 1013 of 1866
==16944==    at 0x1B909C70: calloc (vg_replace_malloc.c:175)
==16944==    by 0x1B8F45C8: allocate_dtv (in /lib/ld-2.4.so)
==16944==    by 0x1B8F468B: _dl_allocate_tls (in /lib/ld-2.4.so)
==16944==    by 0x1D4829FF: pthread_create@@GLIBC_2.1
(in /lib/libpthread-2.4.so)
==16944==    by 0x1BCFDB87: (within /usr/lib/libsqlite3.so.0.8.6)
==16944==
==16944==
==16944== 312 (72 direct, 240 indirect) bytes in 2 blocks are definitely lost
in loss record 1026 of 1866
==16944==    at 0x1B9092C5: malloc (vg_replace_malloc.c:130)
==16944==    by 0x1D73A639: (within /lib/libc-2.4.so)
==16944==    by 0x1D73AD36: __nss_database_lookup (in /lib/libc-2.4.so)
==16944==    by 0x1DBE7079: ???
==16944==    by 0x1DBE7D99: ???
==16944==    by 0x1D6F8C74: getpwuid_r (in /lib/libc-2.4.so)
==16944==    by 0x1D6F8669: getpwuid (in /lib/libc-2.4.so)
==16944==    by 0x1CB7B23C: (within /usr/qt/3/lib/libqt-mt.so.3.3.6)
==16944==    by 0x1CB7BB21: (within /usr/qt/3/lib/libqt-mt.so.3.3.6)
==16944==    by 0x1D355E27: _SmcProcessMessage (in /usr/lib/libSM.so.6.0.0)
==16944==
==16944==
==16944== 80 bytes in 2 blocks are definitely lost in loss record 1037 of 1866
==16944==    at 0x1B9092C5: malloc (vg_replace_malloc.c:130)
==16944==    by 0x1B8EE33E: _dl_new_object (in /lib/ld-2.4.so)
==16944==    by 0x1B8EA357: _dl_map_object_from_fd (in /lib/ld-2.4.so)
==16944==    by 0x1B8EC150: _dl_map_object (in /lib/ld-2.4.so)
==16944==    by 0x1B8EFD45: openaux (in /lib/ld-2.4.so)
==16944==    by 0x1B8F1541: _dl_catch_error (in /lib/ld-2.4.so)
==16944==    by 0x1B8EFF3C: _dl_map_object_deps (in /lib/ld-2.4.so)
==16944==    by 0x1B8F543E: dl_open_worker (in /lib/ld-2.4.so)
==16944==    by 0x1B8F1541: _dl_catch_error (in /lib/ld-2.4.so)
==16944==    by 0x1B8F4F08: _dl_open (in /lib/ld-2.4.so)
==16944==    by 0x1D562E3C: (within /lib/libdl-2.4.so)
==16944==    by 0x1B8F1541: _dl_catch_error (in /lib/ld-2.4.so)
==16944==
==16944==
==16944== 188 (128 direct, 60 indirect) bytes in 1 blocks are definitely lost
in loss record 1125 of 1866
==16944==    at 0x1B9092C5: malloc (vg_replace_malloc.c:130)
==16944==    by 0x1D179F8B: (within /usr/lib/libfontconfig.so.1.1.0)
==16944==
==16944==
==16944== 216 bytes in 1 blocks are definitely lost in loss record 1189 of
1866
==16944==    at 0x1B9092C5: malloc (vg_replace_malloc.c:130)
==16944==    by 0x1D3ED209: _XimOpenIM (in /usr/lib/libX11.so.6.2.0)
==16944==
==16944==
==16944== 584 (52 direct, 532 indirect) bytes in 1 blocks are definitely lost
in loss record 1439 of 1866
==16944==    at 0x1B909441: operator new(unsigned) (vg_replace_malloc.c:132)
==16944==    by 0x1C290741: KServiceTypeFactory::createEntry(int)
(kservicetypefactory.cpp:270)
==16944==
==16944==
==16944== 19556 (6912 direct, 12644 indirect) bytes in 18 blocks are
definitely lost in loss record 1808 of 1866
==16944==    at 0x1B909D6A: realloc (vg_replace_malloc.c:196)
==16944==    by 0x1D179EA3: (within /usr/lib/libfontconfig.so.1.1.0)
==16944==
==16944==
==16944== 12612 bytes in 3 blocks are definitely lost in loss record 1814 of
1866
==16944==    at 0x1B909D6A: realloc (vg_replace_malloc.c:196)
==16944==    by 0x1D197C42: (within /usr/lib/libfreetype.so.6.3.8)
==16944==
==16944==
==16944== 12643 bytes in 4 blocks are definitely lost in loss record 1815 of
1866
==16944==    at 0x1B9092C5: malloc (vg_replace_malloc.c:130)
==16944==    by 0x1D197BBA: (within /usr/lib/libfreetype.so.6.3.8)
==16944==
==16944== LEAK SUMMARY:
==16944==    definitely lost: 32715 bytes in 32 blocks.
==16944==    indirectly lost: 13476 bytes in 675 blocks.
==16944==      possibly lost: 288 bytes in 2 blocks.
==16944==    still reachable: 63411122 bytes in 350589 blocks.
==16944==         suppressed: 0 bytes in 0 blocks.
==16944== Reachable blocks (those to which a pointer was found) are not shown.
==16944== To see them, rerun with: --show-reachable=yes

Can someone second?

 digikam --version
Qt: 3.3.6
KDE: 3.5.5
digiKam: 0.9.0-rc2

exiv2-config --version
0.12

Bye

  Thorsten

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

Am Do Dez 14 2006 schrieb Thorsten Schnebeck:

Upps
> I display a JPG-image in IE, use the save as dialog to save this image as
> png. This crashs digikam :-(
> I do not get
... a valid backtrace but:

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

[Gilles Caulier-2]

Not reproductible here. I use every day PNG file format to save my photo. No
crash here...

Your report sound like a problem with your HDD free space/ or something is
broken in your KDE installation ?

> kio (KIOJob): stat file:///home/schnebeck/EOS/einTest/IMG_4876.png
> kio (KIOJob): error 11 /home/schnebeck/EOS/einTest/IMG_4876.png

Why KIOJob return an error just before than digiKam start the PNG stuff ?

Gilles

On Thursday 14 December 2006 21:04, Thorsten Schnebeck wrote:

> Hi,
>
> I have a problem with current SVN:
>
> I display a JPG-image in IE, use the save as dialog to save this image as
> png. This crashs digikam :-(
> I do not get
> [...]
> kio (KTrader): query for ThumbCreator : returning 13 offers
> kio (KTrader): query for ThumbCreator : returning 13 offers
> kfile (kdelibs): Figure out an extension:
> kfile (kdelibs):        getExtension (*.png,*.PNG)
> kfile (kdelibs):                try: '*.png'
> kfile (kdelibs):        setMimeFilter-style: pattern ext='.png'
> kdecore (KAcceleratorManager): KAcceleratorManager::manage
> kdecore (KAcceleratorManager): findAccelerators
> kdecore (KAcceleratorManager): KAcceleratorManager::manage
> kdecore (KAcceleratorManager): findAccelerators
> kfile (kdelibs): slotOK
> kio (KIOJob): stat file:///home/schnebeck/EOS/einTest/IMG_4876.png
> kio (KIOJob): error 11 /home/schnebeck/EOS/einTest/IMG_4876.png
> kfile (kdelibs): slotStatResult
> kfile (kdelibs): ::urls()
> kfile (kdelibs): ::urls()
> kfile (kdelibs): KRecentDocument::add for
> file:///home/schnebeck/EOS/einTest/IMG_4876.png
> kio (KDirLister): [virtual void KDirLister::stop()]
> kio (KDirListerCache): [void KDirListerCache::stop(KDirLister*)] lister:
> 0x20a9f310
> digikam: Saving to :/home/schnebeck/EOS/einTest/BdFfxa.digikamtempfile.tmp
> (png)
> digikam: (800x533) JPEG image preview size: 31895 bytes
> digikam: Writing Raw profile: type=exif, length=6327
> ==16944==
> ==16944== Thread 2:
> ==16944== Conditional jump or move depends on uninitialised value(s)
> ==16944==    at 0x1B90A4C5: strlen (mac_replace_strmem.c:189)
> ==16944==    by 0x1BC01E44:
> Digikam::PNGLoader::writeRawProfile(png_struct_def*, png_info_struct*,
> char*, char*, unsigned long) (in /usr/kde/3.5/lib/libdigikam.so.0.0.0)
> digikam: Writing Raw profile: type=iptc, length=31940
> ==16944==
> ==16944== Invalid read of size 1
> ==16944==    at 0x1D4A15C0: adler32 (in /lib/libz.so.1.2.3)
> ==16944==  Address 0x20CE6320 is 0 bytes after a block of size 2032 alloc'd
> ==16944==    at 0x1B9092C5: malloc (vg_replace_malloc.c:130)
> ==16944==    by 0x1D3384DD: png_malloc_default
> (in /usr/lib/libpng12.so.0.13.0)
> ==16944==
> ==16944== Invalid read of size 1
> ==16944==    at 0x1D4A15C3: adler32 (in /lib/libz.so.1.2.3)
> ==16944==  Address 0x20CE6321 is 1 bytes after a block of size 2032 alloc'd
> ==16944==    at 0x1B9092C5: malloc (vg_replace_malloc.c:130)
> ==16944==    by 0x1D3384DD: png_malloc_default
> (in /usr/lib/libpng12.so.0.13.0)
> ==16944==
> ==16944== Invalid read of size 1
> ==16944==    at 0x1D4A15D0: adler32 (in /lib/libz.so.1.2.3)
> ==16944==  Address 0x20CE6322 is 2 bytes after a block of size 2032 alloc'd
> ==16944==    at 0x1B9092C5: malloc (vg_replace_malloc.c:130)
> ==16944==    by 0x1D3384DD: png_malloc_default
> (in /usr/lib/libpng12.so.0.13.0)
> ==16944==
> ==16944== Invalid read of size 1
> ==16944==    at 0x1D4A15D8: adler32 (in /lib/libz.so.1.2.3)
> ==16944==  Address 0x20CE6323 is 3 bytes after a block of size 2032 alloc'd
> ==16944==    at 0x1B9092C5: malloc (vg_replace_malloc.c:130)
> ==16944==    by 0x1D3384DD: png_malloc_default
> (in /usr/lib/libpng12.so.0.13.0)
> ==16944==
> ==16944== Invalid read of size 1
> ==16944==    at 0x1D4A15E0: adler32 (in /lib/libz.so.1.2.3)
> ==16944==  Address 0x20CE6324 is 4 bytes after a block of size 2032 alloc'd
> ==16944==    at 0x1B9092C5: malloc (vg_replace_malloc.c:130)
> ==16944==    by 0x1D3384DD: png_malloc_default
> (in /usr/lib/libpng12.so.0.13.0)
> ==16944==
> ==16944== Invalid read of size 1
> ==16944==    at 0x1D4A15E8: adler32 (in /lib/libz.so.1.2.3)
> ==16944==  Address 0x20CE6325 is 5 bytes after a block of size 2032 alloc'd
> ==16944==    at 0x1B9092C5: malloc (vg_replace_malloc.c:130)
> ==16944==    by 0x1D3384DD: png_malloc_default
> (in /usr/lib/libpng12.so.0.13.0)
> ==16944==
> ==16944== Invalid read of size 1
> ==16944==    at 0x1D4A15F0: adler32 (in /lib/libz.so.1.2.3)
> ==16944==  Address 0x20CE6326 is 6 bytes after a block of size 2032 alloc'd
> ==16944==    at 0x1B9092C5: malloc (vg_replace_malloc.c:130)
> ==16944==    by 0x1D3384DD: png_malloc_default
> (in /usr/lib/libpng12.so.0.13.0)
> ==16944==
> ==16944== Invalid read of size 1
> ==16944==    at 0x1D4A15F8: adler32 (in /lib/libz.so.1.2.3)
> ==16944==  Address 0x20CE6327 is 7 bytes after a block of size 2032 alloc'd
> ==16944==    at 0x1B9092C5: malloc (vg_replace_malloc.c:130)
> ==16944==    by 0x1D3384DD: png_malloc_default
> (in /usr/lib/libpng12.so.0.13.0)
> ==16944==
> ==16944== Invalid read of size 1
> ==16944==    at 0x1D4A1600: adler32 (in /lib/libz.so.1.2.3)
> ==16944==  Address 0x20CE6328 is 8 bytes after a block of size 2032 alloc'd
> ==16944==    at 0x1B9092C5: malloc (vg_replace_malloc.c:130)
> ==16944==    by 0x1D3384DD: png_malloc_default
> (in /usr/lib/libpng12.so.0.13.0)
> ==16944==
> ==16944== Invalid read of size 1
> ==16944==    at 0x1D4A1608: adler32 (in /lib/libz.so.1.2.3)
> ==16944==  Address 0x20CE6329 is 9 bytes after a block of size 2032 alloc'd
> ==16944==    at 0x1B9092C5: malloc (vg_replace_malloc.c:130)
> ==16944==    by 0x1D3384DD: png_malloc_default
> (in /usr/lib/libpng12.so.0.13.0)
> ==16944==
> ==16944== Invalid read of size 1
> ==16944==    at 0x1D4A1610: adler32 (in /lib/libz.so.1.2.3)
> ==16944==  Address 0x20CE632A is 10 bytes after a block of size 2032
> alloc'd ==16944==    at 0x1B9092C5: malloc (vg_replace_malloc.c:130)
> ==16944==    by 0x1D3384DD: png_malloc_default
> (in /usr/lib/libpng12.so.0.13.0)
> ==16944==
> ==16944== Invalid read of size 1
> ==16944==    at 0x1D4A1618: adler32 (in /lib/libz.so.1.2.3)
> ==16944==  Address 0x20CE632B is 11 bytes after a block of size 2032
> alloc'd ==16944==    at 0x1B9092C5: malloc (vg_replace_malloc.c:130)
> ==16944==    by 0x1D3384DD: png_malloc_default
> (in /usr/lib/libpng12.so.0.13.0)
> ==16944==
> ==16944== Invalid read of size 1
> ==16944==    at 0x1D4A1620: adler32 (in /lib/libz.so.1.2.3)
> ==16944==  Address 0x20CE632C is 12 bytes after a block of size 2032
> alloc'd ==16944==    at 0x1B9092C5: malloc (vg_replace_malloc.c:130)
> ==16944==    by 0x1D3384DD: png_malloc_default
> (in /usr/lib/libpng12.so.0.13.0)
> ==16944==
> ==16944== Invalid read of size 1
> ==16944==    at 0x1D4A1628: adler32 (in /lib/libz.so.1.2.3)
> ==16944==  Address 0x20CE632D is 13 bytes after a block of size 2032
> alloc'd ==16944==    at 0x1B9092C5: malloc (vg_replace_malloc.c:130)
> ==16944==    by 0x1D3384DD: png_malloc_default
> (in /usr/lib/libpng12.so.0.13.0)
> ==16944==
> ==16944== Invalid read of size 1
> ==16944==    at 0x1D4A1630: adler32 (in /lib/libz.so.1.2.3)
> ==16944==  Address 0x20CE632E is 14 bytes after a block of size 2032
> alloc'd ==16944==    at 0x1B9092C5: malloc (vg_replace_malloc.c:130)
> ==16944==    by 0x1D3384DD: png_malloc_default
> (in /usr/lib/libpng12.so.0.13.0)
> ==16944==
> ==16944== Invalid read of size 1
> ==16944==    at 0x1D4A1638: adler32 (in /lib/libz.so.1.2.3)
> ==16944==  Address 0x20CE632F is 15 bytes after a block of size 2032
> alloc'd ==16944==    at 0x1B9092C5: malloc (vg_replace_malloc.c:130)
> ==16944==    by 0x1D3384DD: png_malloc_default
> (in /usr/lib/libpng12.so.0.13.0)
> ==16944== Stack overflow in thread 2: can't grow stack to 0x20CE7000
> KCrash: crashing... crashRecursionCounter = 2
> KCrash: Application Name = digikam path = <unknown> pid = 16944
> kio (KDirLister): -KDirLister
> kio (KDirLister): [virtual void KDirLister::stop()]
> kio (KDirListerCache): [void KDirListerCache::stop(KDirLister*)] lister:
> 0x20a9f310
> kio (KDirListerCache): [void KDirListerCache::forgetDirs(KDirLister*)]
> 0x20a9f310
> kio (KDirListerCache): [void KDirListerCache::forgetDirs(KDirLister*, const
> KURL&, bool)] 0x20a9f310 _url: file:///home/schnebeck/EOS/einTest
> kio (KDirListerCache): [void KDirListerCache::forgetDirs(KDirLister*, const
> KURL&, bool)] 0x20a9f310 item moved into cache:
> file:///home/schnebeck/EOS/einTest
> ICE default IO error handler doing an exit(), pid = 16944, errno = 9
> kio (KDirWatch): KDirWatchPrivate::removeEntry
> for '/home/schnebeck/EOS/einTest' sub_entry: (nil)
> kio (KDirWatch): removeEntry:
> unwatched /home/schnebeck/EOS/einTest /home/schnebeck/EOS/einTest
> kio (KDirListerCache): -KDirListerCache
> ==16944==
> ==16944== ERROR SUMMARY: 3342 errors from 27 contexts (suppressed: 7 from
> 1) ==16944== malloc/free: in use at exit: 63457601 bytes in 351298 blocks.
> ==16944== malloc/free: 2729509 allocs, 2378211 frees, 265248832 bytes
> allocated.
> ==16944== For counts of detected errors, rerun with: -v
> ==16944== searching for pointers to 351298 not-freed blocks.
> ==16944== checked 82747112 bytes.
> ==16944==
> ==16944==
> ==16944== 288 bytes in 2 blocks are possibly lost in loss record 1013 of
> 1866 ==16944==    at 0x1B909C70: calloc (vg_replace_malloc.c:175)
> ==16944==    by 0x1B8F45C8: allocate_dtv (in /lib/ld-2.4.so)
> ==16944==    by 0x1B8F468B: _dl_allocate_tls (in /lib/ld-2.4.so)
> ==16944==    by 0x1D4829FF: pthread_create@@GLIBC_2.1
> (in /lib/libpthread-2.4.so)
> ==16944==    by 0x1BCFDB87: (within /usr/lib/libsqlite3.so.0.8.6)
> ==16944==
> ==16944==
> ==16944== 312 (72 direct, 240 indirect) bytes in 2 blocks are definitely
> lost in loss record 1026 of 1866
> ==16944==    at 0x1B9092C5: malloc (vg_replace_malloc.c:130)
> ==16944==    by 0x1D73A639: (within /lib/libc-2.4.so)
> ==16944==    by 0x1D73AD36: __nss_database_lookup (in /lib/libc-2.4.so)
> ==16944==    by 0x1DBE7079: ???
> ==16944==    by 0x1DBE7D99: ???
> ==16944==    by 0x1D6F8C74: getpwuid_r (in /lib/libc-2.4.so)
> ==16944==    by 0x1D6F8669: getpwuid (in /lib/libc-2.4.so)
> ==16944==    by 0x1CB7B23C: (within /usr/qt/3/lib/libqt-mt.so.3.3.6)
> ==16944==    by 0x1CB7BB21: (within /usr/qt/3/lib/libqt-mt.so.3.3.6)
> ==16944==    by 0x1D355E27: _SmcProcessMessage (in /usr/lib/libSM.so.6.0.0)
> ==16944==
> ==16944==
> ==16944== 80 bytes in 2 blocks are definitely lost in loss record 1037 of
> 1866 ==16944==    at 0x1B9092C5: malloc (vg_replace_malloc.c:130)
> ==16944==    by 0x1B8EE33E: _dl_new_object (in /lib/ld-2.4.so)
> ==16944==    by 0x1B8EA357: _dl_map_object_from_fd (in /lib/ld-2.4.so)
> ==16944==    by 0x1B8EC150: _dl_map_object (in /lib/ld-2.4.so)
> ==16944==    by 0x1B8EFD45: openaux (in /lib/ld-2.4.so)
> ==16944==    by 0x1B8F1541: _dl_catch_error (in /lib/ld-2.4.so)
> ==16944==    by 0x1B8EFF3C: _dl_map_object_deps (in /lib/ld-2.4.so)
> ==16944==    by 0x1B8F543E: dl_open_worker (in /lib/ld-2.4.so)
> ==16944==    by 0x1B8F1541: _dl_catch_error (in /lib/ld-2.4.so)
> ==16944==    by 0x1B8F4F08: _dl_open (in /lib/ld-2.4.so)
> ==16944==    by 0x1D562E3C: (within /lib/libdl-2.4.so)
> ==16944==    by 0x1B8F1541: _dl_catch_error (in /lib/ld-2.4.so)
> ==16944==
> ==16944==
> ==16944== 188 (128 direct, 60 indirect) bytes in 1 blocks are definitely
> lost in loss record 1125 of 1866
> ==16944==    at 0x1B9092C5: malloc (vg_replace_malloc.c:130)
> ==16944==    by 0x1D179F8B: (within /usr/lib/libfontconfig.so.1.1.0)
> ==16944==
> ==16944==
> ==16944== 216 bytes in 1 blocks are definitely lost in loss record 1189 of
> 1866
> ==16944==    at 0x1B9092C5: malloc (vg_replace_malloc.c:130)
> ==16944==    by 0x1D3ED209: _XimOpenIM (in /usr/lib/libX11.so.6.2.0)
> ==16944==
> ==16944==
> ==16944== 584 (52 direct, 532 indirect) bytes in 1 blocks are definitely
> lost in loss record 1439 of 1866
> ==16944==    at 0x1B909441: operator new(unsigned)
> (vg_replace_malloc.c:132) ==16944==    by 0x1C290741:
> KServiceTypeFactory::createEntry(int)
> (kservicetypefactory.cpp:270)
> ==16944==
> ==16944==
> ==16944== 19556 (6912 direct, 12644 indirect) bytes in 18 blocks are
> definitely lost in loss record 1808 of 1866
> ==16944==    at 0x1B909D6A: realloc (vg_replace_malloc.c:196)
> ==16944==    by 0x1D179EA3: (within /usr/lib/libfontconfig.so.1.1.0)
> ==16944==
> ==16944==
> ==16944== 12612 bytes in 3 blocks are definitely lost in loss record 1814
> of 1866
> ==16944==    at 0x1B909D6A: realloc (vg_replace_malloc.c:196)
> ==16944==    by 0x1D197C42: (within /usr/lib/libfreetype.so.6.3.8)
> ==16944==
> ==16944==
> ==16944== 12643 bytes in 4 blocks are definitely lost in loss record 1815
> of 1866
> ==16944==    at 0x1B9092C5: malloc (vg_replace_malloc.c:130)
> ==16944==    by 0x1D197BBA: (within /usr/lib/libfreetype.so.6.3.8)
> ==16944==
> ==16944== LEAK SUMMARY:
> ==16944==    definitely lost: 32715 bytes in 32 blocks.
> ==16944==    indirectly lost: 13476 bytes in 675 blocks.
> ==16944==      possibly lost: 288 bytes in 2 blocks.
> ==16944==    still reachable: 63411122 bytes in 350589 blocks.
> ==16944==         suppressed: 0 bytes in 0 blocks.
> ==16944== Reachable blocks (those to which a pointer was found) are not
> shown. ==16944== To see them, rerun with: --show-reachable=yes
>
> Can someone second?
>
>  digikam --version
> Qt: 3.3.6
> KDE: 3.5.5
> digiKam: 0.9.0-rc2
>
> exiv2-config --version
> 0.12
>
> Bye
>
>   Thorsten
>
> _______________________________________________
> 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

On Friday, December 15, 2006 07:48:03 AM Gilles Caulier wrote:

> Not reproductible here. I use every day PNG file format to save my photo.
> No crash here...
>
> Your report sound like a problem with your HDD free space/ or something is
> broken in your KDE installation ?
>
> > kio (KIOJob): stat file:///home/schnebeck/EOS/einTest/IMG_4876.png
> > kio (KIOJob): error 11 /home/schnebeck/EOS/einTest/IMG_4876.png
>
> Why KIOJob return an error just before than digiKam start the PNG stuff ?
>
> Gilles

Hi Gilles,

no, I loaded the same image into KolourPaint that nearly have the same "save
as"-dialog and there it no problem to save to png. As a non-KDE program GIMP
has also no problems.
There is 12 GB left on partition, should be enough ;-)
Although no room on a device should never crash an already running
application.

So I tried to recompile some of the involved packages to get a BT and here it
is:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1250223200 (LWP 12511)]
0xb633a819 in adler32 () from /lib/libz.so.1
(gdb) bt
#0  0xb633a819 in adler32 () from /lib/libz.so.1
#1  0xb633d3c3 in deflateCopy () from /lib/libz.so.1
#2  0xb633e4fc in deflateParams () from /lib/libz.so.1
#3  0xb633d6c7 in deflate () from /lib/libz.so.1
#4  0xb64ab391 in png_save_uint_16 () from /usr/lib/libpng12.so.0
#5  0xb64ac498 in png_write_chunk_start () from /usr/lib/libpng12.so.0
#6  0xb64b2f5a in png_write_info_before_PLTE () from /usr/lib/libpng12.so.0
#7  0xb64b2fbc in png_write_info () from /usr/lib/libpng12.so.0
#8  0xb7ea86d3 in Digikam::PNGLoader::save (this=0xb57b136c,
filePath=@0x8519bc8,
    observer=0x8519bc0) at pngloader.cpp:691
#9  0xb7ebea99 in Digikam::DImg::save (this=0x8519bc4, filePath=@0x8519bc8,
format=@0x8519bcc,
    observer=0x8519bc0) at dimg.cpp:397
#10 0xb7e3c036 in Digikam::SavingTask::execute (this=0x8519bb8) at
loadsavetask.cpp:395
#11 0xb7e399fd in Digikam::LoadSaveThread::run (this=0x84cd550) at
loadsavethread.cpp:172
#12 0xb6946853 in QThreadInstance::start () from /usr/qt/3/lib/libqt-mt.so.3
#13 0xb6461294 in start_thread () from /lib/libpthread.so.0
#14 0xb620597e in clone () from /lib/libc.so.6  

(This is another computer, here is libpng12. On the other system it was
libpng13)

Strange that a save command enters a loader code. Maybe that libpng does not
want to write a illegal png format to disk?
To make it clear: there is no problem to write to jpg, tiff, bmp etc. When
using jpeg2000 I get an error message but png results in a longer freeze and
then a crash.

But its also strange that no-one else seems to trigger such a generic problem.

Bye

  Thorsten

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

[Gilles Caulier-2]

On Friday 15 December 2006 13:36, Thorsten Schnebeck wrote:

> On Friday, December 15, 2006 07:48:03 AM Gilles Caulier wrote:
> > Not reproductible here. I use every day PNG file format to save my photo.
> > No crash here...
> >
> > Your report sound like a problem with your HDD free space/ or something
> > is broken in your KDE installation ?
> >
> > > kio (KIOJob): stat file:///home/schnebeck/EOS/einTest/IMG_4876.png
> > > kio (KIOJob): error 11 /home/schnebeck/EOS/einTest/IMG_4876.png
> >
> > Why KIOJob return an error just before than digiKam start the PNG stuff ?
> >
> > Gilles
>
> Hi Gilles,
>
> no, I loaded the same image into KolourPaint that nearly have the same
> "save as"-dialog and there it no problem to save to png. As a non-KDE
> program GIMP has also no problems.
> There is 12 GB left on partition, should be enough ;-)
> Although no room on a device should never crash an already running
> application.
>
> So I tried to recompile some of the involved packages to get a BT and here
> it is:
>
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread -1250223200 (LWP 12511)]
> 0xb633a819 in adler32 () from /lib/libz.so.1
> (gdb) bt
> #0  0xb633a819 in adler32 () from /lib/libz.so.1
> #1  0xb633d3c3 in deflateCopy () from /lib/libz.so.1
> #2  0xb633e4fc in deflateParams () from /lib/libz.so.1
> #3  0xb633d6c7 in deflate () from /lib/libz.so.1
> #4  0xb64ab391 in png_save_uint_16 () from /usr/lib/libpng12.so.0
> #5  0xb64ac498 in png_write_chunk_start () from /usr/lib/libpng12.so.0
> #6  0xb64b2f5a in png_write_info_before_PLTE () from /usr/lib/libpng12.so.0
> #7  0xb64b2fbc in png_write_info () from /usr/lib/libpng12.so.0
> #8  0xb7ea86d3 in Digikam::PNGLoader::save (this=0xb57b136c,
> filePath=@0x8519bc8,
>     observer=0x8519bc0) at pngloader.cpp:691
> #9  0xb7ebea99 in Digikam::DImg::save (this=0x8519bc4, filePath=@0x8519bc8,
> format=@0x8519bcc,
>     observer=0x8519bc0) at dimg.cpp:397
> #10 0xb7e3c036 in Digikam::SavingTask::execute (this=0x8519bb8) at
> loadsavetask.cpp:395
> #11 0xb7e399fd in Digikam::LoadSaveThread::run (this=0x84cd550) at
> loadsavethread.cpp:172
> #12 0xb6946853 in QThreadInstance::start () from
> /usr/qt/3/lib/libqt-mt.so.3 #13 0xb6461294 in start_thread () from
> /lib/libpthread.so.0
> #14 0xb620597e in clone () from /lib/libc.so.6
>
> (This is another computer, here is libpng12. On the other system it was
> libpng13)
>
> Strange that a save command enters a loader code. Maybe that libpng does
> not want to write a illegal png format to disk?
> To make it clear: there is no problem to write to jpg, tiff, bmp etc. When
> using jpeg2000 I get an error message but png results in a longer freeze
> and then a crash.
>
> But its also strange that no-one else seems to trigger such a generic
> problem.
>
> Bye
>
>   Thorsten

Look like the BT sound a crash in libpng using libz (used to compress image
data). I suspect a problem with a shared library in your system. Check it.

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

On Friday, December 15, 2006 03:51:59 PM Gilles Caulier wrote:

> On Friday 15 December 2006 13:36, Thorsten Schnebeck wrote:
> > On Friday, December 15, 2006 07:48:03 AM Gilles Caulier wrote:
> > > Not reproductible here. I use every day PNG file format to save my
> > > photo. No crash here...
> > >
> > > Your report sound like a problem with your HDD free space/ or something
> > > is broken in your KDE installation ?
> > >
> > > > kio (KIOJob): stat file:///home/schnebeck/EOS/einTest/IMG_4876.png
> > > > kio (KIOJob): error 11 /home/schnebeck/EOS/einTest/IMG_4876.png
> > >
> > > Why KIOJob return an error just before than digiKam start the PNG stuff
> > > ?
> > >
> > > Gilles
> >
> > Hi Gilles,
> >
> > no, I loaded the same image into KolourPaint that nearly have the same
> > "save as"-dialog and there it no problem to save to png. As a non-KDE
> > program GIMP has also no problems.
> > There is 12 GB left on partition, should be enough ;-)
> > Although no room on a device should never crash an already running
> > application.
> >
> > So I tried to recompile some of the involved packages to get a BT and
> > here it is:
> >
> > Program received signal SIGSEGV, Segmentation fault.
> > [Switching to Thread -1250223200 (LWP 12511)]
> > 0xb633a819 in adler32 () from /lib/libz.so.1
> > (gdb) bt
> > #0  0xb633a819 in adler32 () from /lib/libz.so.1
> > #1  0xb633d3c3 in deflateCopy () from /lib/libz.so.1
> > #2  0xb633e4fc in deflateParams () from /lib/libz.so.1
> > #3  0xb633d6c7 in deflate () from /lib/libz.so.1
> > #4  0xb64ab391 in png_save_uint_16 () from /usr/lib/libpng12.so.0
> > #5  0xb64ac498 in png_write_chunk_start () from /usr/lib/libpng12.so.0
> > #6  0xb64b2f5a in png_write_info_before_PLTE () from
> > /usr/lib/libpng12.so.0 #7  0xb64b2fbc in png_write_info () from
> > /usr/lib/libpng12.so.0
> > #8  0xb7ea86d3 in Digikam::PNGLoader::save (this=0xb57b136c,
> > filePath=@0x8519bc8,
> >     observer=0x8519bc0) at pngloader.cpp:691
> > #9  0xb7ebea99 in Digikam::DImg::save (this=0x8519bc4,
> > filePath=@0x8519bc8, format=@0x8519bcc,
> >     observer=0x8519bc0) at dimg.cpp:397
> > #10 0xb7e3c036 in Digikam::SavingTask::execute (this=0x8519bb8) at
> > loadsavetask.cpp:395
> > #11 0xb7e399fd in Digikam::LoadSaveThread::run (this=0x84cd550) at
> > loadsavethread.cpp:172
> > #12 0xb6946853 in QThreadInstance::start () from
> > /usr/qt/3/lib/libqt-mt.so.3 #13 0xb6461294 in start_thread () from
> > /lib/libpthread.so.0
> > #14 0xb620597e in clone () from /lib/libc.so.6
> >
> > (This is another computer, here is libpng12. On the other system it was
> > libpng13)
> >
> > Strange that a save command enters a loader code. Maybe that libpng does
> > not want to write a illegal png format to disk?
> > To make it clear: there is no problem to write to jpg, tiff, bmp etc.
> > When using jpeg2000 I get an error message but png results in a longer
> > freeze and then a crash.
> >
> > But its also strange that no-one else seems to trigger such a generic
> > problem.
> >
> > Bye
> >
> >   Thorsten
>
> Look like the BT sound a crash in libpng using libz (used to compress image
> data). I suspect a problem with a shared library in your system. Check it.

As the problem still exists - and still in digiKam only I collect new infos.

When I interrupt the session before digikam crashs I have this threading info:

Program received signal SIGINT, Interrupt.
[Switching to Thread -1245165904 (LWP 25514)]
0xffffe410 in __kernel_vsyscall ()
(gdb) info threads
  4 Thread -1255158880 (LWP 25528)  0xb60d741d in png_save_uint_16 ()
from /usr/lib/libpng12.so.0
  3 Thread -1255158880 (LWP 25528)  0xb60d741d in png_save_uint_16 ()
from /usr/lib/libpng12.so.0
* 1 Thread -1245165904 (LWP 25514)  0xffffe410 in __kernel_vsyscall ()

For what are the two threads necessary? Is libpng in this case threadsafe?

Full info:

(gdb) thread 4
[Switching to thread 4 (Thread -1255158880 (LWP 25528))]#0  0xb60d741d in
png_save_uint_16 () from /usr/lib/libpng12.so.0
(gdb) bt
#0  0xb60d741d in png_save_uint_16 () from /usr/lib/libpng12.so.0
#1  0xb60d8498 in png_write_chunk_start () from /usr/lib/libpng12.so.0
#2  0xb60def5a in png_write_info_before_PLTE () from /usr/lib/libpng12.so.0
#3  0xb60defbc in png_write_info () from /usr/lib/libpng12.so.0
#4  0xb7e82623 in Digikam::PNGLoader::save (this=0xb52fc36c,
filePath=@0x85a0c50, observer=0x85a0c48) at pngloader.cpp:691
#5  0xb7e988b9 in Digikam::DImg::save (this=0x85a0c4c, filePath=@0x85a0c50,
format=@0x85a0c54, observer=0x85a0c48) at dimg.cpp:412
#6  0xb7e136c6 in Digikam::SavingTask::execute (this=0x85a0c40) at
loadsavetask.cpp:395
#7  0xb7e1108d in Digikam::LoadSaveThread::run (this=0x854aa30) at
loadsavethread.cpp:172
#8  0xb6572853 in QThreadInstance::start () from /usr/qt/3/lib/libqt-mt.so.3
#9  0xb608e294 in start_thread () from /lib/libpthread.so.0
#10 0xb5d5097e in clone () from /lib/libc.so.6


(gdb) thread 3
[Switching to thread 3 (Thread -1255158880 (LWP 25528))]#0  0xb60d741d in
png_save_uint_16 () from /usr/lib/libpng12.so.0
(gdb) bt
#0  0xb60d741d in png_save_uint_16 () from /usr/lib/libpng12.so.0
#1  0xb60d8498 in png_write_chunk_start () from /usr/lib/libpng12.so.0
#2  0xb60def5a in png_write_info_before_PLTE () from /usr/lib/libpng12.so.0
#3  0xb60defbc in png_write_info () from /usr/lib/libpng12.so.0
#4  0xb7e82623 in Digikam::PNGLoader::save (this=0xb52fc36c,
filePath=@0x85a0c50, observer=0x85a0c48) at pngloader.cpp:691
#5  0xb7e988b9 in Digikam::DImg::save (this=0x85a0c4c, filePath=@0x85a0c50,
format=@0x85a0c54, observer=0x85a0c48) at dimg.cpp:412
#6  0xb7e136c6 in Digikam::SavingTask::execute (this=0x85a0c40) at
loadsavetask.cpp:395
#7  0xb7e1108d in Digikam::LoadSaveThread::run (this=0x854aa30) at
loadsavethread.cpp:172
#8  0xb6572853 in QThreadInstance::start () from /usr/qt/3/lib/libqt-mt.so.3
#9  0xb608e294 in start_thread () from /lib/libpthread.so.0
#10 0xb5d5097e in clone () from /lib/libc.so.6


(gdb) thread 1
[Switching to thread 1 (Thread -1245165904 (LWP 25514))]#0  0xb65d9b6f in
QObject::receivers () from /usr/qt/3/lib/libqt-mt.so.3
(gdb) bt
#0  0xb65d9b6f in QObject::receivers () from /usr/qt/3/lib/libqt-mt.so.3
#1  0xb6e2fd2e in KToolBar::highlighted (this=0x86137d0, t0=-26, t1=true) at
ktoolbar.moc:313
#2  0xb6e30057 in KToolBar::qt_emit (this=0x86137d0, _id=10, _o=0xbf80f6a0) at
ktoolbar.moc:380
#3  0xb65d8e6b in QObject::activate_signal () from /usr/qt/3/lib/libqt-mt.so.3
#4  0xb6efbca4 in KToolBarButton::highlighted (this=0x862eb58, t0=-26,
t1=true) at ktoolbarbutton.moc:192
#5  0xb6efc237 in KToolBarButton::enterEvent (this=0x862eb58) at
ktoolbarbutton.cpp:403
#6  0xb6611ca9 in QWidget::event () from /usr/qt/3/lib/libqt-mt.so.3
#7  0xb6efe54e in KToolBarButton::event (this=0xbf80f9f4, e=0x862eb58) at
ktoolbarbutton.cpp:651
#8  0xb65799f7 in QApplication::internalNotify ()
from /usr/qt/3/lib/libqt-mt.so.3
#9  0xb657a5e9 in QApplication::notify () from /usr/qt/3/lib/libqt-mt.so.3
#10 0xb6baed1b in KApplication::notify (this=0xbf80fd84, receiver=0x862eb58,
event=0xbf80f9f4) at kapplication.cpp:550
#11 0xb657baed in qt_dispatchEnterLeave () from /usr/qt/3/lib/libqt-mt.so.3
#12 0xb6519824 in QApplication::x11ProcessEvent ()
from /usr/qt/3/lib/libqt-mt.so.3
#13 0xb65295e1 in QEventLoop::processEvents ()
from /usr/qt/3/lib/libqt-mt.so.3
#14 0xb6590651 in QEventLoop::enterLoop () from /usr/qt/3/lib/libqt-mt.so.3
#15 0xb65904d6 in QEventLoop::exec () from /usr/qt/3/lib/libqt-mt.so.3
#16 0xb657948f in QApplication::exec () from /usr/qt/3/lib/libqt-mt.so.3
#17 0x0804a987 in main (argc=1, argv=0xbf80ff94) at main.cpp:269

Bye

  Thorsten


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

[Marcel Wiesweg]

> As the problem still exists - and still in digiKam only I collect new
> infos.
>
> When I interrupt the session before digikam crashs I have this threading
> info:
>
> Program received signal SIGINT, Interrupt.
> [Switching to Thread -1245165904 (LWP 25514)]
> 0xffffe410 in __kernel_vsyscall ()
> (gdb) info threads
>   4 Thread -1255158880 (LWP 25528)  0xb60d741d in png_save_uint_16 ()
>
> >from /usr/lib/libpng12.so.0
>
>   3 Thread -1255158880 (LWP 25528)  0xb60d741d in png_save_uint_16 ()
>
> >from /usr/lib/libpng12.so.0
>
> * 1 Thread -1245165904 (LWP 25514)  0xffffe410 in __kernel_vsyscall ()
>
> For what are the two threads necessary? Is libpng in this case threadsafe?

libpng should be reentrant, but the real question is, why are two threads
doing (the same?) save operation? This is very strange, the bt's from thread
3 and 4 are indentical, the thread ids are identical. Something broken in
GDB?

To verify with debug messages, you can outcomment line 24 at the top of
pngloader.cpp:
#define ENABLE_DEBUG_MESSAGES

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

> To verify with debug messages, you can outcomment line 24 at the top of
> pngloader.cpp:
> #define ENABLE_DEBUG_MESSAGES


Oh, that was a good hint. With the additional informations I could verify that
there was a libpng version-mishmash on my computer alltough I use only
standard Gentoo update. When installing a new libpng manually I discovered
that digikam still used the old version. So I removed every libpng file
(libpng-config, pkg.pc) and installed latest libpng. Now digikam used the
correct version and problem was gone. AS I have more computers with this
setup I have to test, if I have there the problem, too.

Bye

  Thorsten

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