0

I have a code written in C++ which generates a sharedlib(.so) file which in turn is used in my application which runs on RHEL3.

Now I have to migrate to RHEL5. The code for the .so file compiles successfully but when I try to bring my services up it shows **glibc corrupted double linked list** but the services start successfully.

Can this be due to OS as the same code for same .so compiled in RHEL3 is working fine.

Also if I copy the .so file compiled in RHEL3 to the RHEL5 machine everything works fine.

    This is what i got by running valgrind :
==19845== Invalid read of size 4
==19845==    at 0x453F4EC: std::_Rb_tree<int, std::pair<int const, key>, std::_Select1st<std::pair<int const, key> >, std::less<int>, std::allocator<std::pair<int const, key> > >::_S_right(std::_Rb_tree_node_base*) (in /home/test/examplesofile1.so)
==19845==    by 0x45408AA: std::_Rb_tree<int, std::pair<int const, key>, std::_Select1st<std::pair<int const, key> >, std::less<int>, std::allocator<std::pair<int const, key> > >::_M_erase(std::_Rb_tree_node<std::pair<int const, key> >*) (in /home/test/examplesofile1.so)
==19845==    by 0x4540918: std::_Rb_tree<int, std::pair<int const, key>, std::_Select1st<std::pair<int const, key> >, std::less<int>, std::allocator<std::pair<int const, key> > >::~_Rb_tree() (in /home/test/examplesofile1.so)
==19845==    by 0x4540974: std::map<int, key, std::less<int>, std::allocator<std::pair<int const, key> > >::~map() (in /home/test/examplesofile1.so)
==19845==    by 0x48235FB: (within /home/test/examplesofile2.so)
==19845==    by 0xAA5058: __cxa_finalize (in /lib/libc-2.5.so)
==19845==    by 0x477BC03: (within /home/test/examplesofile2.so)
==19845==    by 0x4A2FDEB: (within /home/test/examplesofile2.so)
==19845==    by 0xA697CD: _dl_fini (in /lib/ld-2.5.so)
==19845==    by 0xAA4DA8: exit (in /lib/libc-2.5.so)
==19845==    by 0x8086F57: vMakeDaemon (commonfunctions.c:438)
==19845==    by 0x8067F9A: Initialize (mngr.c:360)
user3338642
  • 201
  • 1
  • 2
  • 5

1 Answers1

1

In most cases this means that some memory is freed twice. So the bug is most probably in your code.

Try to recompile your library on new system and use valgrind to find what caused the problem.

ldanko
  • 557
  • 8
  • 20