Here is the relevant part of the backtrace obtained with gdb:
#0 0x0000006e in ?? ()
#1 0x005e007b in Exiv2::ExifData::findKey(Exiv2::ExifKey const&) () from /usr/lib/libexiv2.so.6
#2 0x005e03e5 in Exiv2::ExifData::operator[](std::string const&) () from /usr/lib/libexiv2.so.6
#3 0x004efaf3 in exiv2wrapper::ExifTag::setParentImage(exiv2wrapper::Image&) () from /home/osomon/dev/pyexiv2-branches/pyexiv2/build/libexiv2python.so
The problem is with re-setting the parent image of a tag (not just EXIF tags for that matter, the same issue likely exists for IPTC and XMP tags) to the same owner image. It should be relatively easy to add a check to avoid the problem.
@Yannick: note that the bug can easily be worked around by doing something like this:
Here is the relevant part of the backtrace obtained with gdb:
#0 0x0000006e in ?? () ExifData: :findKey( Exiv2:: ExifKey const&) () from /usr/lib/ libexiv2. so.6 ExifData: :operator[ ](std:: string const&) () from /usr/lib/ libexiv2. so.6 :ExifTag: :setParentImage (exiv2wrapper: :Image& ) () from /home/osomon/ dev/pyexiv2- branches/ pyexiv2/ build/libexiv2p ython.so
#1 0x005e007b in Exiv2::
#2 0x005e03e5 in Exiv2::
#3 0x004efaf3 in exiv2wrapper:
The problem is with re-setting the parent image of a tag (not just EXIF tags for that matter, the same issue likely exists for IPTC and XMP tags) to the same owner image. It should be relatively easy to add a check to avoid the problem.
@Yannick: note that the bug can easily be worked around by doing something like this:
d1[key] = pyexiv2. ExifTag( key, d1[key].value)
or, even more concise:
d1[key] = d1[key].value