Hi Eljay, Thanks for the help. Here's what's going on in my app. DSO A defines an exception class (EventBody) and a handle for it (TEventHandle). DSO B also happens to refer to this exception class and goes one step further by defining a derived exception class (UserExceptionBody). When I link these two DSOs with my main executable, if an EventBody object is thrown from DSO B, the program terminates instead of properly catching the exception. Like you said, this is probably caused by some kind of typeinfo mismatch. I can't seem to figure it out. This is the nm output for these symbols in DSO A: 00000000003519b0 V typeinfo for Execution::EventBody 000000000011c150 V typeinfo name for Execution::EventBody 0000000000351d80 V typeinfo for Execution::TEventHandle<Execution::EventBody> 000000000011cd20 V typeinfo name for Execution::TEventHandle<Execution::EventBody> This is the nm output for these symbols in DSO B: U typeinfo for Execution::EventBody U typeinfo for Execution::TEventHandle<Execution::EventBody> 00000000002e9150 V typeinfo for DOCF::UserExceptionBody 00000000000c79e0 V typeinfo name for DOCF::UserExceptionBody 00000000002e9200 V typeinfo for Execution::TEventHandle<DOCF::UserExceptionBody> 00000000000c7b80 V typeinfo name for Execution::TEventHandle<DOCF::UserExceptionBody> Finally, this is the nm output for these symbols from my main executable: 000000000062ab10 V typeinfo for DOCF::UserExceptionBody 000000000062a860 V typeinfo for Execution::TEventHandle<Execution::EventBody> NOTE: There is no typeinfo for the Execution::EventBody class found in the main executable. I presume this is the reason the terminate handler is called when the program tries to catch exceptions of this type (Execution::TEventHandle<Execution::EventBody>). I have explicitly instantiated the template class TEventHandle<Execution::EventBody> in DSO A where it was defined. I also explicitly instantiated template class TEventHandle<DOCF::UserExceptionBody> in DSO B where it was defined. I did this per Matthias's earlier instructions to avoid duplicate symbols. Btw, this application is all C++. There aren't any C barriers to deal with. It uses an awful lot of templates though, and there is certainly quite a bit of cross DSO dependency in the sense that DSO B is extending classes defined in DSO A. Can you spot anything from this that can explain why the terminate handler is called? If so perhaps you could recommend a way for me to better restructure to avoid these difficulties. Thanks a bunch, Dallas On Tue, May 18, 2010 at 6:33 AM, John (Eljay) Love-Jensen <eljay@xxxxxxxxx> wrote: > Hi Dallas, > >> In other words how does "typeinfo for" differ from "typeinfo name for"? > > The class type_info object has a char const* member called name. > > Type "typeinfo name for" is the nul-terminated C string referenced by that > typeinfo. > > You can access that name by: > > #include <typeinfo> > char const* name = typeid<Foo_t>.name(); > > The name generated varies from C++ compiler by vendor, and sometimes even by > version. If anonymous namespaces are involved, may vary by compile too. > >> I'm assuming this because the type is only defined in DSO A and should >> be undefined in DSO B as well as the executable. Is this >> understanding correct? > > That is a C++ compiler/linker implementation detail. > > For GCC, the RTTI uses vague linkage: > > http://gcc.gnu.org/onlinedocs/gcc/Vague-Linkage.html > > It is possible to get ODR violations under certain circumstances. :-( > > Visibility may bollix up the RTTI mechanism. In particular, if the typeinfo > data is hidden, then the vague linkage mechanism may not work as desired. > Resulting in typeid's not matching, and exceptions not being caught across > packages (.so) and/or with the main executable. > > Also with a shared library, you may need to pay attention to exception > handling through a C barrier. If C routines or OS calls (with callbacks) > are sandwiched on the stack, stack unwinding during exception handling may > fail, resulting in a terminate call. > > HTH, > --Eljay > >
