[Insight-users] itk with vxl runtime error

Tomáš Kazmar Tomash.Kazmar at seznam.cz
Sun Oct 28 12:28:18 EDT 2007


Hi all, 

  have anyone tried to build itk with current vxl-1.9.0 (USE_SYSTEM_VXL option)
and to use both itk and vxl stuff from you program? To me an empty program
consisting of empty main and linked together with both libs gives memory
allocation errors (such as glibc complaining about its memory management list
overwritten...). Am I doing something wrong? Is it possible to link to both types
of libs?

To me valgrind gives error message like this:

==10308== Memcheck, a memory error detector.
==10308== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
==10308== Using LibVEX rev 1732, a library for dynamic binary translation.
==10308== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
==10308== Using valgrind-3.2.3, a dynamic binary instrumentation framework.
==10308== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
==10308== For more details, rerun with: -v
==10308==
==10308== Invalid free() / delete / delete[]
==10308==    at 0x4004B48: operator delete[](void*) (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==10308==    by 0x4CE76E3: vnl_bignum::~vnl_bignum() (in /afs/ms.mff.cuni.cz/u/k/kazmt1am/BIG/diplo/itk-build/bin/libitkvnl.so.3.5.0)
==10308==    by 0x4CEEAF3: __tcf_3 (in /afs/ms.mff.cuni.cz/u/k/kazmt1am/BIG/diplo/itk-build/bin/libitkvnl.so.3.5.0)
==10308==    by 0x414CC895: __cxa_finalize (in /lib/libc-2.5.so)
==10308==  Address 0x55EEFA8 is 0 bytes inside a block of size 2 free'd
==10308==    at 0x4004B48: operator delete[](void*) (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==10308==    by 0x4CE76E3: vnl_bignum::~vnl_bignum() (in /afs/ms.mff.cuni.cz/u/k/kazmt1am/BIG/diplo/itk-build/bin/libitkvnl.so.3.5.0)
==10308==    by 0x523B08F: __tcf_3 (in /afs/ms.mff.cuni.cz/u/k/kazmt1am/BIG/diplo/vxl-build/lib/libvnl.so)
==10308==    by 0x414CC895: __cxa_finalize (in /lib/libc-2.5.so)
==10308==
==10308== Invalid free() / delete / delete[]
==10308==    at 0x4004B48: operator delete[](void*) (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==10308==    by 0x4CE76E3: vnl_bignum::~vnl_bignum() (in /afs/ms.mff.cuni.cz/u/k/kazmt1am/BIG/diplo/itk-build/bin/libitkvnl.so.3.5.0)
==10308==    by 0x4CEEB19: __tcf_2 (in /afs/ms.mff.cuni.cz/u/k/kazmt1am/BIG/diplo/itk-build/bin/libitkvnl.so.3.5.0)
==10308==    by 0x414CC895: __cxa_finalize (in /lib/libc-2.5.so)
==10308==  Address 0x55EEF70 is 0 bytes inside a block of size 2 free'd
==10308==    at 0x4004B48: operator delete[](void*) (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==10308==    by 0x4CE76E3: vnl_bignum::~vnl_bignum() (in /afs/ms.mff.cuni.cz/u/k/kazmt1am/BIG/diplo/itk-build/bin/libitkvnl.so.3.5.0)
==10308==    by 0x523B0B5: __tcf_2 (in /afs/ms.mff.cuni.cz/u/k/kazmt1am/BIG/diplo/vxl-build/lib/libvnl.so)
==10308==    by 0x414CC895: __cxa_finalize (in /lib/libc-2.5.so)
==10308==
==10308== Invalid free() / delete / delete[]
==10308==    at 0x40051FC: free (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==10308==    by 0x415AD972: (within /lib/libc-2.5.so)
==10308==  Address 0x43E1838 is not stack'd, malloc'd or (recently) free'd
==10308==
==10308== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 6 from 1)
==10308== malloc/free: in use at exit: 4 bytes in 2 blocks.
==10308== malloc/free: 13,798 allocs, 13,799 frees, 393,874 bytes allocated.
==10308== For counts of detected errors, rerun with: -v
==10308== searching for pointers to 2 not-freed blocks.
==10308== checked 640,632 bytes.
==10308==
==10308== LEAK SUMMARY:
==10308==    definitely lost: 4 bytes in 2 blocks.
==10308==      possibly lost: 0 bytes in 0 blocks.
==10308==    still reachable: 0 bytes in 0 blocks.
==10308==         suppressed: 0 bytes in 0 blocks.
==10308== Rerun with --leak-check=full to see details of leaked memory.

Linking with only vxl or only itkvxl libs is ok as I do not really need the vxl libs.
I am just curious what happens there. It looks like if itk/vxl was allocating
the "same" memory differently.

Thanks for any hints.

Regrads,
Tomas


More information about the Insight-users mailing list