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.

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?

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.

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();}

?

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().

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.

Is it possible for any of your destructors to throw?

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. ;)

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?