Does the stack get unwound (destructors run) when a SIGABRT occurs in C++?
Thanks.
No:
$ cat test.cc
#include <iostream>
#include <sys/types.h>
#include <signal.h>
class Test {
public:
~Test() { std::cout << "~Test called" << std::endl; }
};
int main(int argc, char *argv[])
{
Test t = Test();
if (argc > 1) {
kill(0, SIGABRT);
}
return 0;
}
$ g++ test.cc
$ ./a.out
~Test called
$ ./a.out 1
Aborted
This answer indicates that destructors aren't called.
No, only exceptions trigger stack unwinding. Signals are part of POSIX, which is a C API, so it's not "aware of" C++ facilities such as exceptions.
The signal(3) man page on my Mac OS X box says
No Name Default Action Description
...
6 SIGABRT create core image abort program (formerly SIGIOT)
which suggests to me that the default is to not unwind...
the signal SIGABRT is used for making core file of running application some time. We some time use this signal to debug application. And as far as I know Destructors are not called by this signal.
Related
Here is a minimum example:
[joel#maison various] (master *)$ cat throw.cpp
#include <iostream>
int main(int argc, char* argv[])
{
throw("pouet pouet");
}
[joel#maison various] (master *)$ ./a.out
terminate called after throwing an instance of 'char const*'
Aborted (core dumped)
Reading the docs, it seems like the default terminate handler is abort(). I couldn't find anything about triggering a segfault in the abort man page.
Throwing an exception and not handling it calls abort() which raises SIGABRT.
You can verify it with the following
#include <iostream>
#include <stdexcept>
#include <signal.h>
extern "C" void handle_sigabrt(int)
{
std::cout << "Handling and then returning (exiting)" << std::endl;
}
int main()
{
signal(SIGABRT, &handle_sigabrt);
throw("pouet pouet");
}
Demo
I have written very simple program and expected to crash, and it crashes. Now, I have set terminate function, but it will not be called and program just crashed without calling this function.
I have test program both inside debugger/outside debugger, built in both debug/release mode, but showing same behaviour (at least no calling my terminate function). I am musing VS 2012 and Windows 10.
void func()
{
cout<<"Aah you threw exception"<<endl;
}
int main(int argc, char* argv[])
{
set_terminate(func); //setting terminate function
int *p = NULL;
*p =11;
cout<<*p; //this will throw exception
}
C++ is not Java! A signal (or trap) can be generated by dereferencing a nullptr, but it is not automatically translated in C++ exception. On a POSIX compliant system, you can try to use the signal function to catch a signal as proposed by Throwaway Account 3 Million. On Windows, you can try to use the C structured exception handling.
If you don't, and still generate such a trap, the standard just defines that as an Undefined Behaviour, and it commonly just abort the program immediately, bypassing any set_terminate, atexit or whatever function you planned to be call on a controlled termination of your program.
Use signal to catch segmentation errors:
#include <iostream>
#include <signal.h>
using namespace std;
void func(int signal) {
cerr << "Caught signal " << signal << endl;
}
int main() {
signal(SIGSEGV, func);
void (*p)() = NULL;
p();
}
Why is no unhandled exception exception given by VS 2013, or any abort signal raised when the following code is executed?
#include <thread>
void f1()
{
throw(1);
}
int main(int argc, char* argv[])
{
std::thread(f1);
}
The C++ standard states that std::terminate should be called in the following situation:
when the exception handling mechanism cannot find a handler for a thrown exception (15.5.1)
in such cases, std::terminate() is called (15.5.2)
The problem is that in this code, main() could end before the spawned thread (f1).
Try this instead:
#include <thread>
void f1()
{
throw(1);
}
int main(int argc, char* argv[])
{
std::thread t(f1);
t.join(); // wait for the thread to terminate
}
This call terminate() on Coliru (gcc).
Unfortunately Visual Studio 2013 will call directly abort() instead of terminate() (in my tests at least) when encountering this so even adding a handler (using std::set_handler() ) will apparently not work.
I reported this to the VS team.
Still, this code will trigger an error, while your initial code is not garanteed to.
I'm just trying a few of the new C++11 features with GCC 4.7.2, though when I go to run a seg fault occurs.
$ ./a.out
Message from main.
terminate called after throwing an instance of 'std::system_error'
what(): Unknown error -1
Aborted (core dumped)
I compiled with the 'beta' features of GCC, in regards to c++0x with:
g++ -std=c++11 c11.cpp
The code:
#include <future>
#include <iostream>
void called_from_async() {
std::cout << "Async call" << std::endl;
}
int main() {
//called_from_async launched in a separate thread if possible
std::future<void> result( std::async(called_from_async));
std::cout << "Message from main." << std::endl;
//ensure that called_from_async is launched synchronously
//if it wasn't already launched
result.get();
return 0;
}
I believe this happens because you have forgot to link with POSIX threads library. Just add -pthread or -lpthread to the g++ flags and the problem should go away.
If you are interested in details, this happens because C++11 runtime is resolving symbols from pthread in run-time only if you happen to use those features. So if you forgot to link, the runtime won't be able to resolve those symbols, treat your environment as if it doesn't support threads, and throw exception (which you don't catch and it aborts your application).
I'm trying to use boost::exception and have condensed my prototype code down to the example in the Boost exception tutorial however when running the code with the BOOST_THROW_EXCEPTION macro I get an abort from the program.
#include <iostream>
#include <boost/exception/all.hpp>
typedef boost::error_info<struct tag_my_info,int> my_info;
struct my_error: virtual boost::exception, virtual std::exception { };
void f() {
BOOST_THROW_EXCEPTION(my_error() << my_info(42));
// Uncomment the below (and comment the above) for the program to work
//throw my_error() << my_info(42);
}
int main(int argc, char** argv) {
try {
f();
}
catch(my_error& x) {
if(int const* mi = boost::get_error_info<my_info>(x)) {
std::cout << "My info: " << *mi << std::endl;
}
}
return 0;
}
Running the code with the BOOST_THROW_EXCEPTION macro:
$ ./a.out
Abort trap
If as the comment says, I swap the code, all is well
$ ./a.out
My info: 42
Below is the output from the g++ preprocessor for f()
void f() {
::boost::exception_detail::throw_exception_(my_error() << my_info(42),__PRETTY_FUNCTION__,"main.cpp",14);
}
Software versions are:
$ g++ -v
Using built-in specs.
Target: x86_64-apple-darwin10
Thread model: posix
gcc version 4.4.6 (GCC)
$ port list boost
boost #1.47.0 devel/boost
I'm on OSX SL using the tools provided by MacPorts. I've double checked the g++ search paths and there's only one copy of the boost hpp files and that's the ones that belong to the aforementioned boost package.
I have no idea why the abort trap is being called. I admit I'm newish to C++ .
The problem was caused by using the MacPorts version of g++. There are plenty of tickets related to exceptions and Abort Traps in the MP system (and plenty of examples on Google).
Using the version of g++ that comes with XCode enabled this problem to go away.