When does a process get SIGABRT (signal 6)?

I will give my answer from a competitive programming(cp) perspective, but it applies to other domains as well.

Many a times while doing cp, constraints are quite large.

For example : I had a question with a variables N, M, Q such that 1 ≤ N, M, Q < 10^5.

The mistake I was making was I declared a 2D integer array of size 10000 x 10000 in C++ and struggled with the SIGABRT error at Codechef for almost 2 days.

Now, if we calculate :

Typical size of an integer : 4 bytes

No. of cells in our array : 10000 x 10000

Total size (in bytes) : 400000000 bytes = 4*10^8 ≈ 400 MB

Your solutions to such questions will work on your PC(not always) as it can afford this size.

But the resources at coding sites(online judges) is limited to few KBs.

Hence, the SIGABRT error and other such errors.

Conclusion:

In such questions, we ought not to declare an array or vector or any other DS of this size, but our task is to make our algorithm such efficient that it works without them(DS) or with less memory.

PS : There might be other reasons for this error; above was one of them.

As "@sarnold", aptly pointed out, any process can send signal to any other process, hence, one process can send SIGABORT to other process & in that case the receiving process is unable to distinguish whether its coming because of its own tweaking of memory etc, or someone else has "unicastly", send to it.

In one of the systems I worked there is one deadlock detector which actually detects if process is coming out of some task by giving heart beat or not. If not, then it declares the process is in deadlock state and sends SIGABORT to it.

I just wanted to share this prospective with reference to question asked.

Regarding the first question: What are the scenarios where a process gets a SIGABRT in C++?

I can think of two special cases where a C++ program is aborted automatically -- not by directly calling std::abort() or std::terminate():

One: Throw an exception while an exception is being handled.

try {
    throw "abc";
}
catch (...) {
    throw "def";  // abort here
}

Two: An uncaught exception that attempts to propagates outside main().

int main(int argc, char** argv)
{
    throw "abc";  // abort here
}

C++ experts could probably name more special cases.

There is also a lot of good info on these reference pages:

• https://en.cppreference.com/w/cpp/utility/program/abort
• https://en.cppreference.com/w/cpp/error/terminate

For Android native code, here are some reasons abort is called according to https://source.android.com/devices/tech/debug/native-crash :

Aborts are interesting because they are deliberate. There are many different ways to abort (including calling abort(3), failing an assert(3), using one of the Android-specific fatal logging types), but all involve calling abort.

The error munmap_chunk invalid pointer also causes a SIGABRT and in my case it was very hard to debug as I was not using pointers at all. It turned out that it was related to std::sort().

std::sort() requires a compare function that creates a strict weak ordering! That means both comparator(a, b) and comparator(b, a) must return false when a==b holds. (see https://en.cppreference.com/w/cpp/named_req/Compare) In my case I defined the operator< in my struct like below:

bool operator<(const MyStruct& o) const {
    return value <= o.value; // Note the equality sign
}

and this was causing the SIGABRT because the function does not create a strict weak ordering. Removing the = solved the problem.