RE: C++ exceptions

RE: C++ exceptions

[vijay nag]

Hello gcc,

I'm working on a big project consisting of both C && C++ libraries.
The shared binary created out of these two libraries seems to be
having trouble with the exceptions. Exception handler i.e catch() is
not being dispatched by libstdc++ for some reason and the program is
terminating with SIGABRT as a result of it. Static binary seems to be
catching exceptions without any issues.
Some amount of googling on this topic suggested me to use
"-fexceptions" compiler switch but it didn't have any affect. Since
static binary works even without "-fexceptions" I think the issue has
nothing to do with "-fexceptions" compiler switch.  Just before
sigabrt I see these lines being printed by libstdc++. How do I debug
this issue ?

"terminate called after throwing an instance of 'ORBEM_AS_NotFound'

0xffffe524 in __kernel_vsyscall ()
(gdb) bt
#0  0xffffe524 in __kernel_vsyscall ()
#1  0xb7d55a40 in __GI_raise (sig=sig@entry=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:56
#2  0xb7d57203 in __GI_abort () at abort.c:90
#3  0xb7f42195 in __gnu_cxx::__verbose_terminate_handler () at
../../../../../gcc/libstdc++-v3/libsupc++/vterminate.cc:95
#4  0xb7f3feb5 in __cxxabiv1::__terminate (handler=0xb7f42050
<__gnu_cxx::__verbose_terminate_handler()>) at
../../../../../gcc/libstdc++-v3/libsupc++/eh_terminate.cc:40
#5  0xb7f3fef2 in std::terminate () at
../../../../../gcc/libstdc++-v3/libsupc++/eh_terminate.cc:50
#6  0xb7f401ae in __cxxabiv1::__cxa_throw (obj=0x16887c70,
tinfo=0xc860434 <typeinfo for ORBEM_AS_NotFound>, dest=0x9cea50
<ORBEM_AS_NotFound::~ORBEM_AS_NotFound()>)
    at ../../../../../gcc/libstdc++-v3/libsupc++/eh_throw.cc:83
#7  0x009a6145 in Config_Manager::Get_Client
(this=this@entry=0x168e8750, asId=...) at
orbs/server/Config_Manager.cpp:421
#8  0x009a6500 in Config_Manager::Add_Mod_Client (this=0x168e8750,
asId=..., asPasswd=...) at orbs/server/Config_Manager.cpp:514
#9  0x009af26a in set_config (orbs_data=orbs_data@entry=0x168b3ca8,
config_req=config_req@entry=0x16b42148, rsp=rsp@entry=0xbfffd0f8) at
orbs/server/ORBEM_Server.cpp:1248
#10 0x009b0685 in orbs_config_req_handler (h=0x16875f60,
data=0x168b3ca8) at orbs/orbs.cpp:821

RE: C++ exceptions

[Marc Glisse]

On Wed, 20 Nov 2013, vijay nag wrote:

> Hello gcc,
>
> I'm working on a big project consisting of both C && C++ libraries.
> The shared binary created out of these two libraries seems to be
> having trouble with the exceptions. Exception handler i.e catch() is
> not being dispatched by libstdc++ for some reason and the program is
> terminating with SIGABRT as a result of it. Static binary seems to be
> catching exceptions without any issues.
> Some amount of googling on this topic suggested me to use
> "-fexceptions" compiler switch but it didn't have any affect. Since
> static binary works even without "-fexceptions" I think the issue has
> nothing to do with "-fexceptions" compiler switch.  Just before
> sigabrt I see these lines being printed by libstdc++. How do I debug
> this issue ?
>
> "terminate called after throwing an instance of 'ORBEM_AS_NotFound'

Are you running on Solaris (or maybe a BSD)? Does LD_PRELOAD=libgcc_s.so.1 
(or maybe LD_PRELOAD=/path/to/libgcc_s.so.1) help?

-- 
Marc Glisse

Re: C++ exceptions

[vijay nag]

On Wed, Nov 20, 2013 at 6:19 PM, Marc Glisse <marc.glisse@inria.fr> wrote:
> On Wed, 20 Nov 2013, vijay nag wrote:
>
>> Hello gcc,
>>
>> I'm working on a big project consisting of both C && C++ libraries.
>> The shared binary created out of these two libraries seems to be
>> having trouble with the exceptions. Exception handler i.e catch() is
>> not being dispatched by libstdc++ for some reason and the program is
>> terminating with SIGABRT as a result of it. Static binary seems to be
>> catching exceptions without any issues.
>> Some amount of googling on this topic suggested me to use
>> "-fexceptions" compiler switch but it didn't have any affect. Since
>> static binary works even without "-fexceptions" I think the issue has
>> nothing to do with "-fexceptions" compiler switch.  Just before
>> sigabrt I see these lines being printed by libstdc++. How do I debug
>> this issue ?
>>
>> "terminate called after throwing an instance of 'ORBEM_AS_NotFound'
>
>
> Are you running on Solaris (or maybe a BSD)? Does LD_PRELOAD=libgcc_s.so.1
> (or maybe LD_PRELOAD=/path/to/libgcc_s.so.1) help?
>
> --
> Marc Glisse

Nope Im running a variant of debian linux i686 kernel. Does GCC pick
libgcc from GCC_EXEC_PREFIX ?  I am running the program in complete
chroot encironment so that libraries donot collide with host machine.
Are you telling me that Issue is because of wrong version of libgcc ?

Re: C++ exceptions

[Marc Glisse]

On Wed, 20 Nov 2013, vijay nag wrote:

> On Wed, Nov 20, 2013 at 6:19 PM, Marc Glisse <marc.glisse@inria.fr> wrote:
>> On Wed, 20 Nov 2013, vijay nag wrote:
>>
>>> Hello gcc,
>>>
>>> I'm working on a big project consisting of both C && C++ libraries.
>>> The shared binary created out of these two libraries seems to be
>>> having trouble with the exceptions. Exception handler i.e catch() is
>>> not being dispatched by libstdc++ for some reason and the program is
>>> terminating with SIGABRT as a result of it. Static binary seems to be
>>> catching exceptions without any issues.
>>> Some amount of googling on this topic suggested me to use
>>> "-fexceptions" compiler switch but it didn't have any affect. Since
>>> static binary works even without "-fexceptions" I think the issue has
>>> nothing to do with "-fexceptions" compiler switch.  Just before
>>> sigabrt I see these lines being printed by libstdc++. How do I debug
>>> this issue ?
>>>
>>> "terminate called after throwing an instance of 'ORBEM_AS_NotFound'
>>
>>
>> Are you running on Solaris (or maybe a BSD)? Does LD_PRELOAD=libgcc_s.so.1
>> (or maybe LD_PRELOAD=/path/to/libgcc_s.so.1) help?
>>
>> --
>> Marc Glisse
>
> Nope Im running a variant of debian linux i686 kernel. Does GCC pick
> libgcc from GCC_EXEC_PREFIX ?

At runtime, it uses RPATH or /etc/ld.so.conf.

> I am running the program in complete
> chroot encironment so that libraries donot collide with host machine.
> Are you telling me that Issue is because of wrong version of libgcc ?

Probably not. I only asked because a common issue on solaris is that both 
libc and libgcc_s provide exception routines, and if not all routines are 
taken from the same library, bad things happen.

The first thing you need to do is reduce your testcase. Can it show the 
issue with a single shared lib? With none? Does any try-throw-catch fail 
this way or only some? That will give you more information about the 
issue, and once the test is small enough, you can consider using a 
debugger to follow what is going on.


------

Wait, are you throwing from a destructor? Those are noexcept by default 
nowadays, which would cause a call to std::terminate. Specify 
noexcept(false) on it if you insist.

-- 
Marc Glisse

Re: C++ exceptions

[Jonathan Wakely]

On 20 November 2013 17:43, vijay nag wrote:
>
> Nope Im running a variant of debian linux i686 kernel. Does GCC pick
> libgcc from GCC_EXEC_PREFIX ?  I am running the program in complete
> chroot encironment so that libraries donot collide with host machine.
> Are you telling me that Issue is because of wrong version of libgcc ?

It's not possible to say, because you've still provided almost no
information.  How are you building the libraries? What flags are you
using to compile and link?

Is the exception thrown from one of the libraries? Is the catch in a
library or the main program?

Have you tried a simple example that just has a single function in a
single shared library that throws an exception?  If not, why not?

Without most of this information we're just guessing randomly what the
problem might be.

Re: C++ exceptions

[vijay nag]

On Wed, Nov 20, 2013 at 11:28 PM, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
> On 20 November 2013 17:43, vijay nag wrote:
>>
>> Nope Im running a variant of debian linux i686 kernel. Does GCC pick
>> libgcc from GCC_EXEC_PREFIX ?  I am running the program in complete
>> chroot encironment so that libraries donot collide with host machine.
>> Are you telling me that Issue is because of wrong version of libgcc ?
>
> It's not possible to say, because you've still provided almost no
> information.  How are you building the libraries? What flags are you
> using to compile and link?
>
> Is the exception thrown from one of the libraries? Is the catch in a
> library or the main program?
>
> Have you tried a simple example that just has a single function in a
> single shared library that throws an exception?  If not, why not?
>
> Without most of this information we're just guessing randomly what the
> problem might be.

I tried creating a small binary to demonstrate the problem that I had
been facing with my gcc-4.7.2 tool chain and glibc-2.17. The library
and binaries were created using exact CFLAGS, CXXFLAGS et al.
Strangely, the problem doesn't manifest in my example program :(.  On
further hacking and debugging libgcc, I found that
_Unwind_RaiseException() was always "returning" in failure case with
return code _URC_END_OF_STACK.  Does it mean that FDE is missing for
the function which is suppose to catch the exception ? How do I check
if an FDE exists for a particular function or not ?

"Wait, are you throwing from a destructor? Those are noexcept by
default nowadays, which would cause a call to std::terminate. Specify
noexcept(false) on it if you insist."

>>> I don't think Im throwing exception from a destructor and by the way Try/Catch is not working even for POD types.

Re: C++ exceptions

[Ian Lance Taylor]

On Thu, Nov 21, 2013 at 1:20 AM, vijay nag <vijunag@gmail.com> wrote:
>
> I tried creating a small binary to demonstrate the problem that I had
> been facing with my gcc-4.7.2 tool chain and glibc-2.17. The library
> and binaries were created using exact CFLAGS, CXXFLAGS et al.
> Strangely, the problem doesn't manifest in my example program :(.  On
> further hacking and debugging libgcc, I found that
> _Unwind_RaiseException() was always "returning" in failure case with
> return code _URC_END_OF_STACK.  Does it mean that FDE is missing for
> the function which is suppose to catch the exception ? How do I check
> if an FDE exists for a particular function or not ?

You can use readelf --debug=frames to examine the unwind information
in an executable or object file.

Ian

Re: C++ exceptions

[vijay nag]

On Sat, Nov 23, 2013 at 1:10 AM, Ian Lance Taylor <iant@google.com> wrote:
> On Thu, Nov 21, 2013 at 1:20 AM, vijay nag <vijunag@gmail.com> wrote:
>>
>> I tried creating a small binary to demonstrate the problem that I had
>> been facing with my gcc-4.7.2 tool chain and glibc-2.17. The library
>> and binaries were created using exact CFLAGS, CXXFLAGS et al.
>> Strangely, the problem doesn't manifest in my example program :(.  On
>> further hacking and debugging libgcc, I found that
>> _Unwind_RaiseException() was always "returning" in failure case with
>> return code _URC_END_OF_STACK.  Does it mean that FDE is missing for
>> the function which is suppose to catch the exception ? How do I check
>> if an FDE exists for a particular function or not ?
>
> You can use readelf --debug=frames to examine the unwind information
> in an executable or object file.
>
> Ian

Ok I found the problem. There seems to exist stack similar stack
unwind definition in glibc as well and linker was picking definitions
from libc rather than from libgcc_s.so since libc was first in the
default link order although I don't understand why linker is not
throwing multiple definition error.

Back-trace at libgcc/unwind in a normal working application was

(gdb) bt
#0  _Unwind_Find_FDE (pc=0xb7eb47f8 <_Unwind_RaiseException+56>,
bases=0xbffff174) at ../../../../gcc/libgcc/unwind-dw2-fde-dip.c:451
#1  0xb7eb3e21 in uw_frame_state_for
(context=context@entry=0xbffff120, fs=fs@entry=0xbffff010) at
../../../../gcc/libgcc/unwind-dw2.c:1179
#2  0xb7eb4362 in uw_init_context_1 (context=context@entry=0xbffff120,
outer_cfa=outer_cfa@entry=0xbffff300,
    outer_ra=0xb7f40201 <__cxxabiv1::__cxa_throw(void*,
std::type_info*, void (*)(void*))+97>) at
../../../../gcc/libgcc/unwind-dw2.c:1500
#3  0xb7eb47f9 in _Unwind_RaiseException (exc=0x52048) at
../../../../gcc/libgcc/unwind.inc:88
#4  0xb7f40201 in __cxxabiv1::__cxa_throw (obj=0x52068, tinfo=0x51780
<_ZTIi@@CXXABI_1.3>, dest=0x0) at
../../../../../gcc/libstdc++-v3/libsupc++/eh_throw.cc:78
#5  0x00048d41 in PrintException () at exception/Exception.cpp:26
#6  0x00048ce0 in main () at exception/main.c:27
(gdb)


and Back-trace at glibc/unwind in a non-working application

(gdb) bt
#0  _Unwind_Find_FDE (pc=0xb7d217f8 <_Unwind_RaiseException+56>,
bases=0xbfffb8d4) at ../sysdeps/generic/unwind-dw2-fde-glibc.c:253
#1  0xb7d20e21 in uw_frame_state_for
(context=context@entry=0xbfffb880, fs=fs@entry=0xbfffb770) at
../../../../gcc/libgcc/unwind-dw2.c:1179
#2  0xb7d21362 in uw_init_context_1 (context=context@entry=0xbfffb880,
outer_cfa=outer_cfa@entry=0xbfffba60,
    outer_ra=0xb7f40201 <__cxxabiv1::__cxa_throw(void*,
std::type_info*, void (*)(void*))+97>) at
../../../../gcc/libgcc/unwind-dw2.c:1500
#3  0xb7d217f9 in _Unwind_RaiseException (exc=0x172a3bd0) at
../../../../gcc/libgcc/unwind.inc:88
#4  0xb7f40201 in __cxxabiv1::__cxa_throw (obj=0x172a3bf0,
tinfo=0x151ea200 <_ZTIi@@CXXABI_1.3>, dest=0x0) at
../../../../../gcc/libstdc++-v3/libsupc++/eh_throw.cc:78


So I had to explicitly specify this order "-Wl,--start-group -lgcc_s
-lgcc -lc -Wl,--end-group" in linker command line arguments to pick-up
definitions from libgcc_s.so rather than from libc.

Re: C++ exceptions

[Jonathan Wakely]

On 23 November 2013 16:11, vijay nag wrote:
> Ok I found the problem. There seems to exist stack similar stack
> unwind definition in glibc as well and linker was picking definitions
> from libc rather than from libgcc_s.so since libc was first in the
> default link order although I don't understand why linker is not
> throwing multiple definition error.

Because the first definition that is found gets used, that's how
shared libraries work.


> So I had to explicitly specify this order "-Wl,--start-group -lgcc_s
> -lgcc -lc -Wl,--end-group" in linker command line arguments to pick-up
> definitions from libgcc_s.so rather than from libc.

If you'd using ld to link then it's your job to get the command right.
If you use gcc to link then it should get it right automatically.

I've asked twice what commands you're using to compile and link, but
you won't provide that information for some reason.

Re: C++ exceptions

[Jonathan Wakely]

On 23 November 2013 16:40, Jonathan Wakely wrote:
>
> If you'd using

s/you'd/you're/