进程什么时候得到SIGABRT(信号6)?

在c++中，进程获得SIGABRT的场景是什么?这个信号总是来自进程内部还是可以从一个进程发送到另一个进程?

有没有办法确定是哪个进程在发送这个信号?

当前回答

libc和其他库通常使用SIGABRT在出现严重错误时中止程序。例如，glibc在检测到double-free或其他堆损坏时发送SIGABRT。

此外，大多数断言实现在断言失败的情况下使用SIGABRT。

此外，SIGABRT可以像其他信号一样从任何其他进程发送。当然，发送进程需要以相同的用户或根用户运行。

其他回答

在c++中还有另一个简单的原因。

std::thread::~thread{
    if((joinable ())
        std::terminate ();
}

例如，线程范围结束，但你忘记调用

thread::join();

thread::detach();

我将从竞争性编程(cp)的角度给出我的答案，但它也适用于其他领域。

很多时候在做cp的时候，约束条件是相当大的。

例如:我有一个关于变量N, M, Q的问题，使得1≤N, M, Q < 10^5。

我犯的错误是我在c++中声明了一个大小为10000 x 10000的2D整数数组，并在Codechef中挣扎了近2天的SIGABRT错误。

现在，如果我们计算:

整数的典型大小:4字节不。数组中的单元格:10000 x 10000 总大小(字节):400000000字节= 4*10^8≈400mb

你对这些问题的解决方案将在你的PC上工作(不总是)，因为它可以负担得起这个大小。

但编码网站(在线裁判)的资源有限，只有几kb。

因此，会出现SIGABRT错误和其他此类错误。

结论:

在这样的问题中，我们不应该声明一个数组或向量或任何其他这种大小的DS，但我们的任务是使我们的算法如此高效，以至于它可以在没有它们(DS)或内存更少的情况下工作。

PS:这个错误可能有其他原因;上面是其中一个。

对于Android原生代码，以下是根据https://source.android.com/devices/tech/debug/native-crash调用abort的一些原因:

中止之所以有趣，是因为它们是有意为之的。中止有许多不同的方法(包括调用abort(3)， assert失败(3)，使用android特定的致命日志类型之一)，但都涉及调用abort。

关于第一个问题:在c++中进程获得SIGABRT的场景是什么?

我可以想到两种c++程序自动中止的特殊情况——不是通过直接调用std::abort()或std::terminate():

一:在处理异常时抛出异常。

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

二:试图在main()外部传播的未捕获异常。

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

c++专家可能还能举出更多的特殊情况。

在这些参考页面上也有很多好的信息:

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

它通常发生在内存分配有问题的时候。

当我的程序试图分配一个大小为负的数组。

推荐文章