* RE: C++ exceptions @ 2013-11-20 12:49 vijay nag 2013-11-20 14:53 ` Marc Glisse 0 siblings, 1 reply; 10+ messages in thread From: vijay nag @ 2013-11-20 12:49 UTC (permalink / raw) To: gcc-help 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* RE: C++ exceptions 2013-11-20 12:49 C++ exceptions vijay nag @ 2013-11-20 14:53 ` Marc Glisse 2013-11-20 17:58 ` vijay nag 0 siblings, 1 reply; 10+ messages in thread From: Marc Glisse @ 2013-11-20 14:53 UTC (permalink / raw) To: vijay nag; +Cc: gcc-help 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: C++ exceptions 2013-11-20 14:53 ` Marc Glisse @ 2013-11-20 17:58 ` vijay nag 2013-11-20 17:59 ` Marc Glisse 2013-11-20 18:14 ` Jonathan Wakely 0 siblings, 2 replies; 10+ messages in thread From: vijay nag @ 2013-11-20 17:58 UTC (permalink / raw) To: gcc-help 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 ? ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: C++ exceptions 2013-11-20 17:58 ` vijay nag @ 2013-11-20 17:59 ` Marc Glisse 2013-11-20 18:14 ` Jonathan Wakely 1 sibling, 0 replies; 10+ messages in thread From: Marc Glisse @ 2013-11-20 17:59 UTC (permalink / raw) To: vijay nag; +Cc: gcc-help 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: C++ exceptions 2013-11-20 17:58 ` vijay nag 2013-11-20 17:59 ` Marc Glisse @ 2013-11-20 18:14 ` Jonathan Wakely 2013-11-21 10:23 ` vijay nag 1 sibling, 1 reply; 10+ messages in thread From: Jonathan Wakely @ 2013-11-20 18:14 UTC (permalink / raw) To: vijay nag; +Cc: gcc-help 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: C++ exceptions 2013-11-20 18:14 ` Jonathan Wakely @ 2013-11-21 10:23 ` vijay nag 2013-11-22 19:47 ` Ian Lance Taylor 0 siblings, 1 reply; 10+ messages in thread From: vijay nag @ 2013-11-21 10:23 UTC (permalink / raw) To: Jonathan Wakely; +Cc: gcc-help 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: C++ exceptions 2013-11-21 10:23 ` vijay nag @ 2013-11-22 19:47 ` Ian Lance Taylor 2013-11-23 16:40 ` vijay nag 0 siblings, 1 reply; 10+ messages in thread From: Ian Lance Taylor @ 2013-11-22 19:47 UTC (permalink / raw) To: vijay nag; +Cc: Jonathan Wakely, gcc-help 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: C++ exceptions 2013-11-22 19:47 ` Ian Lance Taylor @ 2013-11-23 16:40 ` vijay nag 2013-11-23 16:42 ` Jonathan Wakely 0 siblings, 1 reply; 10+ messages in thread From: vijay nag @ 2013-11-23 16:40 UTC (permalink / raw) To: Ian Lance Taylor; +Cc: Jonathan Wakely, gcc-help 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: C++ exceptions 2013-11-23 16:40 ` vijay nag @ 2013-11-23 16:42 ` Jonathan Wakely 2013-11-23 16:54 ` Jonathan Wakely 0 siblings, 1 reply; 10+ messages in thread From: Jonathan Wakely @ 2013-11-23 16:42 UTC (permalink / raw) To: vijay nag; +Cc: gcc-help 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: C++ exceptions 2013-11-23 16:42 ` Jonathan Wakely @ 2013-11-23 16:54 ` Jonathan Wakely 0 siblings, 0 replies; 10+ messages in thread From: Jonathan Wakely @ 2013-11-23 16:54 UTC (permalink / raw) To: vijay nag; +Cc: gcc-help On 23 November 2013 16:40, Jonathan Wakely wrote: > > If you'd using s/you'd/you're/ ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2013-11-23 16:42 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2013-11-20 12:49 C++ exceptions vijay nag 2013-11-20 14:53 ` Marc Glisse 2013-11-20 17:58 ` vijay nag 2013-11-20 17:59 ` Marc Glisse 2013-11-20 18:14 ` Jonathan Wakely 2013-11-21 10:23 ` vijay nag 2013-11-22 19:47 ` Ian Lance Taylor 2013-11-23 16:40 ` vijay nag 2013-11-23 16:42 ` Jonathan Wakely 2013-11-23 16:54 ` Jonathan Wakely
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).