On Wed, Nov 20, 2013 at 11:28 PM, Jonathan Wakely <jwakely.gcc@xxxxxxxxx> 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.
