CODEWITHSUNDEEP
c++exceptiong++shared-libraries
Sämy
Sämy

Reputation: 839

Exceptions across binary boundary

I know, this question has been asked quite some times, however I can't find a solution for my problem.

I have the following situation:

   A
  / \
 /   \
B <-- C

At some point C throws an instance of EException:

void doSometing() {
    throw EException("test-message");
}

in B I would like to catch this exception:

try {
    doSomething();
} catch (const EException& ex) {
    // Not reached
} catch (...) {
    // Not reached
}

but as mentioned in the code, neither one of the catch clauses get called. Instead the thread, this code is executed in, gets aborted.

I tried the following things:

Using nm I get for A:

0000000000066260 T EException::EException(QString const&)
0000000000066306 T EException::EException(EException const&)
00000000000661d0 T EException::EException() 
0000000000066260 T EException::EException(QString const&) 
0000000000066306 T EException::EException(EException const&) 
00000000000661d0 T EException::EException() 
00000000000664de T EException::~EException()
000000000006641e T EException::~EException() 
000000000006641e T EException::~EException() 
00000000000663b6 T EException::operator=(EException const&)
<...>
000000000028de40 V typeinfo for EException
000000000028dd80 V typeinfo for EException*
000000000007342b V typeinfo name for EException
0000000000072ab7 V typeinfo name for EException*
000000000028de00 V vtable for EException

for B:

U EException::EException(QString const&)
U EException::~EException()
<...>
0000000000726f60 V typeinfo for EException

and for C:

U EException::EException(QString const&)
U EException::~EException()
<...>
U typeinfo for EException

Could the problem be, that B uses its own typeinfo of EException, while C uses the one provided by A? How would I fix this?

My environment:

Thank you for your help!

Upvotes: 21

Views: 2212

Answers (5)

xryl669
xryl669

Reputation: 3584

IMHO, this as nothing to do with the compiler flags whatsoever.

Declare your exception object as extern and don't provide any implementation anywhere except in your main binary.

This will force the linker (dynamic linker BTW) to use the only implementation that's possible.

No typeinfo is generated on extern definition only.

Upvotes: 1

user1525342
user1525342

Reputation: 56

Check for

-fvisibility=hidden

option in your linker settings. If it set, change it to

-fvisibility=default

Upvotes: 1

neam
neam

Reputation: 934

You may try to compile A, B and C with -rdynamic (at linkage stage)

The GCC man page tell about -rdynamic:

Pass the flag -export-dynamic to the ELF linker, on targets that support it. This instructs the linker to add all symbols, not only used ones, to the dynamic symbol table. This option is needed for some uses of "dlopen" or to allow obtaining backtraces from within a program.

Upvotes: 0

Sascha
Sascha

Reputation: 1114

I had similar problems with gcc < 4.5 with RTTI symbols used across shared library boundaries, but not with gcc 4.6. However, you might still find the following information useful.

As already mentioned, the vtable (containing an entry to the typeinfo object) for EException seems to be duplicated in some translation units which was definitely a problem with gcc < 4.5 (well, it is an issue of libsupc++, as far as I know, not merging the type_info objects). Anchoring the vtable of EException by defining a virtual out-of-line destructor (it must be the first virtual function declaration in the header) in A did the trick for me.

Posting the complete header file for EException might also be helpful.

Upvotes: 3

Gold
Gold

Reputation: 136

B is using it's own EException class definition V typeinfo for EException whereas C seems to use an Unresolved one ( the U means the type is undefined in the current translation unit and must be resolved by the loader and dynamic linker ).

Verify that B is still a shared library and it is not linked statically whith A but dynamicaly, preventing C from findind A's stuffs, cause as I cant see B won't link the same type as A. Take care of your header ^^.

Upvotes: 0

Related Questions