Jump to content
  • Advertisement
Sign in to follow this  
Chozo

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.

If you intended to correct an error in the post then please contact us.

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 this post


Link to post
Share on other sites
Advertisement
Quote:
Original post by Chozo
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?
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 this post


Link to post
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 this post


Link to post
Share on other sites
Quote:
Original post by Chozo
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.


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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
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 this post


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

Quote:

(gdb) break main
Breakpoint 1 at 0x805f819
(gdb) run --console
Starting 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) n
Program not restarted.
(gdb) cont
Continuing.

Catchpoint 2 (exception thrown)
__cxa_throw (obj=0x821052c, tinfo=0x82111e0, dest=0x82111e0 <typeinfo for ConfigurationException>) at /usr/local/src/gcc/gcc-3.2.2/libstdc++-v3/libsupc++/eh_throw.cc:59
59 /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.cc
Current language: auto; currently c++
(gdb) bt
#0 __cxa_throw (obj=0x821052c, tinfo=0x82111e0, dest=0x82111e0 <typeinfo for ConfigurationException>) 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 <abort>) 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 this post


Link to post
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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!