Mixing exception handling libraries with non exception handling

Mixing exception handling libraries with non exception handling

[Barry Andrews]

Hi All,

I have a 3rd party library ( which I'll call X ) which I believe was 
compiled with exception handling disabled. Then I have my C++ library 
which does have exception handling. When I load the X library first into 
a process, then load my library in the same process, exception handling 
becomes disabled and the abort() function is called. from unwind-dc2.c 
if I try to throw an exception in my code. This only happens if I load 
the X library first. I don't have any control over the X library, i.e. I 
cannot recompile it.

Has anyone run into this before? Is there some compiler option in gcc or 
#define I should have to keep exception handling enabled when I load my 
library? It appears that this is some sort of runtime thing.

Many many thanks for any guidance!

-B

Re: Mixing exception handling libraries with non exception handling

[Andrew Haley]

Barry Andrews wrote:

> I have a 3rd party library ( which I'll call X ) which I believe was
> compiled with exception handling disabled. Then I have my C++ library
> which does have exception handling. When I load the X library first into
> a process, then load my library in the same process, exception handling
> becomes disabled and the abort() function is called. from unwind-dc2.c
> if I try to throw an exception in my code. This only happens if I load
> the X library first. I don't have any control over the X library, i.e. I
> cannot recompile it.
> 
> Has anyone run into this before? 

Yes.

> Is there some compiler option in gcc or
> #define I should have to keep exception handling enabled when I load my
> library?

No.

> It appears that this is some sort of runtime thing.

Yes.  Throwing an exception uses unwinder data which the runtime
library uses to unwind frames on the stack when an exception is
thrown.  No unwinder data and you can't throw an exception; it
can't be helped.

Andrew.

Re: Mixing exception handling libraries with non exception handling

[Andrew Haley]

Barry Andrews wrote:

> So, since it is a runtime thing, I would think I would be able to
> control this somehow when my library is loaded. Do you know how
> exception handling is turned off anyway? I mean... I can load another C
> library ( libc for example ) which obviously does not have exception
> handling and it doesn't interfere with my C++ exceptions.

Unwinder data for exceptions is generated by the compiler.

Depending on your platform, libc (or at least some of it) may
well be compiled with -fexceptions.  It should only matter if
a stack frame belonging to the C library is active on the stack
at the time the exception is thrown.  In other words, if you
throw from your code, and catch from your code, and no routine
in the library is in-between, exceptions should still work.

Andrew.

> Andrew Haley wrote:
>> Barry Andrews wrote:
>>
>>  
>>> I have a 3rd party library ( which I'll call X ) which I believe was
>>> compiled with exception handling disabled. Then I have my C++ library
>>> which does have exception handling. When I load the X library first into
>>> a process, then load my library in the same process, exception handling
>>> becomes disabled and the abort() function is called. from unwind-dc2.c
>>> if I try to throw an exception in my code. This only happens if I load
>>> the X library first. I don't have any control over the X library, i.e. I
>>> cannot recompile it.
>>>
>>> Has anyone run into this before?     
>>
>> Yes.
>>
>>  
>>> Is there some compiler option in gcc or
>>> #define I should have to keep exception handling enabled when I load my
>>> library?
>>>     
>>
>> No.
>>
>>  
>>> It appears that this is some sort of runtime thing.
>>>     
>>
>> Yes.  Throwing an exception uses unwinder data which the runtime
>> library uses to unwind frames on the stack when an exception is
>> thrown.  No unwinder data and you can't throw an exception; it
>> can't be helped.
>>
>> Andrew.
>>
>>   
> 
> 

Re: Mixing exception handling libraries with non exception handling

[Andrew Haley]

This top-posting is confusing the hell out of me.  Please stop.

Barry Andrews wrote:
> "Unwinder data for exceptions is generated by the compiler."
> 
> Right, so if the data is there how is it that it gets turned off? Is
> library X saying "Don't load any unwinder data from now on?"

No.

> "In other words, if you
> throw from your code, and catch from your code, and no routine
> in the library is in-between, exceptions should still work."
> 
> Are you saying this is always true? I'm certain there are no other calls
> in between.

Yes, it is always true AFAIAA.  The unwinder reads the data lazily,
so unless it actually finds a stack frame belonging to code that has
no unwinder data, that should have no effect.  The instant the unwinder
sees a frame that it can't unwind, it will abort: there is nothing
else it can do.

Note this: the abort is from within the unwinder, WHILE IT IS
TRYING TO UNWIND A ROUTINE WITH NO UNWINDER DATA.  So, you have
to try to find out why that is happening.

gdb is your friend here.

> Is there no work around for this? It seems so very strange to me.

Compile with -fexceptions.

Andrew.


> Andrew Haley wrote:
>> Barry Andrews wrote:
>>
>>  
>>> So, since it is a runtime thing, I would think I would be able to
>>> control this somehow when my library is loaded. Do you know how
>>> exception handling is turned off anyway? I mean... I can load another C
>>> library ( libc for example ) which obviously does not have exception
>>> handling and it doesn't interfere with my C++ exceptions.
>>>     
>>
>> Unwinder data for exceptions is generated by the compiler.
>>
>> Depending on your platform, libc (or at least some of it) may
>> well be compiled with -fexceptions.  It should only matter if
>> a stack frame belonging to the C library is active on the stack
>> at the time the exception is thrown.  In other words, if you
>> throw from your code, and catch from your code, and no routine
>> in the library is in-between, exceptions should still work.
>>
>> Andrew.
>>
>>  
>>> Andrew Haley wrote:
>>>    
>>>> Barry Andrews wrote:
>>>>
>>>>  
>>>>      
>>>>> I have a 3rd party library ( which I'll call X ) which I believe was
>>>>> compiled with exception handling disabled. Then I have my C++ library
>>>>> which does have exception handling. When I load the X library first
>>>>> into
>>>>> a process, then load my library in the same process, exception
>>>>> handling
>>>>> becomes disabled and the abort() function is called. from unwind-dc2.c
>>>>> if I try to throw an exception in my code. This only happens if I load
>>>>> the X library first. I don't have any control over the X library,
>>>>> i.e. I
>>>>> cannot recompile it.
>>>>>
>>>>> Has anyone run into this before?             
>>>> Yes.
>>>>
>>>>  
>>>>      
>>>>> Is there some compiler option in gcc or
>>>>> #define I should have to keep exception handling enabled when I
>>>>> load my
>>>>> library?
>>>>>             
>>>> No.
>>>>
>>>>  
>>>>      
>>>>> It appears that this is some sort of runtime thing.
>>>>>             
>>>> Yes.  Throwing an exception uses unwinder data which the runtime
>>>> library uses to unwind frames on the stack when an exception is
>>>> thrown.  No unwinder data and you can't throw an exception; it
>>>> can't be helped.
>>>>
>>>> Andrew.
>>>>
>>>>         
>>>     
>>
>>
>>   
> 
> 

Re: Mixing exception handling libraries with non exception handling

[Andrew Haley]

Barry Andrews wrote:
> Andrew Haley wrote:
>>
>> Yes, it is always true AFAIAA.  The unwinder reads the data lazily,
>> so unless it actually finds a stack frame belonging to code that has
>> no unwinder data, that should have no effect.  The instant the unwinder
>> sees a frame that it can't unwind, it will abort: there is nothing
>> else it can do.
>>
>> Note this: the abort is from within the unwinder, WHILE IT IS
>> TRYING TO UNWIND A ROUTINE WITH NO UNWINDER DATA.  So, you have
>> to try to find out why that is happening.
>>
>> gdb is your friend here.
>>   
> And that's why it aborts for me. There is no unwinder data at all. I'll
> keep digging, but there are lots of internals here to debug.

OK, so you have to look at a gdb backtrace to see which routine
with no unwinder data is being unwound.

>>> Is there no work around for this? It seems so very strange to me.
>>>     
>>
>> Compile with -fexceptions.
>>   
> Yeah, I have that. Doesn't help. Did it work for you?

Yes, always.

Andrew.

Re: Mixing exception handling libraries with non exception handling

[Ian Lance Taylor]

Andrew Haley <aph@redhat.com> writes:

>> Is there no work around for this? It seems so very strange to me.
>
> Compile with -fexceptions.

Or -funwind-tables.

Ian

Re: Mixing exception handling libraries with non exception handling

[Andrew Haley]

Barry Andrews wrote:
> Ian Lance Taylor wrote:
>> Andrew Haley <aph@redhat.com> writes:
>>
>>  
>>>> Is there no work around for this? It seems so very strange to me.
>>>>       
>>> Compile with -fexceptions.
>>>     
>>
>> Or -funwind-tables.
>>   
> Unfortunately neither flag helps. I think the only way is to rebuild
> library X.

Well, yes.  That's what we said: Compile with -fexceptions.  This means
Library X.

Andrew.

Re: Mixing exception handling libraries with non exception handling

[Ian Lance Taylor]

Barry Andrews <titanandrews@gmail.com> writes:

> Ian Lance Taylor wrote:
>> Andrew Haley <aph@redhat.com> writes:
>>
>>   
>>>> Is there no work around for this? It seems so very strange to me.
>>>>       
>>> Compile with -fexceptions.
>>>     
>>
>> Or -funwind-tables.
>>   
> Unfortunately neither flag helps. I think the only way is to rebuild
> library X.

Yes, one of those options is required while building library X.

Ian