Bug 158989

Summary: digikam won't start: MakerTagInfo registry full (MetaEngine relevant)
Product: [Applications] digikam Reporter: Mark Nowiasz <mark+kde>
Component: Portability-RuntimeAssignee: Digikam Developers <digikam-bugs-null>
Status: RESOLVED FIXED    
Severity: crash CC: ahuggel, caulier.gilles
Priority: NOR    
Version: unspecified   
Target Milestone: ---   
Platform: FreeBSD Ports   
OS: FreeBSD   
Latest Commit: Version Fixed In: 7.3.0
Sentry Crash Report:

Description Mark Nowiasz 2008-03-09 02:01:40 UTC
Version:            (using KDE 3.5.8)
Installed from:    FreeBSD Ports
Compiler:          gcc (GCC) 4.2.1 20070719  [FreeBSD] 
OS:                FreeBSD

When trying to start digikam via shell, it creates the following error message:

>digikam
terminate called after throwing an instance of 'Exiv2::Error'
  what():  MakerTagInfo registry full
Abort (core dumped)
Comment 1 Pino Toscano 2008-03-09 02:20:31 UTC
What is the version of your libexiv2 are you using?
Comment 2 Mark Nowiasz 2008-03-09 14:04:25 UTC
I'm using libexif-0.6.15
Comment 3 caulier.gilles 2008-03-09 14:14:51 UTC
Not libexif ! libexiv2...

Gilles Caulier
Comment 4 Mark Nowiasz 2008-03-09 14:18:12 UTC
Oops, sorry :-(

exiv2-0.16,1
Comment 5 Andreas Huggel 2008-03-10 12:39:02 UTC
What version of exiv2 was digikam compiled with? 

(I'm sure how to best check that, I think there is something like an "About" Window somewhere with version info, maybe that shows it.)

Andreas
Comment 6 Andreas Huggel 2008-03-10 12:39:48 UTC
s/sure/not sure/
Comment 7 Mark Nowiasz 2008-03-10 12:59:21 UTC
Well, it's not possible to use *any* window, since digikam won't start at all - it just aborts when trying to start it. As stated above:

exiv2-0.16,1
Comment 8 Andreas Huggel 2008-03-11 04:38:00 UTC
yeah yeah of course, my bad.

Can you find it out from the BSD package info?
Comment 9 Andreas Huggel 2008-03-11 05:39:27 UTC
This problem has come up before and so far was always a symptom for an invalid combination of versions. (Which shouldn't happen in the first place, there is something else wrong somewhere.)

freshports.org lists the following releases for the relevant packages. If you install the libkexiv2 and exiv2 packages which were current at the release date of your version of digikam, does that fix the problem?

digikam:
23-Dec-2007 0.9.3
18-Sep-2007 0.9.2_1
23-Jul-2007 0.9.2

libkexiv2:
07-Mar-2008 0.1.6_1
18-Sep-2007 0.1.6
02-Jul-2007 0.1.5

exiv2: 
07-Mar-2008 0.16,1
23-Jul-2007 0.14,1
Comment 10 Mark Nowiasz 2008-03-11 15:49:35 UTC
I'd be glad to test it - but I can't find the old version (0.14,1) of exiv2 anywhere :-(
Comment 11 caulier.gilles 2008-03-19 07:54:26 UTC
Mark,

At least, i recommend to only install one version of shared library to prevent confusion.

I have already seen many report about incompatibility between shared library, especailly with Exiv2...

Andreas, i suspect than older Exiv2 versions which don't use a standard ABI number can fragilize recent releases as well when both version are installed at the same time... In all cases, removing older Exiv2 releases fix the problem...

Gilles Caulier
Comment 12 Arnd Baecker 2008-04-10 12:01:41 UTC
Mark, any update on this bug?

Many thanks in advance, Arnd
Comment 13 Arnd Baecker 2008-04-24 10:55:49 UTC
Mark, any update on this bug? Otherwise it will be closed ...

Many thanks in advance, Arnd 
Comment 14 krienke 2008-05-27 10:55:49 UTC
Hello,

since digikam 0.9.4-beta5 I have exactly the problem described here. I run a openSuSE 10.3 system. I have libexiv2-2-0.16-17 and its devel package installed  and compiled digikam with this config. This works fine. However when I start digikam it then tells me it cannot find libexiv2.so.0 . When I install additionally libexiv2-0.15-8.2 then digikam will start however then I get the "MakerTagInfo registry full" error.

When I completely remove the rpms libexiv2-2-0.16-17 as well as libexiv2-devel-2-0.16-17 and only install libexiv2-0.15-8.2 as well as libexiv2-devel-0.15-8.2 and then recompile digikam everything works fine and no 
"MakerTagInfo registry full"  error is shown. 

With digikam 0.9.4-beta4 I did not have this problem and beta4 still runs fine no matter if libexiv2-2-016-17 is installed or not. 
Comment 15 caulier.gilles 2008-05-27 11:56:26 UTC
Andreas,

Your viewpoint about comment #14 ?

Gilles Caulier
Comment 16 Andreas Huggel 2008-05-27 18:01:24 UTC
> When I install additionally libexiv2-0.15-8.2 then digikam will start
> however then I get the "MakerTagInfo registry full" error. 

So does it load 0.15? Since digikam (and I assume libkexiv2) was compiled with exiv2 0.16, that would be the case I mentioned in comment #9. Digikam shouldn't even start in this case! (see below)

> When I [...] only install libexiv2-0.15-8.2 as well as
> libexiv2-devel-0.15-8.2 and then recompile digikam everything works fine
> and no "MakerTagInfo registry full"  error is shown. 

Compile and run the same versions of everything: works fine. That's fine.

The questions are
1) When you installed libexiv2-2-0.16-17, you say "when I start digikam it then tells me it cannot find libexiv2.so.0". Why not? And why is it not looking for libexiv2.so.2 (see below)??

2) When digikam was compiled with v0.16 and run with 0.15, why does it load the library in the first place? 

Here is a small illustration done using the tarballs from the exiv2 distribution:

When I install exiv2 0.16 in /usr/local/lib, it installs
 libexiv2.so.2.1.0
 libexiv2.so.2 -> libexiv2.so.2.1.0
 libexiv2.so -> libexiv2.so.2.1.0

When I compile a small application (exifprint from the samples directory), I get
$ ldd exifprint
	libexiv2.so.2 => /usr/local/lib/libexiv2.so.2 (0xb7de6000)
        (and several others)

Now, I uninstall exiv2 0.16 and install 0.15 instead. In /usr/local/lib, it installs
 libexiv2.so.0.1.0
 libexiv2.so.0 -> libexiv2.so.0.1.0
 libexiv2.so -> libexiv2.so.0.1.0

When I now try to run the application compiled with 0.16, I get

$ exiv2-0.16/samples/exifprint
exiv2-0.16/samples/exifprint: error while loading shared libraries: libexiv2.so.2: cannot open shared object file: No such file or directory

It doesn't even start! So I don't understand how it is possible to run digikam with exiv2 0.15 when it was compiled with exiv2 0.16

Do you have any other versions of exiv2 installed on your system?

Or is it a problem with the exiv2 package of your distribution? Try the same thing that you did with the exiv2 distribution from www.exiv2.org to find out. I would expect similar results as those described above.

-ahu.
Comment 17 krienke 2008-05-28 08:50:43 UTC
Am Dienstag, 27. Mai 2008 18:01:25 schrieb Andreas Huggel:
[bugs.kde.org quoted mail]

I uninstalled the 0.16 rpm versions of exiv2 and then compiled the 0.16 
version from source and installed it. After I recompiled digikam 0.9.4-beta5 
it now works for me. It seems the exiv2-0.16 rpm I had caused the problem. 

digkam uses now /usr/lib/libexiv2.so.0 from libexiv2-0.15-8.2 but anyway it 
works. The 0.15 is still required for kde which links to this version. The 
0.16 version was required for kde4. 

Rainer
Comment 18 caulier.gilles 2008-05-28 09:01:03 UTC
So, this file can be closed now ?

Gilles Caulier
Comment 19 krienke 2008-05-28 09:51:22 UTC
Am Mittwoch, 28. Mai 2008 08:50:44 schrieb krienke@uni-koblenz.de:
[bugs.kde.org quoted mail]

I just found another explanaition for the "MakerTagInfo registry full". I just 
tried to start digikam from the souce directory. The installed version runs 
fine. If I however try to start  

$ ./digikam-0.9.4-beta5/digikam/digikam/digikam
terminate called after throwing an instance of 'Exiv2::Error'
  what():  MakerTagInfo registry full
Aborted

So here I still get the this error allthogh the very same version of digikam 
is already installed and runs. Strange. 

Have anice day
Rainer
Comment 20 Andreas Huggel 2008-05-28 13:02:53 UTC
Just curious, can you do 

   $ ldd digikam 

from eg, your home directory and 

   $ ldd ./digikam-0.9.4-beta5/digikam/digikam/digikam

to see if they load the same exiv2 library?

-ahu.
Comment 21 krienke 2008-05-28 13:15:51 UTC
Am Mittwoch, 28. Mai 2008 13:02:54 schrieb Andreas Huggel:
> ------- You are receiving this mail because: -------
> You are the assignee for the bug, or are watching the assignee.
>


$ ldd /opt/kde3/bin/digikam | grep exiv2
        libkexiv2.so.3 => /opt/kde3/lib/libkexiv2.so.3 (0xb73bd000)
        libexiv2.so.0 => /usr/lib/libexiv2.so.0 (0xb72c4000)

The digikam file in digikam-0.9.4-beta5/digikam/digikam is a bourne shell 
script.   It says its a wrapper:

# digikam - temporary wrapper script for .libs/digikam
# ....

It finally calls digikam-0.9.4-beta5/digikam/digikam/.libs/lt-digikam

$ ldd digikam-0.9.4-beta5/digikam/digikam/.libs/lt-digikam | grep exiv2
        libkexiv2.so.3 => /opt/kde3/lib/libkexiv2.so.3 (0xb73dd000)
        libexiv2.so.2 => /usr/lib/libexiv2.so.2 (0xb7260000)
        libexiv2.so.0 => /usr/lib/libexiv2.so.0 (0xb595a000)

Rainer
Comment 22 caulier.gilles 2008-05-28 13:25:57 UTC
Andreas,

This is the problem :

   libexiv2.so.2 => /usr/lib/libexiv2.so.2 (0xb7260000)
   libexiv2.so.0 => /usr/lib/libexiv2.so.0 (0xb595a000)

How it's possible ?

Gilles
Comment 23 Andreas Huggel 2008-05-28 13:42:46 UTC
Yup. I suspect libkexiv2 loads one version and digikam is directly linked to another version.

-ahu.
Comment 24 caulier.gilles 2008-05-28 13:46:46 UTC
Andreas,

But digiKam is not linked with Exiv2 directly (there is nothing in this way from the Makefile.am). Only libkexiv2 must do.

It's a packaging problem ?

Gilles
Comment 25 Andreas Huggel 2008-05-28 15:08:43 UTC
I think we can find out what is linked to libexiv2 by running ldd on each of the libraries digikam is linked to. Those that don't show up anywhere are directly linked to digikam. A bit tedious since there are many but I don't have a better idea.

Rainer, since you have the interesting case with different versions, could you please do that? Start with libkexiv2 and then go through all the other libraries that digikam is linked to to see if any of them is linked to libexiv2. If not it must be digikam itself.

I don't think it's a packaging problem, Rainer compiled this version of digikam himself.

-ahu.
Comment 26 krienke 2008-05-29 15:08:07 UTC
Am Mittwoch, 28. Mai 2008 15:08:43 schrieb Andreas Huggel:

> Rainer, since you have the interesting case with different versions, could
> you please do that? Start with libkexiv2 and then go through all the other
> libraries that digikam is linked to to see if any of them is linked to
> libexiv2. If not it must be digikam itself.


Ok, what I did was to run this quite simple loop in the beta5 source tree:

for i in `ldd digikam/digikam/.libs/lt-digikam | awk '{print $3}'`; do 
        ldd $i|grep exiv2 && echo $i; 
done

it does a ldd on all shared libs lt-digikam depends on and then does a ldd on 
each of these libs and greps all occurences of exiv2 and then echos the lib 
they were found in if there were any.

The result is:

        libkexiv2.so.3 => /opt/kde3/lib/libkexiv2.so.3 (0xb73d0000)
        libexiv2.so.2 => /usr/lib/libexiv2.so.2 (0xb7252000)
        libexiv2.so.0 => /usr/lib/libexiv2.so.0 (0xb5974000)
/home/krienke/tmp/digikam/digikam-0.9.4-beta5/digikam/digikam/.libs/libdigikam.so.0
        libexiv2.so.0 => /usr/lib/libexiv2.so.0 (0xb7ea6000)
/opt/kde3/lib/libkexiv2.so.3

So both libdigikam.so.0 links to exiv2 as well as libkexiv2.so.3

Is this what you wanted to see?

Rainer
Comment 27 Andreas Huggel 2008-05-29 18:31:12 UTC
Rainer,
Yes, thanks, good job!

Gilles,
The public libkexiv2 API "leaks" Exiv2 objects in at least 2 places:
   static void printExiv2ExceptionError(const QString& msg, Exiv2::Error& e);
   static QString convertCommentValue(const Exiv2::Exifdatum &comment);

(I didn't check if it also throws Exiv2::Error out of the library)

If these methods are used in digikam, then digikam must link to Exiv2. And if it links a different version than libkexiv2 then I'm not sure what will happen.
Is it possible that you use Exiv2 objects only in the implementation of libkexiv2 and not in its API? (I suggest nowhere in kexiv2.h at all, not even in the private sections of the classes there) This includes that libkexiv2 shouldn't throw Exiv2 objects for digikam to catch.

Having said that, I still don't really understand this bug. The error that we get is not caused by any of these calls directly, it happens during the initialization of Exiv2, before any client call is made. I've opened a bug for Exiv2 to replace this initialization code with something more straightforward (http://dev.robotbattle.com/mantis/view.php?id=550), maybe that will help too.

-ahu.
Comment 28 caulier.gilles 2008-05-29 19:37:14 UTC
> static void printExiv2ExceptionError(const QString& msg, Exiv2::Error& e); 

==> Not used in digiKam

> static QString convertCommentValue(const Exiv2::Exifdatum &comment); 

==> Not used in digiKam

> I didn't check if it also throws Exiv2::Error out of the library

No isn't it....

> Is it possible that you use Exiv2 objects only in the implementation of >libkexiv2 and not in its API? (I suggest nowhere in kexiv2.h at all, not even >in the private sections of the classes there) This includes that libkexiv2 >shouldn't throw Exiv2 objects for digikam to catch. 

Yes, i will do it.

Gilles
Comment 29 caulier.gilles 2008-05-30 08:20:20 UTC
SVN commit 814354 by cgilles:

libkexiv2 from trunk : reduce memory fingerprint and API simplifications: remove unecessary private methods to access on internal STD C++ and Exiv2 C++ components
CCBUGS: 158989 


 M  +4 -5      CMakeLists.txt  
 M  +15 -15    kexiv2.cpp  
 M  +4 -35     kexiv2.h  
 M  +5 -5      kexiv2comments.cpp  
 M  +0 -45     kexiv2private.cpp  
 M  +4 -2      kexiv2private.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=814354
Comment 30 caulier.gilles 2008-05-30 08:22:49 UTC
SVN commit 814357 by cgilles:

libkexiv2 from trunk : No need to redeclare internal Exiv2 components here.
CCBUGS: 158989


 M  +0 -3      kexiv2.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=814357
Comment 31 caulier.gilles 2008-05-30 09:09:26 UTC
SVN commit 814363 by cgilles:

libkexiv2 from trunk : improve binary compatibility again. do not make visible all private methods from kexiv2.h
Now, all Exiv2 components are unknow from host application which use libkexiv2
CCBUGS: 158989


 M  +2 -8      kexiv2.cpp  
 M  +242 -152  kexiv2.h  
 M  +1 -92     kexiv2comments.cpp  
 M  +30 -30    kexiv2exif.cpp  
 M  +8 -8      kexiv2gps.cpp  
 M  +11 -11    kexiv2image.cpp  
 M  +19 -19    kexiv2iptc.cpp  
 M  +106 -0    kexiv2private.h  
 M  +19 -19    kexiv2xmp.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=814363
Comment 32 caulier.gilles 2008-05-30 09:11:11 UTC
Andreas,

I have reassigned this file to libkexiv2 component in bugzilla

Gilles
Comment 33 caulier.gilles 2008-05-30 09:12:29 UTC
SVN commit 814370 by cgilles:

digiKam from trunk : compile following libkexiv2 api changes
CCBUGS: 158989


 M  +16 -14    libs/dmetadata/dmetadata.cpp  
 M  +4 -2      libs/widgets/metadata/exifwidget.cpp  
 M  +4 -2      libs/widgets/metadata/iptcwidget.cpp  
 M  +4 -2      libs/widgets/metadata/makernotewidget.cpp  
 M  +4 -2      libs/widgets/metadata/xmpwidget.cpp  
 M  +2 -0      project/project.kdevelop  


WebSVN link: http://websvn.kde.org/?view=rev&revision=814370
Comment 34 caulier.gilles 2008-05-30 09:19:40 UTC
Andreas,

I can't do more...

Only libkexiv2 from trunk (KDE4) is fixed. libkexiv2 from KDE3 branch still as well, to preserve binary compatibility (libkexiv2 have just been released and digiKam/kipi-plugins are in beta release)

Please, check (only) kexiv2.h from trunk. All Exiv2 component are now invisible from library host program. I have also removed unecessary private methods.

http://websvn.kde.org/trunk/extragear/libs/libkexiv2/libkexiv2/kexiv2.h?revision=814371&view=markup

If it's fine for you, i will close this file here and mark this file as resolved into libkexiv2 for KDE4 NEWS file.

Best

Gilles Caulier
Comment 35 Andreas Huggel 2008-06-03 04:31:34 UTC
Looks good. I've also fixed Exiv2 bug #550, it will be in 0.17 - if nothing else, that removes at least the symptom :)

Did you find out why libdigikam.so links with exiv2?

-ahu.
Comment 36 caulier.gilles 2008-06-03 09:39:57 UTC
> Did you find out why libdigikam.so links with exiv2? 

Not yet.

Like libkexiv2 0.17 have been released, i currently fix libkexiv2 for KDE3 in the same way than KDE4 version.

Gilles
Comment 37 caulier.gilles 2008-06-03 09:46:58 UTC
SVN commit 816063 by cgilles:

libkexiv2 from KDE3 branch : binary compatibility is broken here. API change to export all Exiv2 access classes to internal private container.
This fix is similar than last changes from KDE4 implementation.
BUGS: 158989


 M  +1 -1      Makefile.am  
 M  +55 -299   kexiv2.cpp  
 M  +4 -51     kexiv2.h  
 AM            kexiv2private.cpp   [License: GPL (v2+)]
 AM            kexiv2private.h   [License: GPL (v2+)]


WebSVN link: http://websvn.kde.org/?view=rev&revision=816063
Comment 38 caulier.gilles 2021-05-09 14:51:16 UTC
Not reproducible with digiKam 7.3.0 and Exiv2 0.27.4