Problem going to GCC from ICC

[tmortime]

We have been using the Intel C++ compiler for quite a while and have, for various reasons, decided to switch to GCC. We were able to build pretty easily but now experience pretty frequent crashes, usually in the form of an invalid free. The following output is obtained. You'll notice the Valgrind output doesn't appear to be from the same spot as what you get when in the debugger, not sure why, but it all appears to be std::string related.
 
The offending line is this
result += ife_print (&ife);
 
where result is a so called ChString which is our own String class, which inherites from std::basic_string, and then defined as typedef String<char> ChString.
 
the ife_print function signature returns an std::string object.
 
Any help in this matter would be greatly appreciated.
 
Regards,
-Tom
 
*** glibc detected *** ./netseq-linux: free(): invalid pointer: 0xb7d73a25 ***
/lib/i686/nosegneg/libc.so.6[0x7fbd1d]
/lib/i686/nosegneg/libc.so.6(cfree+0x90)[0x7ff3d0]
/usr/lib/libstdc++.so.6(_ZdlPv+0x21)[0x388ef1]
/usr/lib/libstdc++.so.6(_ZNSs4_Rep10_M_destroyERKSaIcE+0x1d)[0x365a6d]
/usr/lib/libstdc++.so.6(_ZNSs7reserveEj+0xa8)[0x3671c8]
/usr/lib/libstdc++.so.6(_ZNSs6appendERKSs+0x4d)[0x3675cd]
/usr/lib/libstdc++.so.6(_ZNSspLERKSs+0x24)[0x367654]
./netseq-linux[0x81a78b0]
./netseq-linux[0x819fd60]
...
 
And in the debugger:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 2325392 (LWP 24450)]
0x008038ac in memcpy () from /lib/i686/nosegneg/libc.so.6
(gdb) bt
#0  0x008038ac in memcpy () from /lib/i686/nosegneg/libc.so.6
#1  0x003665e4 in std::string::_Rep::_M_clone () from /usr/lib/libstdc++.so.6
#2  0x00367168 in std::string::reserve () from /usr/lib/libstdc++.so.6
#3  0x003675cd in std::string::append () from /usr/lib/libstdc++.so.6
#4  0x00367654 in std::string::operator+= () from /usr/lib/libstdc++.so.6
#5  0x081a78b0 in NetToolsLinux::ifconfig (this=0x91b3938) at NetToolsLinux.cpp:82
#6  0x0819fd60 in MachineImplLinux::ifconfig (this=0x91b38e8) at MachineLinux.cpp:430
#7  0x0816fe1e in Machine::ifconfig (this=0x91b3944) at Machine.cpp:107
#8  0x082b5985 in SeqScr::InterfaceInfo::prepareReport (this=0xb7ecc0a8) at InterfaceInfo.cpp:60
#9  0x082b5c55 in SeqScr::InterfaceInfo::dataUpdate (this=0xb7ecc0a8, msgPackets=@0x91d0dc8) at InterfaceInfo.cpp:29
#10 0x0827a1d0 in SeqScr::ScriptExec::dataUpdate (this=0xb7e22430, msgPackets=@0x91d0dc8) at ScriptExec.cpp:132
#11 0x08244339 in ITestElement::dataUpdate (this=0xb7e22430, msgPackets=@0x91d0dc8) at ITestElement.cpp:301
#12 0x0820b794 in TestMaster::processCompletedPackets (this=0x91d0b04, message=@0x91d0dc8) at TestMaster.cpp:390
#13 0x081b5324 in Controller::processCachedPackets (this=0x91d0b04) at Controller.cpp:115
#14 0x081b5593 in Controller::onTimeout (this=0x91d0b04) at Controller.cpp:41
#15 0x0832ab8e in APN::Task::iterate ()
#16 0x0832a61b in APN::Task::svc ()
#17 0x08475e7a in ACE_Task_Base::svc_run ()
#18 0x08488958 in ACE_Thread_Adapter::invoke ()
#19 0x0090b302 in start_thread () from /lib/i686/nosegneg/libpthread.so.0
#20 0x008643ae in clone () from /lib/i686/nosegneg/libc.so.6
 
And Valgrind:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 2325392 (LWP 24450)]
0x008038ac in memcpy () from /lib/i686/nosegneg/libc.so.6
(gdb) bt
#0  0x008038ac in memcpy () from /lib/i686/nosegneg/libc.so.6
#1  0x003665e4 in std::string::_Rep::_M_clone () from /usr/lib/libstdc++.so.6
#2  0x00367168 in std::string::reserve () from /usr/lib/libstdc++.so.6
#3  0x003675cd in std::string::append () from /usr/lib/libstdc++.so.6
#4  0x00367654 in std::string::operator+= () from /usr/lib/libstdc++.so.6
#5  0x081a78b0 in NetToolsLinux::ifconfig (this=0x91b3938) at NetToolsLinux.cpp:82
#6  0x0819fd60 in MachineImplLinux::ifconfig (this=0x91b38e8) at MachineLinux.cpp:430
#7  0x0816fe1e in Machine::ifconfig (this=0x91b3944) at Machine.cpp:107
#8  0x082b5985 in SeqScr::InterfaceInfo::prepareReport (this=0xb7ecc0a8) at InterfaceInfo.cpp:60
#9  0x082b5c55 in SeqScr::InterfaceInfo::dataUpdate (this=0xb7ecc0a8, msgPackets=@0x91d0dc8) at InterfaceInfo.cpp:29
#10 0x0827a1d0 in SeqScr::ScriptExec::dataUpdate (this=0xb7e22430, msgPackets=@0x91d0dc8) at ScriptExec.cpp:132
#11 0x08244339 in ITestElement::dataUpdate (this=0xb7e22430, msgPackets=@0x91d0dc8) at ITestElement.cpp:301
#12 0x0820b794 in TestMaster::processCompletedPackets (this=0x91d0b04, message=@0x91d0dc8) at TestMaster.cpp:390
#13 0x081b5324 in Controller::processCachedPackets (this=0x91d0b04) at Controller.cpp:115
#14 0x081b5593 in Controller::onTimeout (this=0x91d0b04) at Controller.cpp:41
#15 0x0832ab8e in APN::Task::iterate ()
#16 0x0832a61b in APN::Task::svc ()
#17 0x08475e7a in ACE_Task_Base::svc_run ()
#18 0x08488958 in ACE_Thread_Adapter::invoke ()
#19 0x0090b302 in start_thread () from /lib/i686/nosegneg/libpthread.so.0
#20 0x008643ae in clone () from /lib/i686/nosegneg/libc.so.6

[Andrew Haley]

tmortime wrote:

> We have been using the Intel C++ compiler for quite a while and have, for
> various reasons, decided to switch to GCC. We were able to build pretty
> easily but now experience pretty frequent crashes, usually in the form of an
> invalid free. The following output is obtained. You'll notice the Valgrind
> output doesn't appear to be from the same spot as what you get when in the
> debugger, not sure why, but it all appears to be std::string related.
>  
> The offending line is this
> result += ife_print (&ife);
>  
> where result is a so called ChString which is our own String class, which
> inherites from std::basic_string, and then defined as typedef String<char>
> ChString.
>  
> the ife_print function signature returns an std::string object.
>  
> Any help in this matter would be greatly appreciated.

You're in a much better position than us in that you have the source code and
you can debug it.  If you can make a test case from your code and post it
here, we'll be able to help.

Andrew.

[tmortime]

Thanks for all the replies, both on the list and off. The problem actually ended up being a lack of virtual destructor in our String class. Not sure how it worked before... maybe it always had this problem but the Intel libraries didn't catch the invalid free in the same way. Not sure.

Thanks again,
-Tom