1

In cppreference abort, we have

Destructors of variables with automatic, thread local and static storage durations are not called. Functions passed to std::atexit() are also not called. Whether open resources such as files are closed is implementation defined.

I'm bit confused about the terminology and contradiction of the abort term that "closes" my program and from the description of that function which it says that destructors and open resources possibly are not called/closed, respectively. So, is it possible that my program remains running and it has some memory leak or resources still opened after a call to abort()?

Community
  • 1
  • 1
  • Might not be an exact dupe, but could help understand: http://stackoverflow.com/questions/397075/what-is-the-difference-between-exit-and-abort – Tas Apr 26 '16 at 23:18
  • 1
    The program can't both abort and remain running, that's a contradiction. Since it doesn't exist after it aborted, it can't be leaking memory either -- that's relevant during runtime. What could potentially happen is other external resources not being cleaned up properly (like temporary files, etc.) – Dan Mašek Apr 26 '16 at 23:18
  • @DanMašek: re "Since it doesn't exist after it aborted, it can't be leaking memory either", there's no connection from premise to conclusion, sorry. Still with modern OSes for general computers, memory is generally reclaimed. – Cheers and hth. - Alf Apr 26 '16 at 23:24
  • In C++ you should preferably use `std::terminate` which calls `abort` for you. http://stackoverflow.com/a/36854092/464581 – Cheers and hth. - Alf Apr 26 '16 at 23:26
  • @DanMašek I know that contradiction, but sometimes, some programs throw an error, "closes" apparently but its process is still opened and we have to kill it from task manager... So I imagined that approaches... –  Apr 26 '16 at 23:33

3 Answers3

2

Functions passed to std::atexit() are also not called. Whether open resources such as files are closed is implementation defined.

This means the implementation gets to decide what happens. On any common consumer operating system, most objects associated with your process get destroyed when your process exits. That means you won't leak memory that was allocated with new, for example, or open files.

There might be uncommon kinds of objects that aren't freed - for example, if you have a shared memory block, it might stay around in case another process tries to access it. Or if you created a temporary file, intending to delete it later, now the file will stay there because your program isn't around to delete it.

user253751
  • 57,427
  • 7
  • 48
  • 90
2

It's like killing a person. They won't have a chance to pay any outstanding bills, organize their heritage, clean their apartment, etc.

Whether any of this happens is up to their relatives or other third parties.

So, usually things like open files will be closed and no memory will be leaked because the OS takes care of this (like when the police or so will empty the apartment). There are some platforms where this won't happen, such as 16 bit windows or embedded systems, but under modern windows or Linux systems it will be okay.

However, what definitely won't happen is that destructors are run. This would be like having the to-be-killed person write a last entry into their diary and seal it or something - only the person itself knows how to do it, and they can't when you kill them without warning. So if anything important was supposed to happen in a destructor, it can be problematic, but usually not dramatically - it might be something like that the program created a Temporary file somewhere and would normally delete it on exiting, and now it can't and the file stays.

Still, your program will be closed and not running anymore. It just won't get a chance to clean up things and is therefore depending on the OS to do the right thing and clean up the resources used by it.

CherryDT
  • 25,571
  • 5
  • 49
  • 74
  • Damn, this answer clarified all for me... The others too. Thanks for all! –  Apr 26 '16 at 23:41
1

On Unix, calling abort() effectively delivers a SIGABRT signal to your process. The default behavior of the kernel when that signal is delivered is to close down your process, possibly leaving behind a core file, and closing any descriptors. Your process's thread of control is completely removed. Note that this all happens outside any notion of c++ (or any other language). That is why it is considered implementation defined.

If you wish to change the default behavior, you would need to install a signal handler to catch the SIGABRT.

jbruni
  • 1,238
  • 8
  • 12