Bug 350367 - Digikam crash when saving edited picture
Summary: Digikam crash when saving edited picture
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Metadata-Engine (show other bugs)
Version: 4.11.0
Platform: Mint (Ubuntu based) Linux
: NOR crash
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords: drkonqi
Depends on:
Blocks:
 
Reported: 2015-07-19 09:55 UTC by Thomas
Modified: 2021-05-04 04:14 UTC (History)
5 users (show)

See Also:
Latest Commit:
Version Fixed In: 7.3.0


Attachments
New crash information added by DrKonqi (8.84 KB, text/plain)
2015-08-21 19:54 UTC, nils.pooth
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas 2015-07-19 09:55:34 UTC
Application: digikam (4.11.0)
KDE Platform Version: 4.14.2
Qt Version: 4.8.6
Operating System: Linux 3.13.0-37-generic x86_64
Distribution: Linux Mint 17.1 Rebecca

-- Information about the crash:
- What I was doing when the application crashed:
I opened a JPG file in the image editor and modified it. Then when I try to save or save as the file Digikam crash. So I'm unable to save modification done in the Image Editor.
System Info : 
Linux Mint 17.1
Qt: 4.8.6
KDE Development Platform: 4.14.2
digiKam: 4.11.0

The crash can be reproduced every time.

-- Backtrace:
Application: digiKam (digikam), signal: Aborted
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
[Current thread is 1 (Thread 0x7fd999e72ac0 (LWP 4200))]

Thread 5 (Thread 0x7fd96f95d700 (LWP 4201)):
#0  0x00007fd992a3d12d in poll () at ../sysdeps/unix/syscall-template.S:81
#1  0x00007fd9750f8248 in ?? () from /lib/x86_64-linux-gnu/libusb-1.0.so.0
#2  0x00007fd98fb70182 in start_thread (arg=0x7fd96f95d700) at pthread_create.c:312
#3  0x00007fd992a4a47d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 4 (Thread 0x7fd966291700 (LWP 4202)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x00007fd993525816 in wait (time=18446744073709551615, this=0x1937780) at thread/qwaitcondition_unix.cpp:86
#2  QWaitCondition::wait (this=this@entry=0x19376c0, mutex=mutex@entry=0x19376b8, time=time@entry=18446744073709551615) at thread/qwaitcondition_unix.cpp:158
#3  0x00000000005db1ee in Digikam::ScanController::run (this=0x18b3c00) at /build/digikam-2XzB7s/digikam-4.11.0/core/app/database/scancontroller.cpp:725
#4  0x00007fd99352532f in QThreadPrivate::start (arg=0x18b3c00) at thread/qthread_unix.cpp:349
#5  0x00007fd98fb70182 in start_thread (arg=0x7fd966291700) at pthread_create.c:312
#6  0x00007fd992a4a47d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 3 (Thread 0x7fd965a90700 (LWP 4203)):
#0  0x00007fd98ab50610 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#1  0x00007fd98ab509a9 in g_mutex_unlock () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x00007fd98ab0ef91 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x00007fd98ab0f0ec in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#4  0x00007fd9936547be in QEventDispatcherGlib::processEvents (this=0x7fd9580008c0, flags=...) at kernel/qeventdispatcher_glib.cpp:436
#5  0x00007fd9936260af in QEventLoop::processEvents (this=this@entry=0x7fd965a8fae0, flags=...) at kernel/qeventloop.cpp:149
#6  0x00007fd9936263a5 in QEventLoop::exec (this=this@entry=0x7fd965a8fae0, flags=...) at kernel/qeventloop.cpp:204
#7  0x00007fd993522c5f in QThread::exec (this=this@entry=0x19388b0) at thread/qthread.cpp:537
#8  0x00007fd993607823 in QInotifyFileSystemWatcherEngine::run (this=0x19388b0) at io/qfilesystemwatcher_inotify.cpp:265
#9  0x00007fd99352532f in QThreadPrivate::start (arg=0x19388b0) at thread/qthread_unix.cpp:349
#10 0x00007fd98fb70182 in start_thread (arg=0x7fd965a90700) at pthread_create.c:312
#11 0x00007fd992a4a47d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 2 (Thread 0x7fd9157fa700 (LWP 4286)):
[KCrash Handler]
#6  0x00007fd992986cc9 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#7  0x00007fd99298a0d8 in __GI_abort () at abort.c:89
#8  0x00007fd99297fb86 in __assert_fail_base (fmt=0x7fd999e5d05f "%s%s%s\302\240:%u\302\240:\302\240%s%s l'assertion \302\253\302\240%s\302\240\302\273 a \303\251chou\303\251.\n%n", assertion=assertion@entry=0x7fd990c088d8 "mn_", file=file@entry=0x7fd990c08832 "tiffcomposite.cpp", line=line@entry=749, function=function@entry=0x7fd990c09260 <Exiv2::Internal::TiffMnEntry::doAddPath(unsigned short, std::stack<Exiv2::Internal::TiffPathItem, std::deque<Exiv2::Internal::TiffPathItem, std::allocator<Exiv2::Internal::TiffPathItem> > >&, Exiv2::Internal::TiffComponent*, std::auto_ptr<Exiv2::Internal::TiffComponent>)::__PRETTY_FUNCTION__> "virtual Exiv2::Internal::TiffComponent* Exiv2::Internal::TiffMnEntry::doAddPath(uint16_t, Exiv2::Internal::TiffPath&, Exiv2::Internal::TiffComponent*, Exiv2::Internal::TiffComponent::AutoPtr)") at assert.c:92
#9  0x00007fd99297fc32 in __GI___assert_fail (assertion=0x7fd990c088d8 "mn_", file=0x7fd990c08832 "tiffcomposite.cpp", line=749, function=0x7fd990c09260 <Exiv2::Internal::TiffMnEntry::doAddPath(unsigned short, std::stack<Exiv2::Internal::TiffPathItem, std::deque<Exiv2::Internal::TiffPathItem, std::allocator<Exiv2::Internal::TiffPathItem> > >&, Exiv2::Internal::TiffComponent*, std::auto_ptr<Exiv2::Internal::TiffComponent>)::__PRETTY_FUNCTION__> "virtual Exiv2::Internal::TiffComponent* Exiv2::Internal::TiffMnEntry::doAddPath(uint16_t, Exiv2::Internal::TiffPath&, Exiv2::Internal::TiffComponent*, Exiv2::Internal::TiffComponent::AutoPtr)") at assert.c:101
#10 0x00007fd990b1fc66 in Exiv2::Internal::TiffMnEntry::doAddPath (this=0x7fd8e8059450, tag=<optimized out>, tiffPath=..., pRoot=<optimized out>, object=...) at tiffcomposite.cpp:749
#11 0x00007fd990b1e0a5 in Exiv2::Internal::TiffComponent::addPath (this=this@entry=0x7fd8e8059450, tag=tag@entry=2, tiffPath=..., pRoot=pRoot@entry=0x7fd8e80252d0, object=...) at tiffcomposite.cpp:634
#12 0x00007fd990b1f2f2 in Exiv2::Internal::TiffDirectory::doAddPath (this=<optimized out>, tag=<optimized out>, tiffPath=..., pRoot=0x7fd8e80252d0, object=...) at tiffcomposite.cpp:694
#13 0x00007fd990b1e0a5 in Exiv2::Internal::TiffComponent::addPath (this=<optimized out>, tag=tag@entry=2, tiffPath=..., pRoot=pRoot@entry=0x7fd8e80252d0, object=...) at tiffcomposite.cpp:634
#14 0x00007fd990b1f8cd in Exiv2::Internal::TiffSubIfd::doAddPath (this=0x7fd8e8058ec0, tag=<optimized out>, tiffPath=..., pRoot=0x7fd8e80252d0, object=...) at tiffcomposite.cpp:729
#15 0x00007fd990b1e0a5 in Exiv2::Internal::TiffComponent::addPath (this=this@entry=0x7fd8e8058ec0, tag=tag@entry=2, tiffPath=..., pRoot=pRoot@entry=0x7fd8e80252d0, object=...) at tiffcomposite.cpp:634
#16 0x00007fd990b1f2f2 in Exiv2::Internal::TiffDirectory::doAddPath (this=<optimized out>, tag=<optimized out>, tiffPath=..., pRoot=0x7fd8e80252d0, object=...) at tiffcomposite.cpp:694
#17 0x00007fd990b1e0a5 in Exiv2::Internal::TiffComponent::addPath (this=this@entry=0x7fd8e80252d0, tag=<optimized out>, tiffPath=..., pRoot=pRoot@entry=0x7fd8e80252d0, object=...) at tiffcomposite.cpp:634
#18 0x00007fd990b3c802 in Exiv2::Internal::TiffEncoder::add (this=this@entry=0x7fd9157f7ce0, pRootDir=pRootDir@entry=0x7fd8e80252d0, pSourceDir=pSourceDir@entry=0x0, root=root@entry=131072) at tiffvisitor.cpp:1094
#19 0x00007fd990b299f1 in Exiv2::Internal::TiffParserWorker::encode (io=..., pData=pData@entry=0x0, size=size@entry=0, exifData=..., iptcData=..., xmpData=..., root=root@entry=131072, findEncoderFct=0x7fd990b26370 <Exiv2::Internal::TiffMapping::findEncoder(std::string const&, unsigned int, Exiv2::Internal::IfdId)>, pHeader=pHeader@entry=0x7fd8e8025380, pOffsetWriter=pOffsetWriter@entry=0x0) at tiffimage.cpp:2164
#20 0x00007fd990ab7bde in Exiv2::ExifParser::encode (blob=..., pData=0x0, size=0, byteOrder=Exiv2::littleEndian, exifData=...) at exif.cpp:719
#21 0x00007fd990ad1f29 in Exiv2::JpegBase::doWriteMetadata (this=this@entry=0x7fd8e804bf50, outIo=...) at jpgimage.cpp:837
#22 0x00007fd990ad36ca in Exiv2::JpegBase::writeMetadata (this=0x7fd8e804bf50) at jpgimage.cpp:662
#23 0x00007fd99827b7d6 in KExiv2Iface::KExiv2::Private::saveOperations (this=this@entry=0x7fd8e8002420, finfo=..., image=...) at ../../libkexiv2/kexiv2_p.cpp:312
#24 0x00007fd99827dbdd in KExiv2Iface::KExiv2::Private::saveToFile (this=0x7fd8e8002420, finfo=...) at ../../libkexiv2/kexiv2_p.cpp:155
#25 0x00007fd99827979a in KExiv2Iface::KExiv2::save (this=0x7fd9157f9280, imageFilePath=...) at ../../libkexiv2/kexiv2.cpp:448
#26 0x00007fd998279df9 in KExiv2Iface::KExiv2::applyChanges (this=this@entry=0x7fd9157f9280) at ../../libkexiv2/kexiv2.cpp:476
#27 0x00007fd997b84b42 in Digikam::DMetadata::applyChanges (this=this@entry=0x7fd9157f9280) at /build/digikam-2XzB7s/digikam-4.11.0/core/libs/dmetadata/dmetadata.cpp:130
#28 0x00007fd997a34ff5 in Digikam::DImgLoader::saveMetadata (this=0x7fd9157f9a00, filePath=...) at /build/digikam-2XzB7s/digikam-4.11.0/core/libs/dimg/loaders/dimgloader.cpp:290
#29 0x00007fd997a3a2f5 in Digikam::JPEGLoader::save (this=this@entry=0x7fd9157f9a00, filePath=..., observer=observer@entry=0x540b840) at /build/digikam-2XzB7s/digikam-4.11.0/core/libs/dimg/loaders/jpegloader.cpp:907
#30 0x00007fd997a0fe20 in Digikam::DImg::save (this=this@entry=0x540b858, filePath=..., format=..., observer=observer@entry=0x540b840) at /build/digikam-2XzB7s/digikam-4.11.0/core/libs/dimg/dimg.cpp:681
#31 0x00007fd997bda49f in Digikam::SavingTask::execute (this=0x540b830) at /build/digikam-2XzB7s/digikam-4.11.0/core/libs/threadimageio/loadsavetask.cpp:457
#32 0x00007fd997bcc046 in Digikam::LoadSaveThread::run (this=0x43431b0) at /build/digikam-2XzB7s/digikam-4.11.0/core/libs/threadimageio/loadsavethread.cpp:136
#33 0x00007fd997bfadce in Digikam::DynamicThread::DynamicThreadPriv::run (this=0x4344730) at /build/digikam-2XzB7s/digikam-4.11.0/core/libs/threads/dynamicthread.cpp:186
#34 0x00007fd993518fee in QThreadPoolThread::run (this=0x31ac5c0) at concurrent/qthreadpool.cpp:108
#35 0x00007fd99352532f in QThreadPrivate::start (arg=0x31ac5c0) at thread/qthread_unix.cpp:349
#36 0x00007fd98fb70182 in start_thread (arg=0x7fd9157fa700) at pthread_create.c:312
#37 0x00007fd992a4a47d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 1 (Thread 0x7fd999e72ac0 (LWP 4200)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x00007fd993525816 in wait (time=18446744073709551615, this=0x1c84930) at thread/qwaitcondition_unix.cpp:86
#2  QWaitCondition::wait (this=this@entry=0x1a00950, mutex=mutex@entry=0x1a00928, time=time@entry=18446744073709551615) at thread/qwaitcondition_unix.cpp:158
#3  0x00007fd993518242 in QThreadPoolPrivate::waitForDone (this=0x1a008a0, msecs=msecs@entry=-1) at concurrent/qthreadpool.cpp:295
#4  0x00007fd9935196b5 in QThreadPool::~QThreadPool (this=0x1c85370, __in_chrg=<optimized out>) at concurrent/qthreadpool.cpp:438
#5  0x00007fd9935196e9 in QThreadPool::~QThreadPool (this=0x1c85370, __in_chrg=<optimized out>) at concurrent/qthreadpool.cpp:440
#6  0x00007fd99363e168 in QObjectPrivate::deleteChildren (this=this@entry=0x1c9bb10) at kernel/qobject.cpp:1907
#7  0x00007fd9936406ff in QObject::~QObject (this=0x1c99b10, __in_chrg=<optimized out>) at kernel/qobject.cpp:926
#8  0x00007fd997bf7f47 in ~ThreadManagerCreator (this=0x1c99b10, __in_chrg=<optimized out>) at /build/digikam-2XzB7s/digikam-4.11.0/core/libs/threads/threadmanager.cpp:236
#9  destroy () at /build/digikam-2XzB7s/digikam-4.11.0/core/libs/threads/threadmanager.cpp:241
#10 0x00007fd99298c259 in __run_exit_handlers (status=1, listp=0x7fd992d0e6c8 <__exit_funcs>, run_list_atexit=run_list_atexit@entry=true) at exit.c:82
#11 0x00007fd99298c2a5 in __GI_exit (status=<optimized out>) at exit.c:104
#12 0x00007fd97db2a224 in ?? () from /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0
#13 0x00007fd994d23880 in KApplication::xioErrhandler (this=0x7fffe7863a60, dpy=0x1684ab0) at ../../kdeui/kernel/kapplication.cpp:419
#14 0x00007fd9914475ee in _XIOError () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#15 0x00007fd991444fed in _XEventsQueued () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#16 0x00007fd9914370db in XEventsQueued () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#17 0x00007fd9940bb65c in x11EventSourceCheck (s=0x1682860) at kernel/qguieventdispatcher_glib.cpp:85
#18 0x00007fd98ab0ea61 in g_main_context_check () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#19 0x00007fd98ab0ef7b in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#20 0x00007fd98ab0f0ec in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#21 0x00007fd9936547a1 in QEventDispatcherGlib::processEvents (this=0x1599fd0, flags=...) at kernel/qeventdispatcher_glib.cpp:434
#22 0x00007fd9940bbbe6 in QGuiEventDispatcherGlib::processEvents (this=<optimized out>, flags=...) at kernel/qguieventdispatcher_glib.cpp:204
#23 0x00007fd9936260af in QEventLoop::processEvents (this=this@entry=0x7fffe7863570, flags=...) at kernel/qeventloop.cpp:149
#24 0x00007fd9936263a5 in QEventLoop::exec (this=this@entry=0x7fffe7863570, flags=...) at kernel/qeventloop.cpp:204
#25 0x00007fd99362bb79 in QCoreApplication::exec () at kernel/qcoreapplication.cpp:1225
#26 0x00007fd99401837c in QApplication::exec () at kernel/qapplication.cpp:3828
#27 0x0000000000497bc6 in main (argc=<optimized out>, argv=<optimized out>) at /build/digikam-2XzB7s/digikam-4.11.0/core/app/main/main.cpp:230

Possible duplicates by query: bug 343257, bug 342010, bug 341307, bug 341024.

Reported using DrKonqi
Comment 1 caulier.gilles 2015-07-19 11:43:33 UTC
It crash in Exiv2 shared lib in TIFF file parser.

Please report this problem to Exiv2 library bugzilla with exiv2 version used (look in digiKam Help/Components Info dialog for details). 

http://dev.exiv2.org/projects/exiv2/wiki

Also image edited where you can reproduce the problem.

Gilles Caulier
Comment 2 Thomas 2015-07-19 12:34:30 UTC
Thank you for your very quick answer.
As requested I report the bug to exiv2 dev team, see link below.
http://dev.exiv2.org/issues/1094

Thomas
Comment 3 nils.pooth 2015-08-21 19:54:45 UTC
Created attachment 94155 [details]
New crash information added by DrKonqi

gwenview (4.14.0 pre) on KDE Platform 4.14.10 using Qt 4.8.7

- What I was doing when the application crashed:

I know this bug is closed. I also followed the bug report from Thomas at exiv2. The exiv2-guys closed his bug as well because they said they can't reproduse it.

I still have the same problem as Thomas. When I edit any JPG from my CASIO EX-Z300 with Gwenview or Digikam and try to save, both programs will crash immeditaley without saving the JPG. This happens every time.

This happens never when I edit JPGs from my CANON EOS 500D. Before Tumbleweed I used 13.1 and had not this problem.

When I load this CASIO JPG in Gimp and remove any metadata and reopen it with Gwenview and edit and save again: Everything works fine.

When you're still convinced it's an exiv-problem - sorry for my report. I will try to reopen it at exiv as well.

Nils

-- Backtrace (Reduced):
#6  0x00007f81c7617fbb in Exiv2::Internal::TiffComponent::addPath(unsigned short, std::stack<Exiv2::Internal::TiffPathItem, std::deque<Exiv2::Internal::TiffPathItem, std::allocator<Exiv2::Internal::TiffPathItem> > >&, Exiv2::Internal::TiffComponent*, std::auto_ptr<Exiv2::Internal::TiffComponent>) () from /usr/lib64/libexiv2.so.14
#7  0x00007f81c761d8cf in Exiv2::Internal::TiffMnEntry::doAddPath(unsigned short, std::stack<Exiv2::Internal::TiffPathItem, std::deque<Exiv2::Internal::TiffPathItem, std::allocator<Exiv2::Internal::TiffPathItem> > >&, Exiv2::Internal::TiffComponent*, std::auto_ptr<Exiv2::Internal::TiffComponent>) () from /usr/lib64/libexiv2.so.14
#8  0x00007f81c7617fd2 in Exiv2::Internal::TiffComponent::addPath(unsigned short, std::stack<Exiv2::Internal::TiffPathItem, std::deque<Exiv2::Internal::TiffPathItem, std::allocator<Exiv2::Internal::TiffPathItem> > >&, Exiv2::Internal::TiffComponent*, std::auto_ptr<Exiv2::Internal::TiffComponent>) () from /usr/lib64/libexiv2.so.14
#9  0x00007f81c76186df in Exiv2::Internal::TiffDirectory::doAddPath(unsigned short, std::stack<Exiv2::Internal::TiffPathItem, std::deque<Exiv2::Internal::TiffPathItem, std::allocator<Exiv2::Internal::TiffPathItem> > >&, Exiv2::Internal::TiffComponent*, std::auto_ptr<Exiv2::Internal::TiffComponent>) () from /usr/lib64/libexiv2.so.14
#10 0x00007f81c7617fd2 in Exiv2::Internal::TiffComponent::addPath(unsigned short, std::stack<Exiv2::Internal::TiffPathItem, std::deque<Exiv2::Internal::TiffPathItem, std::allocator<Exiv2::Internal::TiffPathItem> > >&, Exiv2::Internal::TiffComponent*, std::auto_ptr<Exiv2::Internal::TiffComponent>) () from /usr/lib64/libexiv2.so.14
Comment 4 caulier.gilles 2015-08-21 20:20:59 UTC
Problem is into Exiv2 shared library when TIFF structure is parsed. report this problem to Exiv2 team.

Gilles Caulier
Comment 5 caulier.gilles 2015-08-23 12:18:09 UTC
*** Bug 351638 has been marked as a duplicate of this bug. ***
Comment 6 Thomas 2015-08-23 13:44:37 UTC
(In reply to Gilles Caulier from comment #4)
> Problem is into Exiv2 shared library when TIFF structure is parsed. report
> this problem to Exiv2 team.
> 
> Gilles Caulier

I do report the bug to Exiv2 dev team but they close it as "not a bug". I don't have the knowledge to dig further and help the Exiv2 spot the bug. Maybe you are someone else can help them to do so ?

As reference the ticket in Exiv2 bug tracking system:
http://dev.exiv2.org/issues/1094
Comment 7 Thomas 2015-08-23 13:46:06 UTC
(In reply to Thomas from comment #6)
> 
> (In reply to Gilles Caulier from comment #4)
> > Problem is into Exiv2 shared library when TIFF structure is parsed. report
> > this problem to Exiv2 team.
> > 
> > Gilles Caulier
> 
> I do report the bug to Exiv2 dev team but they close it as "not a bug". I
> don't have the knowledge to dig further and help the Exiv2 spot the bug.
> Maybe you are someone else can help them to do so ?
> 
> As reference the ticket in Exiv2 bug tracking system:
> http://dev.exiv2.org/issues/1094

Sorry for my terrible english. I meant "Maybe you OR someone else can help them to do so ?"
Comment 8 caulier.gilles 2015-08-23 14:07:19 UTC
Well, it simple. Look well the original trace :

#20 0x00007fd990ab7bde in Exiv2::ExifParser::encode (blob=..., pData=0x0, size=0, byteOrder=Exiv2::littleEndian, exifData=...) at exif.cpp:719
#21 0x00007fd990ad1f29 in Exiv2::JpegBase::doWriteMetadata (this=this@entry=0x7fd8e804bf50, outIo=...) at jpgimage.cpp:837
#22 0x00007fd990ad36ca in Exiv2::JpegBase::writeMetadata (this=0x7fd8e804bf50) at jpgimage.cpp:662
#23 0x00007fd99827b7d6 in KExiv2Iface::KExiv2::Private::saveOperations (this=this@entry=0x7fd8e8002420, finfo=..., image=...) at ../../libkexiv2/kexiv2_p.cpp:312

This happen when a metadata is writtent o a jpeg file, into TIFF metadata structure. As i can see, the test done by Exiv2 team is just to read metadata with your JPEG image, through exiv2 CLI tool, not to write something into it...

So the test in Exiv2 report is not valid to said int's not a bug... Re-open it please...

Gilles Caulier
Comment 9 Thomas 2015-08-23 17:05:27 UTC
According to this ticket :
http://dev.exiv2.org/issues/1106
They solve the issue andan user have been able to test it positively. As I don't know how to recompile everything I will wait for the next release of exiv2.
Comment 10 Ingo Rehmke 2015-08-25 14:20:04 UTC
HI there,
i have the same problem. it will be solved in exiv2 version 0.26. Until this release i changed my dk settings, so no data will be written in the metadat of the pictures, just in the dk dtabase. so it works without problem. with the new exiv2 version i hope to save these again in the metadata.
Thanks to you for your patience and help
Comment 11 caulier.gilles 2015-12-30 18:08:25 UTC
*** Bug 357340 has been marked as a duplicate of this bug. ***
Comment 12 caulier.gilles 2016-02-22 19:41:46 UTC
*** Bug 359674 has been marked as a duplicate of this bug. ***
Comment 13 caulier.gilles 2021-05-04 04:14:56 UTC
Not reproducible with digiKam 7.3.0 and Exiv2 0.27.4