libs compilation

A

Andre Siqueira

We have a program, that was previous compiled by another people.
We develop a library that this program loads.

We have experience craches in this program. Looking at the gdb we
find:

#0 0xc020cc68 in kill+0x10 () from /usr/lib/libc.2
#1 0xc01a72a4 in raise+0x24 () from /usr/lib/libc.2
#2 0xc01e85f8 in abort_C+0x160 () from /usr/lib/libc.2
#3 0xc01e8654 in abort+0x1c () from /usr/lib/libc.2
#4 0xc04d3a78 in terminate+0x38 () from /usr/lib/libCsup.2
#5 0xc04cd904 in TCompTechCleanupAutomaticLocal::DestructActiveObject
+0x80 () from /usr/lib/libCsup.2
#6 0xc04d131c in TExceptionActionCleanup::processThrow+0x24 () from /
usr/lib/libCsup.2
#7 0xc04d4010 in ThrowException+0x158 () from /usr/lib/libCsup.2
#8 0xc04d4478 in __throw__FPvT1+0x14c () from /usr/lib/libCsup.2
#9 0xd471f6e0 in
std::basic_string<char,std::char_traits<char>,std::allocator<char>>::eek:perator=
+0xb8 ()
from /appl/objectel/Objectel_2.9/bin/ObjectelCommands
#10 0xd41da7b0 in __ct__16SecurityServicesFPCcN21_2+0x478 () from /
appl/objectel/Objectel_2.9/bin/libAG2LIB.sl
#11 0xd38b04d4 in AgCServerSROP::UPSVerifyLoginInformation+0x114 ()
from /appl/objectel/Objectel_2.9/bin/libAG2SLIB.sl
#12 0xd38b2058 in AgCServerSROP::UPSPerformGetUserProfile+0x228 ()
from /appl/objectel/Objectel_2.9/bin/libAG2SLIB.sl
#13 0xd38af644 in AgCServerSROP::performLogin+0xb54 () from /appl/
objectel/Objectel_2.9/bin/libAG2SLIB.sl
#14 0xd391fef0 in AgpProcessSROPRequest+0x278 () from /appl/objectel/
Objectel_2.9/bin/libAG2SLIB.sl
#15 0xaeaa8 in singleUserThread+0x4a8 ()
#16 0xc005b2e4 in __pthread_body+0x44 () from /usr/lib/libpthread.1
#17 0xc0065574 in __pthread_start+0x14 () from /usr/lib/libpthread.1

This is happens because we use the string class from STL in our
library. This problem do not occorus where we do not use std::string.

We are compiling our code with the directive -AA and by using this
directive it implies the following:

-AA Turns on newly supported ANSI C++ Standard
features
like namespace std and the new C++ Standard
Library.
This option also implies -Aa. Include paths are
changed to include_std and libraries are
libCsup_v2 and
libstd_v2.
NOTE: Objects and libraries compiled with -AA are
binary incompatible with objects and libraries
compiled
without -AA.

As we could see the program uses the libCsup_v2 as well as the libCsup
libraries which are incompatible by -AA (we see that using ldd)

The lib libCsup comes from the xerces library.

We try recompiles the xerces library using +AA option and the gdb
backtrace stay like:
#0 0x680a6c68 in kill+0x10 () from /usr/lib/libc.2
#1 0x680412a4 in raise+0x24 () from /usr/lib/libc.2
#2 0x680825f8 in abort_C+0x160 () from /usr/lib/libc.2
#3 0x68082654 in abort+0x1c () from /usr/lib/libc.2
#4 0x651d2a78 in terminate+0x38 () from /usr/lib/libCsup.2
#5 0x651cceb0 in
TCompTechCleanupMemberInCtorDtor::DestructActiveObject+0x74 () from /
usr/lib/libCsup.2
#6 0x651d031c in TExceptionActionCleanup::processThrow+0x24 () from /
usr/lib/libCsup.2
#7 0x651d3010 in ThrowException+0x158 () from /usr/lib/libCsup.2
#8 0x651d3478 in __throw__FPvT1+0x14c () from /usr/lib/libCsup.2
#9 0xabc48 in
std::basic_string<char,std::char_traits<char>,std::allocator<char>>::_C_unlink
+0xb0 ()
#10 0x65698664 in SecurityServices::~SecurityServices+0x64 () from /
appl/objectel/Objectel_2.9/bin/libAG2LIB.sl
#11 0x651cc8ec in TCompTechCleanupAutomaticLocal::DestructActiveObject
+0x68 () from /usr/lib/libCsup.2
#12 0x651d031c in TExceptionActionCleanup::processThrow+0x24 () from /
usr/lib/libCsup.2
#13 0x651d3010 in ThrowException+0x158 () from /usr/lib/libCsup.2
#14 0x651d3478 in __throw__FPvT1+0x14c () from /usr/lib/libCsup.2
#15 0x6563f9b0 in
std::basic_string<char,std::char_traits<char>,std::allocator<char>>::basic_string<char,std::char_traits<char>,std::allocator<char>>
+0xc0 () from /appl/objectel/Objectel_2.9/bin/libAG2LIB.sl
#16 0x6569d14c in SecurityServices::SendRecvXML+0x9c () from /appl/
objectel/Objectel_2.9/bin/libAG2LIB.sl
#17 0x6569b134 in SecurityServices::GetBool+0xac () from /appl/
objectel/Objectel_2.9/bin/libAG2LIB.sl
#18 0x6569a37c in SecurityServices::AuthenticateUser+0x38c () from /
appl/objectel/Objectel_2.9/bin/libAG2LIB.sl
#19 0x657a74ec in AgCServerSROP::UPSVerifyLoginInformation+0x12c ()
from /appl/objectel/Objectel_2.9/bin/libAG2SLIB.sl
#20 0x657a9058 in AgCServerSROP::UPSPerformGetUserProfile+0x228 ()
from /appl/objectel/Objectel_2.9/bin/libAG2SLIB.sl
#21 0x657a6644 in AgCServerSROP::performLogin+0xb54 () from /appl/
objectel/Objectel_2.9/bin/libAG2SLIB.sl
#22 0x65816ef0 in AgpProcessSROPRequest+0x278 () from /appl/objectel/
Objectel_2.9/bin/libAG2SLIB.sl
#23 0xaeaa8 in singleUserThread+0x4a8 ()
#24 0x67b592e4 in __pthread_body+0x44 () from /usr/lib/libpthread.1
#25 0x67b63574 in __pthread_start+0x14 () from /usr/lib/libpthread.1

Do we have to recompile the program using the new libxerces, or are we
using a wrong compile option?
 
A

Andre Siqueira

We have a program, that was previous compiled by another people.
We develop a library that this program loads.

We have experience craches in this program. Looking at the gdb we
find:

#0 0xc020cc68 in kill+0x10 () from /usr/lib/libc.2
#1 0xc01a72a4 in raise+0x24 () from /usr/lib/libc.2
#2 0xc01e85f8 in abort_C+0x160 () from /usr/lib/libc.2
#3 0xc01e8654 in abort+0x1c () from /usr/lib/libc.2
#4 0xc04d3a78 in terminate+0x38 () from /usr/lib/libCsup.2
#5 0xc04cd904 in TCompTechCleanupAutomaticLocal::DestructActiveObject
+0x80 () from /usr/lib/libCsup.2
#6 0xc04d131c in TExceptionActionCleanup::processThrow+0x24 () from /
usr/lib/libCsup.2
#7 0xc04d4010 in ThrowException+0x158 () from /usr/lib/libCsup.2
#8 0xc04d4478 in __throw__FPvT1+0x14c () from /usr/lib/libCsup.2
#9 0xd471f6e0 in
std::basic_string<char,std::char_traits<char>,std::allocator<char>>::eek:perat­or=
+0xb8 ()
from /appl/objectel/Objectel_2.9/bin/ObjectelCommands
#10 0xd41da7b0 in __ct__16SecurityServicesFPCcN21_2+0x478 () from /
appl/objectel/Objectel_2.9/bin/libAG2LIB.sl
#11 0xd38b04d4 in AgCServerSROP::UPSVerifyLoginInformation+0x114 ()
from /appl/objectel/Objectel_2.9/bin/libAG2SLIB.sl
#12 0xd38b2058 in AgCServerSROP::UPSPerformGetUserProfile+0x228 ()
from /appl/objectel/Objectel_2.9/bin/libAG2SLIB.sl
#13 0xd38af644 in AgCServerSROP::performLogin+0xb54 () from /appl/
objectel/Objectel_2.9/bin/libAG2SLIB.sl
#14 0xd391fef0 in AgpProcessSROPRequest+0x278 () from /appl/objectel/
Objectel_2.9/bin/libAG2SLIB.sl
#15 0xaeaa8 in singleUserThread+0x4a8 ()
#16 0xc005b2e4 in __pthread_body+0x44 () from /usr/lib/libpthread.1
#17 0xc0065574 in __pthread_start+0x14 () from /usr/lib/libpthread.1

This is happens because we use the string class from STL in our
library. This problem do not occorus where we do not use std::string.

We are compiling our code with the directive -AA and by using this
directive it implies the following:

-AA Turns on newly supported ANSI C++ Standard
features
like namespace std and the new C++ Standard
Library.
This option also implies -Aa. Include paths are
changed to include_std and libraries are
libCsup_v2 and
libstd_v2.
NOTE: Objects and libraries compiled with -AA are
binary incompatible with objects and libraries
compiled
without -AA.

As we could see the program uses the libCsup_v2 as well as the libCsup
libraries which are incompatible by -AA (we see that using ldd)

The lib libCsup comes from the xerces library.

We try recompiles the xerces library using +AA option and the gdb
backtrace stay like:
#0 0x680a6c68 in kill+0x10 () from /usr/lib/libc.2
#1 0x680412a4 in raise+0x24 () from /usr/lib/libc.2
#2 0x680825f8 in abort_C+0x160 () from /usr/lib/libc.2
#3 0x68082654 in abort+0x1c () from /usr/lib/libc.2
#4 0x651d2a78 in terminate+0x38 () from /usr/lib/libCsup.2
#5 0x651cceb0 in
TCompTechCleanupMemberInCtorDtor::DestructActiveObject+0x74 () from /
usr/lib/libCsup.2
#6 0x651d031c in TExceptionActionCleanup::processThrow+0x24 () from /
usr/lib/libCsup.2
#7 0x651d3010 in ThrowException+0x158 () from /usr/lib/libCsup.2
#8 0x651d3478 in __throw__FPvT1+0x14c () from /usr/lib/libCsup.2
#9 0xabc48 in
std::basic_string<char,std::char_traits<char>,std::allocator<char>>::_C_unl­ink
+0xb0 ()
#10 0x65698664 in SecurityServices::~SecurityServices+0x64 () from /
appl/objectel/Objectel_2.9/bin/libAG2LIB.sl
#11 0x651cc8ec in TCompTechCleanupAutomaticLocal::DestructActiveObject
+0x68 () from /usr/lib/libCsup.2
#12 0x651d031c in TExceptionActionCleanup::processThrow+0x24 () from /
usr/lib/libCsup.2
#13 0x651d3010 in ThrowException+0x158 () from /usr/lib/libCsup.2
#14 0x651d3478 in __throw__FPvT1+0x14c () from /usr/lib/libCsup.2
#15 0x6563f9b0 in
std::basic_string<char,std::char_traits<char>,std::allocator<char>>::basic_­string<char,std::char_traits<char>,std::allocator<char>>
+0xc0 () from /appl/objectel/Objectel_2.9/bin/libAG2LIB.sl
#16 0x6569d14c in SecurityServices::SendRecvXML+0x9c () from /appl/
objectel/Objectel_2.9/bin/libAG2LIB.sl
#17 0x6569b134 in SecurityServices::GetBool+0xac () from /appl/
objectel/Objectel_2.9/bin/libAG2LIB.sl
#18 0x6569a37c in SecurityServices::AuthenticateUser+0x38c () from /
appl/objectel/Objectel_2.9/bin/libAG2LIB.sl
#19 0x657a74ec in AgCServerSROP::UPSVerifyLoginInformation+0x12c ()
from /appl/objectel/Objectel_2.9/bin/libAG2SLIB.sl
#20 0x657a9058 in AgCServerSROP::UPSPerformGetUserProfile+0x228 ()
from /appl/objectel/Objectel_2.9/bin/libAG2SLIB.sl
#21 0x657a6644 in AgCServerSROP::performLogin+0xb54 () from /appl/
objectel/Objectel_2.9/bin/libAG2SLIB.sl
#22 0x65816ef0 in AgpProcessSROPRequest+0x278 () from /appl/objectel/
Objectel_2.9/bin/libAG2SLIB.sl
#23 0xaeaa8 in singleUserThread+0x4a8 ()
#24 0x67b592e4 in __pthread_body+0x44 () from /usr/lib/libpthread.1
#25 0x67b63574 in __pthread_start+0x14 () from /usr/lib/libpthread.1

Do we have to recompile the program using the new libxerces, or are we
using a wrong compile option?

I was trying something here and I discovered that I can use string
with pointer like that:

std::string *test =new std::string("123456");
fprintf(stderr, "my test string = %s\n", test->c_str());

but I can not use like this:

std::string test;
test = "123456";
fprintf(stderr, "my test string = %s\n", test.c_str());

is there any problem with the default allocator?
 
P

Piyo

I have a feeling that the runtime c++ libraries of the application and
the library you are writing are different. If the ABI of the runtime C++
libraries are not compatible, weird crashes in pretty bullet-proof
templates (such as std::string) can occur easily.

For example, gcc3.4 and gcc3.3 have different ABIs for the runtime c++
libraries and thus cannot be mixed easily. Try using the same compiler
that was used to compile the application and see if it solves your problem.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,772
Messages
2,569,593
Members
45,111
Latest member
VetaMcRae
Top