0.8.1 build failure

2005-09-11
2013-05-30
  • Stefan Lucke

    Stefan Lucke - 2005-09-11

    I got an error building current release:

    g++  -g -O2  -lsqlite3 -ljs -lmagic -lid3 -lexif -o mediatomb  mediatomb-main.o libmediatomb.a -lupnp -lixml -lthreadutil -lz -lsqlite3
    libmediatomb.a(libmediatomb_a-content_manager.o)(.text+0x39b): In function `ContentManager::ContentManager[not-in-charge]()':
    ../src/content_manager.cc:116: undefined reference to `magic_open'

    That is wrong ordering of libs.
    g++  -g -O2 -o mediatomb mediatomb-main.o  libmediatomb.a -lsqlite3 -ljs -lmagic -lid3 -lexif -lupnp -lixml -lthreadutil -lz -lsqlite3
    calling that this way worked.

     
    • Martin Heerling

      Martin Heerling - 2005-09-11

      Same here (Suse 9.0).
      I was able to bypass the build failure by updating the "file" package (which is in fact libmagic + friends) with a version supplying both static (libmagic.a) and shared (libmagic.so.1.0.0) versions of the library. Build process works now.

      Marv

       
    • Jin

      Jin - 2005-09-11

      Thanks for the report, guys! Stefan, I assume you also have Suse?

      We had some problems with circular dependencies but got it sorted out for FC3, FC4 and Debian. Unfortunately we do not have a Suse installation, so your feedback is quite important.

      Thanks again,
      Jin

       
    • Stefan Lucke

      Stefan Lucke - 2005-09-11

      Actually yes. My system is based on SuSe 9.0 too. There is only the static version of libmagic.

      stefan@jarada:~> ll /usr/lib/libmag*
      -rw-r--r--    1 root     root        58766 2003-09-23 18:54 /usr/lib/libmagic.a
      -rwxr-xr-x    1 root     root          654 2003-09-23 18:54 /usr/lib/libmagic.la

      Stefan

       
    • Jin

      Jin - 2005-09-11

      btw, Martin, what is the updated "file" package on Suse that you installed, and that allowed compiliing with our default settings?

      I am currently thinking if we should bring out 0.8.2 with the Suse fix, or if that could wait (assuming that this additional file package is part of the default Suse distro, then just indicating the problem would probably be enough for now)

      Thanks,
      Jin

       
      • Martin Heerling

        Martin Heerling - 2005-09-11

        It is a "rpmrebuild --rebuild file-4.13-5.src.rpm" from the Suse 9.3 Source package, to be found on all Suse mirrors.

        I think they changed the it to build the shared lib as well since up to 9.2 (IIRC) the binary package contains only the static libmagic.a but not the libmagis.so shared lib.

        I have some other weird problems on 0.8.1.
        On a distinct point - about 15000 media files - it just segfaults with a segmentation fault - no difference it sqlite or mysql is used. From that point, no new media files can be imported - it just segfaults. Any hints on what I can try to isolate?

        I uncommented all the //-ed "log_*" sequences in the source code files (had to rename a vaiable on two places to get it compiled, although) and ran the so built "debug" binary - but the error makes no sense to me - no output, just segfault..

        Greets,
        Marv

         
    • Jin

      Jin - 2005-09-11

      Uhh... well, could be a number of things.. I tried over 100.000 files and it was OK, so I don't think that the amount matters. I suspect that it may be related to some special file that is being imported (are you always trying with the same files, or does it happen with random data?). It is possible that something goes wrong when parsing metadata of that particular file... that's a guess though.

      What you could do:
      first of all - could you please send me either a backtrace or the coredump file? If no coredump is created try setting "ulimit -c 99999" in the terminal where you run mediatomb.

      I do not know if you are familiar with gdb, but here is how you create a backtrace:
      after the segfault you run gdb /usr/bin/mediatomb /path/to/coredump.1234
      when gdb loads, type "bt" and press enter, the trace should indicate where the crash happened.

      Another thing you could do:
      add the following to content_manager.cc, line 537 (after the if (S_ISREG.... { stuff)
      log_debug(("Processing file: %s\n", path.c_str()));
      Please check if it always segfaults on the same file, or if the problem appears with random data.

      Thanks a lot!
      Jin

       
    • Martin Heerling

      Martin Heerling - 2005-09-11

      Hmmm. It seems it spits on some files, particularly files which does not deliver any mime type at all.

      mheerling@styx:~> file -i /mnt/archive1/2.AVI
      /mnt/archive1/2.AVI:
      mheerling@styx:~> file /mnt/archive1/2.AVI
      /mnt/archive1/2.AVI: RIFF (little-endian) data, wrapped MPEG-1 (CDXA)

      So it is obviously a problem on my side.
      I have made some additional mappings in config.xml - we will see what will happen.

      Right now the import continues, but very sloooowwwwwlyyyy.
      I'll keep you informed.
      Thanks for you gdb/backtrace hints, I'm not familiar on using gdb. If it fails again I will try to produce some investigatable stuff.
      Thanks + greets,
      Marv

       
    • Jin

      Jin - 2005-09-11

      Well, a segfault means, that no matter how tricky your files are - the problem is for sure on our side - we should never crash :)

      Anyway, would be really cool if you could send me the coredump file, then I could take a look at what is going wrong myself.

      About your avi file, try "file -i /mnt/archive1/2.AVI", what does it say?

      Btw, about import speed: we are already working on optimizations and are trying to improve overall performance, so it will get better :)

      Greetings,
      Jin

       
    • Martin Heerling

      Martin Heerling - 2005-09-11

      > About your avi file, try "file -i /mnt/archive1/2.AVI", what does it say?

      As I wrote, it gives no output at all. See my previous post.
      For the coredump, I have to wait 'til it crashes again. Right now it fools me and works...

      The speed thing sound good. It's quite funny because the first 2000 items or so it imports at lightning speed and sometimes later it starts crowling...

      Greets,
      Marv

       
    • Martin Heerling

      Martin Heerling - 2005-09-11

      Ok, here we are:
      (gdb)
      (gdb) bt
      #0  0x402367a4 in exif_get_sshort () from /usr/lib/libexif.so.9
      #1  0x402367c8 in exif_get_short () from /usr/lib/libexif.so.9
      #2  0x4022da81 in exif_data_load_data_content () from /usr/lib/libexif.so.9
      #3  0x4022dc20 in exif_data_load_data_content () from /usr/lib/libexif.so.9
      #4  0x4022dc20 in exif_data_load_data_content () from /usr/lib/libexif.so.9
      #5  0x4022dc20 in exif_data_load_data_content () from /usr/lib/libexif.so.9
      #6  0x4022e586 in exif_data_load_data () from /usr/lib/libexif.so.9
      #7  0x4022d784 in exif_data_new_from_data () from /usr/lib/libexif.so.9
      #8  0x402365e7 in exif_loader_get_data () from /usr/lib/libexif.so.9
      #9  0x4022e810 in exif_data_new_from_file () from /usr/lib/libexif.so.9
      #10 0x0807b278 in LibExifHandler::fillMetadata(zmm::Ref<CdsItem>) (this=0x81f3048, item={_ptr = 0x81e1ec0})
          at ../src/metadata/libexif_handler.cc:363
      #11 0x08057542 in MetadataHandler::setMetadata(zmm::Ref<CdsItem>) (item={_ptr = 0x81e1ec0}) at ../src/metadata_handler.cc:138
      #12 0x08051542 in ContentManager::createObjectFromFile(zmm::String, bool) (this=0x45b5d9ec, path={base = 0x809bcc8}, magic=true)
          at ../src/content_manager.cc:575
      #13 0x0804ea39 in ContentManager::addRecursive(zmm::String, zmm::String) (this=0x80cd960, path={base = 0x814bb30}, parentID=
            {base = 0x814e638}) at ../src/content_manager.cc:324
      #14 0x0804ebc9 in ContentManager::addRecursive(zmm::String, zmm::String) (this=0x80cd960, path={base = 0x80c92a8}, parentID=
            {base = 0x40f1ce38}) at ../src/content_manager.cc:345
      #15 0x0804e668 in ContentManager::_addFile(zmm::String, int) (this=0x80cd960, path={base = 0x80995f8}, recursive=1)
          at ../src/content_manager.cc:264
      #16 0x08052868 in CMAddFileTask::run() (this=0x80d1eb8) at ../src/content_manager.cc:922
      #17 0x08051cd2 in ContentManager::threadProc() (this=0x80cd960) at ../src/content_manager.cc:805
      #18 0x08051def in ContentManager::staticThreadProc(void*) (arg=0x80cd960) at ../src/content_manager.cc:817
      #19 0x40490f60 in pthread_start_thread () from /lib/i686/libpthread.so.0
      #20 0x40434327 in clone () from /lib/i686/libc.so.6
      (gdb)

       
    • Martin Heerling

      Martin Heerling - 2005-09-11

      And here is the backtrace with LD_ASSUME_KERNEL=2.2.5 (I'm running 2.4.21-297-smp4G with single CPU (a Suse patched kernel).

      #0  0x402367a4 in exif_get_sshort () from /usr/lib/libexif.so.9
      (gdb) bt
      #0  0x402367a4 in exif_get_sshort () from /usr/lib/libexif.so.9
      #1  0x402367c8 in exif_get_short () from /usr/lib/libexif.so.9
      #2  0x4022da81 in exif_data_load_data_content () from /usr/lib/libexif.so.9
      #3  0x4022dc20 in exif_data_load_data_content () from /usr/lib/libexif.so.9
      #4  0x4022dc20 in exif_data_load_data_content () from /usr/lib/libexif.so.9
      #5  0x4022dc20 in exif_data_load_data_content () from /usr/lib/libexif.so.9
      #6  0x4022e586 in exif_data_load_data () from /usr/lib/libexif.so.9
      #7  0x4022d784 in exif_data_new_from_data () from /usr/lib/libexif.so.9
      #8  0x402365e7 in exif_loader_get_data () from /usr/lib/libexif.so.9
      #9  0x4022e810 in exif_data_new_from_file () from /usr/lib/libexif.so.9
      #10 0x0807b278 in LibExifHandler::fillMetadata(zmm::Ref<CdsItem>) (this=0x822c8b0, item={_ptr = 0x822a440})
          at ../src/metadata/libexif_handler.cc:363
      #11 0x08057542 in MetadataHandler::setMetadata(zmm::Ref<CdsItem>) (item={_ptr = 0x822a440}) at ../src/metadata_handler.cc:138
      #12 0x08051542 in ContentManager::createObjectFromFile(zmm::String, bool) (this=0xbdfff5ec, path={base = 0x809bcc8}, magic=true)
          at ../src/content_manager.cc:575
      #13 0x0804ea39 in ContentManager::addRecursive(zmm::String, zmm::String) (this=0x80cd1c0, path={base = 0x81304e8}, parentID={base = 0x81cf568})
          at ../src/content_manager.cc:324
      #14 0x0804ebc9 in ContentManager::addRecursive(zmm::String, zmm::String) (this=0x80cd1c0, path={base = 0x80c92a0}, parentID={base = 0x80eb718})
          at ../src/content_manager.cc:345
      #15 0x0804e668 in ContentManager::_addFile(zmm::String, int) (this=0x80cd1c0, path={base = 0x80995f8}, recursive=1)
          at ../src/content_manager.cc:264
      #16 0x08052868 in CMAddFileTask::run() (this=0x80cb3b0) at ../src/content_manager.cc:922
      #17 0x08051cd2 in ContentManager::threadProc() (this=0x80cd1c0) at ../src/content_manager.cc:805
      #18 0x08051def in ContentManager::staticThreadProc(void*) (arg=0x80cd1c0) at ../src/content_manager.cc:817
      #19 0x40493150 in pthread_start_thread () from /lib/libpthread.so.0
      #20 0x40436167 in clone () from /lib/libc.so.6

       
    • Martin Heerling

      Martin Heerling - 2005-09-11

      And me again. I did an update for libexif to version 0.6.12 and it gets past the previous points. So it seems that it is not mediatomb's fault.

      Greets,
      Marv

       
    • Jin

      Jin - 2005-09-12

      Hi, first of all: thanks a lot for your investigation!!

      Indeed, seeing from the backtrace - the problem was in the exif library.

      Thanks,
      Jin

       

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks