This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: terminate called after throwing an exception from a shared library


Hello Eljay et al,

I have to confess that I feel very stupid.  This problem with the
terminate handler being unexpectedly called was caused by just one
overlooked destructor throwing an exception.  I am ashamed to admit
it. :(

However, the good news is that we can all rejoice that the gcc
compiler, linker, and loader are working very well with a complex C++
application, that uses all sorts of static libraries, dynamic shared
objects, and templates galore.

Thank you for your patience and help.

Embarrassed,

Dallas

On Wed, May 19, 2010 at 8:19 AM, Dallas Clement
<dallas.a.clement@gmail.com> wrote:
> Hello Eljay,
>
>> I am surprised that DSO C (RPC) does not have the typeinfo defined.
>
> Yes this is indeed a mystery. ?I do not see any difference between DSO
> B and DSO C in terms of how they throw a TEventHandle<EventBody>
> object.
>
> I tried adding the dummy instantiation routine to both DSO C as well
> as RPC main. ?This is a great idea. ?Surprisingly, the symbols still
> show up undefined. ?I'll keep at it today to see if I can find another
> way to get the compiler to emit weak vs undefined symbols.
>
> Thanks again for all the helpful advice.
>
> Regards,
> Dallas
>
> On Wed, May 19, 2010 at 7:03 AM, John (Eljay) Love-Jensen
> <eljay@adobe.com> wrote:
>> Hi Dallas,
>>
>>> If DSO C is throwing this exception but it's symbol is undefined,
>>> could that be the problem?
>>
>> I am surprised that DSO C (RPC) does not have the typeinfo defined.
>>
>> Look at the *.o files for the DSO C (RPC) to see which one(s) have those
>> undefined symbols.
>>
>> Then look carefully at the .cpp code for the .o file(s) to see what it is
>> doing. ?Perhaps the code is only dealing with pointers or references.
>> Perhaps the code has forward declarations of those things.
>>
>>> Any advice on how I can do this [kluge]? ?This problem was happening even
>>> when I was using inline / auto template instantiation vs. explicit.
>>
>> In your main application:
>>
>> extern void DummyRoutineToForceInstantiateTypeinfo(int i);
>> void DummyRoutineToForceInstantiateTypeinfo(int i)
>> {
>> ?if (i == 1) throw Execution::EventBody();
>> ?if (i == 2) throw DOCF::UserExceptionBody();
>> ?if (i == 3) throw Execution::TEventHandle<Execution::EventBody>();
>> ?if (i == 4) throw Execution::TEventHandle<DOCF::UserExceptionBody>();
>> }
>>
>> I think that will cause the compiler to emit the desired typeinfo into your
>> main executable.
>>
>>> Thanks again for all the help!
>>
>> No problem. ?:-) ?Namaste.
>>
>> Sincerely,
>> --Eljay
>>
>>
>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]