Digikam Crash from Assert in libexiv2

[Todd Goodman]

Hi,

I'm getting a digikam crash everytime I try to start up digikam (and it
scans my files.)

It's in libexiv2 (SVN from today, May 21, 2010.)

I've tried looking some but would appreciate any pointers.  It looks
like the write fails but I'm not quite sure what's being written (TIFF
metadata to where?)

I have lots of diskspace both on the image and SQLite database
filesystem (the same local disk.)

I added debug and see that the group name is CANON and sv is four more
bytes than what was returned as having been written (I don't have that
debug in this trace since I just updated exiv2.)

I suspect it's the same file each time but am not sure how to get the
filename from inside the exiv2 code.

The last few lines of the stdout/stderr and stack backtrace are below.

If anyone has any suggestions for debugging this I'd appreciate it.

Thanks,

Todd Goodman

Error: Directory Unknown: Next pointer is out of bounds; ignored.
Error: Directory Canon: Next pointer is out of bounds; ignored.
Error: Directory Canon: Next pointer is out of bounds; ignored.
Error: Directory Canon: Next pointer is out of bounds; ignored.
Warning: Directory Canon, entry 0x0001 has unknown Exif (TIFF) type 0;
setting type size 1.
Warning: Directory Canon, entry 0x3130 has unknown Exif (TIFF) type
12346; setting type size 1.
Error: Directory Canon, entry 0x3130 has invalid size 1850671152*1;
skipping entry.
Warning: Directory Canon, entry 0x5265 has unknown Exif (TIFF) type
24933; setting type size 1.
Error: Directory Canon, entry 0x5265 has invalid size 1634026604*1;
skipping entry.
digikam: /root/digikam-svn/exiv2/src/tiffcomposite.cpp:1332: virtual
uint32_t
Exiv2::Internal::TiffDirectory::doWrite(Exiv2::Internal::IoWrapper&,
Exiv2::ByteOrder, int32_t, uint32_t, uint32_t, uint32_t&): Assertion `sv
== d' failed.
KCrash: Application 'digikam' crashing...
QSocketNotifier: Invalid socket 8 and type 'Read', disabling...
sock_file=/root/.kde-svn/socket-mail-proxy/kdeinit4_localhost_13
digikam: Fatal IO error: client killed
Warning: connect() failed: : No such file or directory
KCrash cannot reach kdeinit, launching directly.

Application: digiKam (digikam), signal: Aborted
[Current thread is 0 (LWP 30498)]

Thread 2 (Thread 0xb27adb90 (LWP 30500)):
[KCrash Handler]
#5  0xffffe424 in __kernel_vsyscall ()
#6  0xb5449c41 in raise () from /lib/libc.so.6
#7  0xb544b428 in abort () from /lib/libc.so.6
#8  0xb5443005 in __assert_fail () from /lib/libc.so.6
#9  0xb508507d in Exiv2::Internal::TiffDirectory::doWrite () from
/usr/local/lib
/libexiv2.so.6
#10 0xb507f3d8 in Exiv2::Internal::TiffComponent::write () from
/usr/local/lib/l
ibexiv2.so.6
#11 0xb5082b9c in Exiv2::Internal::TiffIfdMakernote::doWrite () from
/usr/local/
lib/libexiv2.so.6
#12 0xb507f3d8 in Exiv2::Internal::TiffComponent::write () from
/usr/local/lib/l
ibexiv2.so.6
#13 0xb508075f in Exiv2::Internal::TiffMnEntry::doWrite () from
/usr/local/lib/l
ibexiv2.so.6
#14 0xb507f3d8 in Exiv2::Internal::TiffComponent::write () from
/usr/local/lib/l
ibexiv2.so.6
#15 0xb5085048 in Exiv2::Internal::TiffDirectory::doWrite () from
/usr/local/lib
/libexiv2.so.6
#16 0xb507f3d8 in Exiv2::Internal::TiffComponent::write () from
/usr/local/lib/l
ibexiv2.so.6
#17 0xb507fddb in Exiv2::Internal::TiffSubIfd::doWriteData () from
/usr/local/li
b/libexiv2.so.6
#18 0xb507f415 in Exiv2::Internal::TiffComponent::writeData () from
/usr/local/l
ib/libexiv2.so.6
#19 0xb507fae1 in Exiv2::Internal::TiffDirectory::doWriteData () from
/usr/local
/lib/libexiv2.so.6
#20 0xb507f415 in Exiv2::Internal::TiffComponent::writeData () from
/usr/local/l
ib/libexiv2.so.6
#21 0xb5085185 in Exiv2::Internal::TiffDirectory::doWrite () from
/usr/local/lib
/libexiv2.so.6
#22 0xb507f3d8 in Exiv2::Internal::TiffComponent::write () from
/usr/local/lib/l
ibexiv2.so.6
#23 0xb508fdc6 in Exiv2::Internal::TiffParserWorker::encode () from
/usr/local/l
ib/libexiv2.so.6
#24 0xb500a68f in Exiv2::ExifParser::encode () from
/usr/local/lib/libexiv2.so.6
#25 0xb7772ca5 in Exiv2::ExifParser::encode (blob=@0xb27aac84,
byteOrder=Exiv2::
bigEndian, exifData=@0xa9cc8280) at
/usr/local/include/exiv2/exif.hpp:626
#26 0xb776ed08 in KExiv2Iface::KExiv2::getExifEncoded (this=0xb27acd6c,
addExifH
eader=false) at /root/digikam-svn/libkexiv2/libkexiv2/kexiv2exif.cpp:92
#27 0xb6fba52c in Digikam::DImgLoader::uniqueHash (filePath=@0xb27acdec,
img=@0x
b27acf8c, loadMetadata=false) at
/root/digikam-svn/graphics/digikam/libs/dimg/lo
aders/dimgloader.cpp:221
#28 0xb6fa46c0 in Digikam::DImg::getUniqueHash (this=0xb27acf8c) at
/root/digika
m-svn/graphics/digikam/libs/dimg/dimg.cpp:2134
#29 0xb6de10e6 in Digikam::ImageScanner::uniqueHash (this=0xb27acf7c) at
/root/d
igikam-svn/graphics/digikam/libs/database/imagescanner.cpp:609
@
#30 0xb6de3756 in Digikam::ImageScanner::prepareImage (this=0xb27acf7c)
at /root
/digikam-svn/graphics/digikam/libs/database/imagescanner.cpp:195
#31 0xb6de393c in Digikam::ImageScanner::addImage (this=0xb27acf7c,
albumId=0) a
t /root/digikam-svn/graphics/digikam/libs/database/imagescanner.cpp:200
#32 0xb6de410d in Digikam::ImageScanner::newFile (this=0xb27acf7c,
albumId=0) at
 /root/digikam-svn/graphics/digikam/libs/database/imagescanner.cpp:100
#33 0xb6d93310 in Digikam::CollectionScanner::scanNewFile
(this=0xb27ad2f8, info
=@0x9bbeaf0c, albumId=0) at
/root/digikam-svn/graphics/digikam/libs/database/col
lectionscanner.cpp:758
#34 0xb6d960df in Digikam::CollectionScanner::scanAlbum
(this=0xb27ad2f8, locati
on=@0x86079f8, album=@0xb27ad13c) at
/root/digikam-svn/graphics/digikam/libs/dat
abase/collectionscanner.cpp:667
#35 0xb6d96357 in Digikam::CollectionScanner::scanAlbum
(this=0xb27ad2f8, locati
on=@0x86079f8, album=@0xb27ad218) at
/root/digikam-svn/graphics/digikam/libs/dat
abase/collectionscanner.cpp:685
#36 0xb6d9685c in Digikam::CollectionScanner::scanAlbumRoot
(this=0xb27ad2f8, lo
cation=@0x86079f8) at
/root/digikam-svn/graphics/digikam/libs/database/collectio
nscanner.cpp:479
#37 0xb6d970de in Digikam::CollectionScanner::completeScan
(this=0xb27ad2f8) at
/root/digikam-svn/graphics/digikam/libs/database/collectionscanner.cpp:250
#38 0x08335a0f in Digikam::ScanController::run (this=0x8588fb8) at
/root/digikam
-svn/graphics/digikam/digikam/scancontroller.cpp:541
#39 0xb56dbfc1 in ?? () from /usr/lib/qt4/libQtCore.so.4
#40 0x08588fb8 in ?? ()
#41 0x00000000 in ?? ()

Thread 1 (Thread 0xb3bb2700 (LWP 30498)):
#0  0xffffe424 in __kernel_vsyscall ()
#1  0xb56828d5 in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib/libpthread.so.0
#2  0xb56dc658 in QWaitCondition::wait () from
/usr/lib/qt4/libQtCore.so.4
#3  0xb56dc066 in QThread::wait () from /usr/lib/qt4/libQtCore.so.4
#4  0x083347ae in Digikam::ScanController::shutDown (this=0x8588fb8) at
/root/di
gikam-svn/graphics/digikam/digikam/scancontroller.cpp:290
#5  0x0833490f in ~ScanController (this=0x8588fb8) at
/root/digikam-svn/graphics
/digikam/digikam/scancontroller.cpp:273
#6  0x083377b3 in ~ScanControllerCreator (this=0x8588fb8) at
/root/digikam-svn/g
raphics/digikam/digikam/scancontroller.cpp:221
#7  0x08334a41 in destroy () at
/root/digikam-svn/graphics/digikam/digikam/scanc
ontroller.cpp:222
#8  0x082804f5 in ~KCleanUpGlobalStatic (this=0x84eee5c) at
/usr/include/kglobal
.h:62
#9  0x08332060 in __tcf_0 () at
/root/digikam-svn/graphics/digikam/digikam/scanc
ontroller.cpp:222
#10 0xb544cbbc in exit () from /lib/libc.so.6
#11 0xb5c919cb in ?? () from /usr/lib/qt4/libQtGui.so.4
#12 0x00000001 in ?? ()
#13 0x08526bc8 in ?? ()
#14 0x0008a4e0 in ?? ()
#15 0xb5c91999 in ?? () from /usr/lib/qt4/libQtGui.so.4
#16 0xb67b6ff4 in ?? () from /usr/lib/libkdeui.so.5
#17 0xbfb61258 in ?? ()
#18 0xb65faaea in KApplication::xioErrhandler (this=0x3a0070, dpy=0x11)
at /var/
tmp/portage/kde-base/kdelibs-4.3.5/work/kdelibs-4.3.5/kdeui/kernel/kapplication.
cpp:408
Backtrace stopped: previous frame inner to this frame (corrupt stack?)


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

[Marcel Wiesweg]

> I'm getting a digikam crash everytime I try to start up digikam (and it
> scans my files.)
>
> It's in libexiv2 (SVN from today, May 21, 2010.)
>
> I've tried looking some but would appreciate any pointers.  It looks
> like the write fails but I'm not quite sure what's being written (TIFF
> metadata to where?)
>
> I have lots of diskspace both on the image and SQLite database
> filesystem (the same local disk.)
>
> I added debug and see that the group name is CANON and sv is four more
> bytes than what was returned as having been written (I don't have that
> debug in this trace since I just updated exiv2.)
>
> I suspect it's the same file each time but am not sure how to get the
> filename from inside the exiv2 code.
>
> The last few lines of the stdout/stderr and stack backtrace are below.
>
> If anyone has any suggestions for debugging this I'd appreciate it.

The best thing to do is isolating the file causing the crash.
Is any filename printed on the console, before the debug output you included
in your mail?
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

Andreas, do you see this message in devel ML. Please respond in ML
directly. Thanks in advance

Gilles

2010/5/21 Todd Goodman <[hidden email]>:

> Hi,
>
> I'm getting a digikam crash everytime I try to start up digikam (and it
> scans my files.)
>
> It's in libexiv2 (SVN from today, May 21, 2010.)
>
> I've tried looking some but would appreciate any pointers.  It looks
> like the write fails but I'm not quite sure what's being written (TIFF
> metadata to where?)
>
> I have lots of diskspace both on the image and SQLite database
> filesystem (the same local disk.)
>
> I added debug and see that the group name is CANON and sv is four more
> bytes than what was returned as having been written (I don't have that
> debug in this trace since I just updated exiv2.)
>
> I suspect it's the same file each time but am not sure how to get the
> filename from inside the exiv2 code.
>
> The last few lines of the stdout/stderr and stack backtrace are below.
>
> If anyone has any suggestions for debugging this I'd appreciate it.
>
> Thanks,
>
> Todd Goodman
>
> Error: Directory Unknown: Next pointer is out of bounds; ignored.
> Error: Directory Canon: Next pointer is out of bounds; ignored.
> Error: Directory Canon: Next pointer is out of bounds; ignored.
> Error: Directory Canon: Next pointer is out of bounds; ignored.
> Warning: Directory Canon, entry 0x0001 has unknown Exif (TIFF) type 0;
> setting type size 1.
> Warning: Directory Canon, entry 0x3130 has unknown Exif (TIFF) type
> 12346; setting type size 1.
> Error: Directory Canon, entry 0x3130 has invalid size 1850671152*1;
> skipping entry.
> Warning: Directory Canon, entry 0x5265 has unknown Exif (TIFF) type
> 24933; setting type size 1.
> Error: Directory Canon, entry 0x5265 has invalid size 1634026604*1;
> skipping entry.
> digikam: /root/digikam-svn/exiv2/src/tiffcomposite.cpp:1332: virtual
> uint32_t
> Exiv2::Internal::TiffDirectory::doWrite(Exiv2::Internal::IoWrapper&,
> Exiv2::ByteOrder, int32_t, uint32_t, uint32_t, uint32_t&): Assertion `sv
> == d' failed.
> KCrash: Application 'digikam' crashing...
> QSocketNotifier: Invalid socket 8 and type 'Read', disabling...
> sock_file=/root/.kde-svn/socket-mail-proxy/kdeinit4_localhost_13
> digikam: Fatal IO error: client killed
> Warning: connect() failed: : No such file or directory
> KCrash cannot reach kdeinit, launching directly.
>
> Application: digiKam (digikam), signal: Aborted
> [Current thread is 0 (LWP 30498)]
>
> Thread 2 (Thread 0xb27adb90 (LWP 30500)):
> [KCrash Handler]
> #5  0xffffe424 in __kernel_vsyscall ()
> #6  0xb5449c41 in raise () from /lib/libc.so.6
> #7  0xb544b428 in abort () from /lib/libc.so.6
> #8  0xb5443005 in __assert_fail () from /lib/libc.so.6
> #9  0xb508507d in Exiv2::Internal::TiffDirectory::doWrite () from
> /usr/local/lib
> /libexiv2.so.6
> #10 0xb507f3d8 in Exiv2::Internal::TiffComponent::write () from
> /usr/local/lib/l
> ibexiv2.so.6
> #11 0xb5082b9c in Exiv2::Internal::TiffIfdMakernote::doWrite () from
> /usr/local/
> lib/libexiv2.so.6
> #12 0xb507f3d8 in Exiv2::Internal::TiffComponent::write () from
> /usr/local/lib/l
> ibexiv2.so.6
> #13 0xb508075f in Exiv2::Internal::TiffMnEntry::doWrite () from
> /usr/local/lib/l
> ibexiv2.so.6
> #14 0xb507f3d8 in Exiv2::Internal::TiffComponent::write () from
> /usr/local/lib/l
> ibexiv2.so.6
> #15 0xb5085048 in Exiv2::Internal::TiffDirectory::doWrite () from
> /usr/local/lib
> /libexiv2.so.6
> #16 0xb507f3d8 in Exiv2::Internal::TiffComponent::write () from
> /usr/local/lib/l
> ibexiv2.so.6
> #17 0xb507fddb in Exiv2::Internal::TiffSubIfd::doWriteData () from
> /usr/local/li
> b/libexiv2.so.6
> #18 0xb507f415 in Exiv2::Internal::TiffComponent::writeData () from
> /usr/local/l
> ib/libexiv2.so.6
> #19 0xb507fae1 in Exiv2::Internal::TiffDirectory::doWriteData () from
> /usr/local
> /lib/libexiv2.so.6
> #20 0xb507f415 in Exiv2::Internal::TiffComponent::writeData () from
> /usr/local/l
> ib/libexiv2.so.6
> #21 0xb5085185 in Exiv2::Internal::TiffDirectory::doWrite () from
> /usr/local/lib
> /libexiv2.so.6
> #22 0xb507f3d8 in Exiv2::Internal::TiffComponent::write () from
> /usr/local/lib/l
> ibexiv2.so.6
> #23 0xb508fdc6 in Exiv2::Internal::TiffParserWorker::encode () from
> /usr/local/l
> ib/libexiv2.so.6
> #24 0xb500a68f in Exiv2::ExifParser::encode () from
> /usr/local/lib/libexiv2.so.6
> #25 0xb7772ca5 in Exiv2::ExifParser::encode (blob=@0xb27aac84,
> byteOrder=Exiv2::
> bigEndian, exifData=@0xa9cc8280) at
> /usr/local/include/exiv2/exif.hpp:626
> #26 0xb776ed08 in KExiv2Iface::KExiv2::getExifEncoded (this=0xb27acd6c,
> addExifH
> eader=false) at /root/digikam-svn/libkexiv2/libkexiv2/kexiv2exif.cpp:92
> #27 0xb6fba52c in Digikam::DImgLoader::uniqueHash (filePath=@0xb27acdec,
> img=@0x
> b27acf8c, loadMetadata=false) at
> /root/digikam-svn/graphics/digikam/libs/dimg/lo
> aders/dimgloader.cpp:221
> #28 0xb6fa46c0 in Digikam::DImg::getUniqueHash (this=0xb27acf8c) at
> /root/digika
> m-svn/graphics/digikam/libs/dimg/dimg.cpp:2134
> #29 0xb6de10e6 in Digikam::ImageScanner::uniqueHash (this=0xb27acf7c) at
> /root/d
> igikam-svn/graphics/digikam/libs/database/imagescanner.cpp:609
> @
> #30 0xb6de3756 in Digikam::ImageScanner::prepareImage (this=0xb27acf7c)
> at /root
> /digikam-svn/graphics/digikam/libs/database/imagescanner.cpp:195
> #31 0xb6de393c in Digikam::ImageScanner::addImage (this=0xb27acf7c,
> albumId=0) a
> t /root/digikam-svn/graphics/digikam/libs/database/imagescanner.cpp:200
> #32 0xb6de410d in Digikam::ImageScanner::newFile (this=0xb27acf7c,
> albumId=0) at
>  /root/digikam-svn/graphics/digikam/libs/database/imagescanner.cpp:100
> #33 0xb6d93310 in Digikam::CollectionScanner::scanNewFile
> (this=0xb27ad2f8, info
> =@0x9bbeaf0c, albumId=0) at
> /root/digikam-svn/graphics/digikam/libs/database/col
> lectionscanner.cpp:758
> #34 0xb6d960df in Digikam::CollectionScanner::scanAlbum
> (this=0xb27ad2f8, locati
> on=@0x86079f8, album=@0xb27ad13c) at
> /root/digikam-svn/graphics/digikam/libs/dat
> abase/collectionscanner.cpp:667
> #35 0xb6d96357 in Digikam::CollectionScanner::scanAlbum
> (this=0xb27ad2f8, locati
> on=@0x86079f8, album=@0xb27ad218) at
> /root/digikam-svn/graphics/digikam/libs/dat
> abase/collectionscanner.cpp:685
> #36 0xb6d9685c in Digikam::CollectionScanner::scanAlbumRoot
> (this=0xb27ad2f8, lo
> cation=@0x86079f8) at
> /root/digikam-svn/graphics/digikam/libs/database/collectio
> nscanner.cpp:479
> #37 0xb6d970de in Digikam::CollectionScanner::completeScan
> (this=0xb27ad2f8) at
> /root/digikam-svn/graphics/digikam/libs/database/collectionscanner.cpp:250
> #38 0x08335a0f in Digikam::ScanController::run (this=0x8588fb8) at
> /root/digikam
> -svn/graphics/digikam/digikam/scancontroller.cpp:541
> #39 0xb56dbfc1 in ?? () from /usr/lib/qt4/libQtCore.so.4
> #40 0x08588fb8 in ?? ()
> #41 0x00000000 in ?? ()
>
> Thread 1 (Thread 0xb3bb2700 (LWP 30498)):
> #0  0xffffe424 in __kernel_vsyscall ()
> #1  0xb56828d5 in pthread_cond_wait@@GLIBC_2.3.2 () from
> /lib/libpthread.so.0
> #2  0xb56dc658 in QWaitCondition::wait () from
> /usr/lib/qt4/libQtCore.so.4
> #3  0xb56dc066 in QThread::wait () from /usr/lib/qt4/libQtCore.so.4
> #4  0x083347ae in Digikam::ScanController::shutDown (this=0x8588fb8) at
> /root/di
> gikam-svn/graphics/digikam/digikam/scancontroller.cpp:290
> #5  0x0833490f in ~ScanController (this=0x8588fb8) at
> /root/digikam-svn/graphics
> /digikam/digikam/scancontroller.cpp:273
> #6  0x083377b3 in ~ScanControllerCreator (this=0x8588fb8) at
> /root/digikam-svn/g
> raphics/digikam/digikam/scancontroller.cpp:221
> #7  0x08334a41 in destroy () at
> /root/digikam-svn/graphics/digikam/digikam/scanc
> ontroller.cpp:222
> #8  0x082804f5 in ~KCleanUpGlobalStatic (this=0x84eee5c) at
> /usr/include/kglobal
> .h:62
> #9  0x08332060 in __tcf_0 () at
> /root/digikam-svn/graphics/digikam/digikam/scanc
> ontroller.cpp:222
> #10 0xb544cbbc in exit () from /lib/libc.so.6
> #11 0xb5c919cb in ?? () from /usr/lib/qt4/libQtGui.so.4
> #12 0x00000001 in ?? ()
> #13 0x08526bc8 in ?? ()
> #14 0x0008a4e0 in ?? ()
> #15 0xb5c91999 in ?? () from /usr/lib/qt4/libQtGui.so.4
> #16 0xb67b6ff4 in ?? () from /usr/lib/libkdeui.so.5
> #17 0xbfb61258 in ?? ()
> #18 0xb65faaea in KApplication::xioErrhandler (this=0x3a0070, dpy=0x11)
> at /var/
> tmp/portage/kde-base/kdelibs-4.3.5/work/kdelibs-4.3.5/kdeui/kernel/kapplication.
> cpp:408
> Backtrace stopped: previous frame inner to this frame (corrupt stack?)
>
>
> _______________________________________________
> 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

[Todd Goodman]

* Marcel Wiesweg <[hidden email]> [100522 06:08]:

>
> > I'm getting a digikam crash everytime I try to start up digikam (and it
> > scans my files.)
> >
> > It's in libexiv2 (SVN from today, May 21, 2010.)
> >
> > I've tried looking some but would appreciate any pointers.  It looks
> > like the write fails but I'm not quite sure what's being written (TIFF
> > metadata to where?)
> >
> > I have lots of diskspace both on the image and SQLite database
> > filesystem (the same local disk.)
> >
> > I added debug and see that the group name is CANON and sv is four more
> > bytes than what was returned as having been written (I don't have that
> > debug in this trace since I just updated exiv2.)
> >
> > I suspect it's the same file each time but am not sure how to get the
> > filename from inside the exiv2 code.
> >
> > The last few lines of the stdout/stderr and stack backtrace are below.
> >
> > If anyone has any suggestions for debugging this I'd appreciate it.
>
> The best thing to do is isolating the file causing the crash.
> Is any filename printed on the console, before the debug output you included
> in your mail?

Hi Marcel,

No, the filename wasn't printed.  However, I decided to throw an error
before the assert in that case and now it continues the scan (I assume
messing up the already bogus metadata on that file?)

I missed that error in the scrollback buffer this time but I'll make
sure I have the filename when the error is caught and redirect stderr
and stdout to a file so I can find it next time.

Thanks,

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

>> > If anyone has any suggestions for debugging this I'd appreciate it.
>>
>> The best thing to do is isolating the file causing the crash.
>> Is any filename printed on the console, before the debug output you included
>> in your mail?
>
> Hi Marcel,
>
> No, the filename wasn't printed.  However, I decided to throw an error
> before the assert in that case and now it continues the scan (I assume
> messing up the already bogus metadata on that file?)

Todd,
Can you go back to the version with the assertion and run it with the
the patch below. This should output the name of the file (the
temporary file actually, but it will be obvious what the original file
is).

There appears to be something wrong with the write algorithm in the
presence of an image with a corrupted makernote. If you can isolate
the image and send it to me I'd like to fix this.

Thanks,
Andreas




Index: tiffcomposite_int.hpp
===================================================================
--- tiffcomposite_int.hpp       (revision 2226)
+++ tiffcomposite_int.hpp       (working copy)
@@ -199,7 +199,7 @@
         int putb(byte data);
         //@}

-    private:
+    public:
         // DATA
         BasicIo& io_;              //! Reference for the IO instance.
         const byte* pHeader_;      //! Pointer to the header data.
Index: tiffcomposite.cpp
===================================================================
--- tiffcomposite.cpp   (revision 2226)
+++ tiffcomposite.cpp   (working copy)
@@ -1329,6 +1329,7 @@
             uint32_t sv = (*i)->size();
             if (sv > 4) {
                 uint32_t d = (*i)->write(ioWrapper, byteOrder,
offset, valueIdx, dataIdx, imageIdx);
+                if (sv != d) std::cerr << "---------------> " <<
ioWrapper.io_.path() << " <---------------\n";
                 assert(sv == d);
                 if ((sv & 1) == 1) {
                     ioWrapper.putb(0x0);    // Align value to word boundary
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Todd Goodman]

* Andreas Huggel <[hidden email]> [100523 05:49]:

> >> > If anyone has any suggestions for debugging this I'd appreciate it.
> >>
> >> The best thing to do is isolating the file causing the crash.
> >> Is any filename printed on the console, before the debug output you included
> >> in your mail?
> >
> > Hi Marcel,
> >
> > No, the filename wasn't printed.  However, I decided to throw an error
> > before the assert in that case and now it continues the scan (I assume
> > messing up the already bogus metadata on that file?)
>
> Todd,
> Can you go back to the version with the assertion and run it with the
> the patch below. This should output the name of the file (the
> temporary file actually, but it will be obvious what the original file
> is).
>
> There appears to be something wrong with the write algorithm in the
> presence of an image with a corrupted makernote. If you can isolate
> the image and send it to me I'd like to fix this.
>
> Thanks,
> Andreas
>
>
>
>
> Index: tiffcomposite_int.hpp
> ===================================================================
> --- tiffcomposite_int.hpp       (revision 2226)
> +++ tiffcomposite_int.hpp       (working copy)
> @@ -199,7 +199,7 @@
>          int putb(byte data);
>          //@}
>
> -    private:
> +    public:
>          // DATA
>          BasicIo& io_;              //! Reference for the IO instance.
>          const byte* pHeader_;      //! Pointer to the header data.
> Index: tiffcomposite.cpp
> ===================================================================
> --- tiffcomposite.cpp   (revision 2226)
> +++ tiffcomposite.cpp   (working copy)
> @@ -1329,6 +1329,7 @@
>              uint32_t sv = (*i)->size();
>              if (sv > 4) {
>                  uint32_t d = (*i)->write(ioWrapper, byteOrder,
> offset, valueIdx, dataIdx, imageIdx);
> +                if (sv != d) std::cerr << "---------------> " <<
> ioWrapper.io_.path() << " <---------------\n";
>                  assert(sv == d);
>                  if ((sv & 1) == 1) {
>                      ioWrapper.putb(0x0);    // Align value to word boundary

Hi Andreas,

Thanks very much.  I'm running with this change and hopefully will find
the file causing the problem.

Sorry for the late reply!

Regards,

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

[Todd Goodman]

* Todd Goodman <[hidden email]> [100524 19:03]:

> * Andreas Huggel <[hidden email]> [100523 05:49]:
> > >> > If anyone has any suggestions for debugging this I'd appreciate it.
> > >>
> > >> The best thing to do is isolating the file causing the crash.
> > >> Is any filename printed on the console, before the debug output you included
> > >> in your mail?
> > >
> > > Hi Marcel,
> > >
> > > No, the filename wasn't printed.  However, I decided to throw an error
> > > before the assert in that case and now it continues the scan (I assume
> > > messing up the already bogus metadata on that file?)
> >
> > Todd,
> > Can you go back to the version with the assertion and run it with the
> > the patch below. This should output the name of the file (the
> > temporary file actually, but it will be obvious what the original file
> > is).
> >
> > There appears to be something wrong with the write algorithm in the
> > presence of an image with a corrupted makernote. If you can isolate
> > the image and send it to me I'd like to fix this.
> >
> > Thanks,
> > Andreas
> >
> >
> >
> >
> > Index: tiffcomposite_int.hpp
> > ===================================================================
> > --- tiffcomposite_int.hpp       (revision 2226)
> > +++ tiffcomposite_int.hpp       (working copy)
> > @@ -199,7 +199,7 @@
> >          int putb(byte data);
> >          //@}
> >
> > -    private:
> > +    public:
> >          // DATA
> >          BasicIo& io_;              //! Reference for the IO instance.
> >          const byte* pHeader_;      //! Pointer to the header data.
> > Index: tiffcomposite.cpp
> > ===================================================================
> > --- tiffcomposite.cpp   (revision 2226)
> > +++ tiffcomposite.cpp   (working copy)
> > @@ -1329,6 +1329,7 @@
> >              uint32_t sv = (*i)->size();
> >              if (sv > 4) {
> >                  uint32_t d = (*i)->write(ioWrapper, byteOrder,
> > offset, valueIdx, dataIdx, imageIdx);
> > +                if (sv != d) std::cerr << "---------------> " <<
> > ioWrapper.io_.path() << " <---------------\n";
> >                  assert(sv == d);
> >                  if ((sv & 1) == 1) {
> >                      ioWrapper.putb(0x0);    // Align value to word boundary

Unfortunately only have:

Error: Directory Canon, entry 0x3130 has invalid size 1850671152*1;
skipping entry.
Warning: Directory Canon, entry 0x5265 has unknown Exif (TIFF) type
24933; setting type size 1.
Error: Directory Canon, entry 0x5265 has invalid size 1634026604*1;
skipping entry.
---------------> MemIo <---------------
digikam: /root/digikam-svn/exiv2/src/tiffcomposite.cpp:1334: virtual
uint32_t
Exiv2::Internal::TiffDirectory::doWrite(Exiv2::Internal::IoWrapper&,
Exiv2::ByteOrder, int32_t, uint32_t, uint32_t, uint32_t&): Assertion `sv
== d' failed.
KCrash: Application 'digikam' crashing...
digikam: Fatal IO error: client killed
sock_file=/root/.kde-svn/socket-mail-proxy/kdeinit4_localhost_13
Warning: connect() failed: : No such file or directory
KCrash cannot reach kdeinit, launching directly.

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