g++ exceptions

This topic is 4899 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

Recommended Posts

Not sure if this would be better in the Unix forum or not, but maybe others here have had this experience. We've got 3 binaries that we compile here. The first 2 compile and run just fine. They catch exceptions and so on just dandily. All 3 binaries share a common source base that is where the exceptions are thrown at. The third binary, when compiled, will always call terminate() when an exception is thrown (we explicitely do NOT use exception specifications to avoid the hassle they bring, and the stack trace shows no sign of an unexpected exception). We've even tried something like this: try { throw std::exception(); } catch(...) { } and terminate() is *still* called. We're pretty much at our wits end here. We can't figure out why the first 2 binaries work just fine and the third fails. As I said, they share a common source base and they use the same compile options. Is it a bug in gcc 3.3.x or am I maybe doing something wrong somewhere? We've also thrown on -fexceptions and -fno-enforce-eh-specs but to no avail. I appreciate any help ideas anyone might have.

Share on other sites
Quote:
 Original post by Chozotry {throw std::exception();} catch(...) {}and terminate() is *still* called. We're pretty much at our wits end here. We can't figure out why the first 2 binaries work just fine and the third fails. As I said, they share a common source base and they use the same compile options. Is it a bug in gcc 3.3.x or am I maybe doing something wrong somewhere?
It's always the compiler's fault isn't it? [wink]

If it's nothing but that above code, then I'd say compiler bug, but it's not nothing but the above code, is it?

Share on other sites
Of course not. :)
It's about 100,000 lines of code all mashed together to make a mess no one dares walk through. I suppose that's the only thing to do isn't it? Walk through it all one line at a time... ugh.

Share on other sites
Quote:
 Original post by ChozoOf course not. :)It's about 100,000 lines of code all mashed together to make a mess no one dares walk through. I suppose that's the only thing to do isn't it? Walk through it all one line at a time... ugh.

Better idea:

gdb ./mess_no_one_dares_walk_through...(gdb) break main...(gdb) run...(gdb) catch throw...(gdb) run...(gdb) bt...

It's possible that finding out the exact thrown exception will help you figure out what's going on... (edit: and that will at least get you to the part where the exception is being thrown) - just my 2 cents. Is it possible you have something like this in an inner branch of logic:

try{}catch(...){   terminate();}

?

Share on other sites
Are you using throw() specifiers somewhere? When an exception is thrown in a function with a throw specifier iirc. unexpected() is called, which by default calls terminate().

Share on other sites
We turned off exception specifications, just to make sure that wasn't it.

I'll try that gdb run through tomorrow and see what comes up. We've used a bt from the terminate() and we think that leads us back to the exception. Never know though (and it never hurts to try).

Thanks for the suggestions. If you've got any more, I'd love to hear them. This has been a heck of a confusing ordeal.

Share on other sites
Is it possible for any of your destructors to throw?

Share on other sites
There shouldn't be any. I can't guarantee it, but I'm pretty sure there aren't any. If there are... someone's in some trouble. ;)

Share on other sites
Here's the output of the gdb session:

Quote:
 (gdb) break mainBreakpoint 1 at 0x805f819(gdb) run --consoleStarting program: /soft/DEV/shane/bin/opodsrvr --console[Thread debugging using libthread_db enabled][New Thread 16384 (LWP 17972)][Switching to Thread 16384 (LWP 17972)] Breakpoint 1, 0x0805f819 in main ()(gdb) catch throw Catchpoint 2 (throw) (gdb) run The program being debugged has been started already.Start it from the beginning? (y or n) nProgram not restarted. (gdb) cont Continuing. Catchpoint 2 (exception thrown) __cxa_throw (obj=0x821052c, tinfo=0x82111e0, dest=0x82111e0 ) at /usr/local/src/gcc/gcc-3.2.2/libstdc++-v3/libsupc++/eh_throw.cc:5959 /usr/local/src/gcc/gcc-3.2.2/libstdc++-v3/libsupc++/eh_throw.cc: No such file or directory. in /usr/local/src/gcc/gcc-3.2.2/libstdc++-v3/libsupc++/eh_throw.ccCurrent language: auto; currently c++(gdb) bt #0 __cxa_throw (obj=0x821052c, tinfo=0x82111e0, dest=0x82111e0 ) at /usr/local/src/gcc/gcc-3.2.2/libstdc++-v3/libsupc++/eh_throw.cc:59#1 0x08191e34 in ApplicationSection::instanceSubNode(std::string) const ()#2 0x08182e4e in AppServerConfiguration::AppServerConfiguration(EnvironmentConfiguration const&, std::string) ()#3 0x08053654 in AppConfiguration::AppConfiguration(std::string) ()#4 0x08053c92 in AppConfiguration::init(std::string const&, std::string const&) ()#5 0x0805f8b5 in main () (gdb) cont Continuing. Program received signal SIGABRT, Aborted.0xb6cbf251 in kill () from /lib/libc.so.6(gdb) bt #0 0xb6cbf251 in kill () from /lib/libc.so.6#1 0xb6c4ccff in pthread_kill () from /lib/libpthread.so.0#2 0xb6c4d07a in raise () from /lib/libpthread.so.0#3 0xb6cbeff4 in raise () from /lib/libc.so.6#4 0xb6cc0393 in abort () from /lib/libc.so.6#5 0xb7a260c9 in __cxxabiv1::__terminate(void (*)()) (handler=0xb6cc02b8 ) at /usr/local/src/gcc/gcc-3.2.2/libstdc++-v3/libsupc++/eh_terminate.cc:47#6 0xb7a26103 in std::terminate() () at /usr/local/src/gcc/gcc-3.2.2/libstdc++-v3/libsupc++/eh_terminate.cc:57#7 0xb7a26230 in __cxa_throw (obj=0x82704a0, tinfo=0x0, dest=0) at /usr/local/src/gcc/gcc-3.2.2/libstdc++-v3/libsupc++/eh_throw.cc:77#8 0x08191e34 in ApplicationSection::instanceSubNode(std::string) const ()#9 0x08182e4e in AppServerConfiguration::AppServerConfiguration(EnvironmentConfiguration const&, std::string) ()#10 0x08053654 in AppConfiguration::AppConfiguration(std::string) ()#11 0x08053c92 in AppConfiguration::init(std::string const&, std::string const&) ()#12 0x0805f8b5 in main ()(gdb)

As you can see, it's not very helpful. The very first exception being thrown is the one that causes terminate() to be called. I'm not sure what the eh_throw.cc error is all about, but it's shown up on every version of g++ I've tried (and I've tried a lot of them). I did a quick grep on terminate just to be sure, but nothing came up. Is there anything else I could try?

Share on other sites
eh_throw.cc is a source file in the C++ Library. If you were to type 'up 7' to go back up to that frame, followed by 'list', it should show you the code where it decided to call terminate, which would probably give you an idea of why it was called in the first place.

1. 1
2. 2
Rutin
24
3. 3
4. 4
JoeJ
18
5. 5

• 14
• 19
• 11
• 11
• 9
• Forum Statistics

• Total Topics
631761
• Total Posts
3002178
×