blocks|key|1179460|text|abort()向调用进程发送SIGABRT信号，这是abort()的基本工作方式。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1179461|abort()通常由库函数调用，用于检测内部错误或某些严重破坏的约束。例如，如果其内部结构被堆溢出损坏，malloc()将调用abort()。|1179462|entityMap^0|0|7|E|7|Q|7|0|0|7|1G|8|1R|7|0^^$0|@$1|2|3|4|5|6|7|J|8|@$9|K|A|L|B|C]|$9|M|A|N|B|C]|$9|O|A|P|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|Q|8|@$9|R|A|S|B|C]|$9|T|A|U|B|C]|$9|V|A|W|B|C]]|D|@]|E|$]]|$1|H|3|-4|5|6|7|X|8|@]|D|@]|E|$]]]|I|$]]

<code>abort()</code> sends the calling process the <code>SIGABRT</code> signal, this is how <code>abort()</code> basically works. 

<code>abort()</code> is usually called by library functions which detect an internal error or some seriously broken constraint. For example <code>malloc()</code> will call <code>abort()</code> if its internal structures are damaged by a heap overflow.

blocks|key|965261|text|SIGABRT通常由libc和其他库使用，用于在出现严重错误时中止程序。例如，在检测到双释放或其他堆损坏的情况下，glibc会发送SIGABRT。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|965262|而且，大多数assert实现都会在断言失败的情况下使用SIGABRT。|965263|此外，SIGABRT可以像任何其他信号一样从任何其他进程发送。当然，发送进程需要以相同的用户或根用户身份运行。|965264|entityMap^0|0|7|1T|7|0|6|6|R|7|0|3|7|0^^$0|@$1|2|3|4|5|6|7|L|8|@$9|M|A|N|B|C]|$9|O|A|P|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|Q|8|@$9|R|A|S|B|C]|$9|T|A|U|B|C]]|D|@]|E|$]]|$1|H|3|I|5|6|7|V|8|@$9|W|A|X|B|C]]|D|@]|E|$]]|$1|J|3|-4|5|6|7|Y|8|@]|D|@]|E|$]]]|K|$]]

<code>SIGABRT</code> is commonly used by libc and other libraries to abort the program in case of critical errors. For example, glibc sends an <code>SIGABRT</code> in case of a detected double-free or other heap corruptions.

Also, most <code>assert</code> implementations make use of <code>SIGABRT</code> in case of a failed assert.

Furthermore, <code>SIGABRT</code> can be sent from any other process like any other signal. Of course, the sending process needs to run as same user or root.

blocks|key|965166|text|您可以使用kill(2)接口向任何进程发送任何信号：|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|965167|kill+-SIGABRT+30823|965168|30823是我启动的一个dash进程，所以我可以很容易地找到我想要杀死的进程。|965169|$+/bin/dash
$+Aborted|code-block|syntax|javascript|965170|Aborted输出显然是dash报告SIGABRT的方式。|965171|它可以使用kill(2)直接发送到任何进程，或者进程可以通过assert(3)、abort(3)或raise(3)将信号发送给自己。|965172|entityMap^0|5|7|0|0|J|0|C|4|0|0|0|7|C|4|0|5|7|U|9|14|8|1D|8|0^^$0|@$1|2|3|4|5|6|7|U|8|@$9|V|A|W|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|X|8|@$9|Y|A|Z|B|C]]|D|@]|E|$]]|$1|H|3|I|5|6|7|10|8|@$9|11|A|12|B|C]]|D|@]|E|$]]|$1|J|3|K|5|L|7|13|8|@]|D|@]|E|$M|N]]|$1|O|3|P|5|6|7|14|8|@$9|15|A|16|B|C]|$9|17|A|18|B|C]]|D|@]|E|$]]|$1|Q|3|R|5|6|7|19|8|@$9|1A|A|1B|B|C]|$9|1C|A|1D|B|C]|$9|1E|A|1F|B|C]|$9|1G|A|1H|B|C]]|D|@]|E|$]]|$1|S|3|-4|5|6|7|1I|8|@]|D|@]|E|$]]]|T|$]]

You can send any signal to any process using the <code>kill(2)</code> interface:

<code>kill -SIGABRT 30823</code>

30823 was a <code>dash</code> process I started, so I could easily find the process I wanted to kill.

<pre><code>$ /bin/dash
$ Aborted
</code></pre>

The <code>Aborted</code> output is apparently how <code>dash</code> reports a SIGABRT.

It can be sent directly to any process using <code>kill(2)</code>, or a process can send the signal to itself via <code>assert(3)</code>, <code>abort(3)</code>, or <code>raise(3)</code>.

blocks|key|965321|text|这种情况通常发生在内存分配出现问题的时候。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|965322|当我的程序试图分配一个大小为负的数组时，我遇到了这种情况。|965323|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

It usually happens when there is a problem with memory allocation. 

It happened to me when my program was trying to allocate an
array with negative size.

blocks|key|1179685|text|在c%2B%2B的情况下还有另一个简单的原因。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1179686|std::thread::~thread{
++++if((joinable+())
++++++++std::terminate+();
}|code-block|syntax|javascript|1179687|即线程的作用域已结束，但您忘记调用|1179688|thread::join();|1179689|或|1179690|thread::detach();|1179691|entityMap^0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|R|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|S|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|T|8|@]|9|@]|A|$E|F]]|$1|K|3|L|5|6|7|U|8|@]|9|@]|A|$]]|$1|M|3|N|5|D|7|V|8|@]|9|@]|A|$E|F]]|$1|O|3|-4|5|6|7|W|8|@]|9|@]|A|$]]]|P|$]]

There's another simple cause in case of c++.

<pre><code>std::thread::~thread{
 if((joinable ())
 std::terminate ();
}
</code></pre>

i.e. scope of thread ended but you forgot to call either 

<pre><code>thread::join();
</code></pre>

or

<pre><code>thread::detach();
</code></pre>

blocks|key|1179637|text|GNU+libc会在调用abort()+(然后触发SIGABRT)之前将一些致命条件的信息打印到/dev/tty，但是如果您将程序作为服务运行，或者没有在实际的终端窗口中运行，这些消息可能会丢失，因为没有tty来显示消息。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1179638|请参阅我关于将libc重定向到stderr而不是/dev/tty的帖子：|1179639|Catching+libc+error+messages,+redirecting+from+/dev/tty|1179640|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/questions/32056387/catching-libc-error-messages-redirecting-from-dev-tty^0|C|7|P|7|1C|8|0|0|0|1J|0|0^^$0|@$1|2|3|4|5|6|7|R|8|@$9|S|A|T|B|C]|$9|U|A|V|B|C]|$9|W|A|X|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|Y|8|@]|D|@]|E|$]]|$1|H|3|I|5|6|7|Z|8|@]|D|@$9|10|A|11|1|12]]|E|$]]|$1|J|3|-4|5|6|7|13|8|@]|D|@]|E|$]]]|K|$L|$5|M|N|O|E|$P|Q]]]]

The GNU libc will print out information to <code>/dev/tty</code> regarding some fatal conditions before it calls <code>abort()</code> (which then triggers <code>SIGABRT</code>), but if you are running your program as a service or otherwise not in a real terminal window, these message can get lost, because there is no tty to display the messages. 

See my post on redirecting libc to write to stderr instead of /dev/tty:

<a href="https://stackoverflow.com/questions/32056387/catching-libc-error-messages-redirecting-from-dev-tty">Catching libc error messages, redirecting from /dev/tty</a>

blocks|key|1179821|text|当进程从自身获取SIGABRT时的一个例子:+Hrvoje提到从ctor调用一个隐藏的纯虚拟生成一个中止，我为此重新创建了一个例子。在这里，当要构造d时，它首先调用它的基类A+ctor，并将内部指针传递给它自己。在表被有效指针填充之前，A+ctor调用纯虚方法，因为d还没有构造。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1179822|#include<iostream>
using+namespace+std;
class+A+{
public:
+A(A+*pa){pa->f();}
+virtual+void+f()=0;
};
class+D+:+public+A+{
public:
+D():A(this){}
+virtual+void+f()+{cout<<"D::f\n";}
};
int+main(){
+D+d;
+A+*pa+=+&d;
+pa->f();
+return+0;
}|code-block|syntax|javascript|1179823|编译:+g%2B%2B+-o+aa+aa.cpp|1179824|ulimit+-c无限制|1179825|运行：./aa|1179826|pure+virtual+method+called
terminate+called+without+an+active+exception
Aborted+(core+dumped)|1179827|现在让我们快速查看核心文件，并验证是否确实调用了SIGABRT：|1179828|gdb+aa+core|1179829|请参阅regs：|1179830|i+r
rdx++++++++++++0x6++++++6
rsi++++++++++++0x69a++++1690
rdi++++++++++++0x69a++++1690
rip++++++++++++0x7feae3170c37|1179831|校验码：|1179832|disas+0x7+feete3170c37|1179833|mov++++$0xea,%25eax++=+234++<-+this+is+the+kill+syscall,+sends+signal+to+process
syscall+++<-----|1179834|http://blog.rchapman.org/posts/Linux_System_Call_Table_for_x86_64/|offset|length|1179835|234+sys_tgkill+pid_t+tgid+pid_t+pid整数信号=6=信号|1179836|:)|1179837|entityMap|0|LINK|mutability|MUTABLE|url^0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|1U|0|0|0|0^^$0|@$1|2|3|4|5|6|7|1H|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|1I|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|1J|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|1K|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|1L|8|@]|9|@]|A|$]]|$1|M|3|N|5|D|7|1M|8|@]|9|@]|A|$E|F]]|$1|O|3|P|5|6|7|1N|8|@]|9|@]|A|$]]|$1|Q|3|R|5|D|7|1O|8|@]|9|@]|A|$E|F]]|$1|S|3|T|5|6|7|1P|8|@]|9|@]|A|$]]|$1|U|3|V|5|D|7|1Q|8|@]|9|@]|A|$E|F]]|$1|W|3|X|5|6|7|1R|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|6|7|1S|8|@]|9|@]|A|$]]|$1|10|3|11|5|D|7|1T|8|@]|9|@]|A|$E|F]]|$1|12|3|13|5|6|7|1U|8|@]|9|@$14|1V|15|1W|1|1X]]|A|$]]|$1|16|3|17|5|6|7|1Y|8|@]|9|@]|A|$]]|$1|18|3|19|5|6|7|1Z|8|@]|9|@]|A|$]]|$1|1A|3|-4|5|6|7|20|8|@]|9|@]|A|$]]]|1B|$1C|$5|1D|1E|1F|A|$1G|13]]]]

A case when process get SIGABRT from itself:
Hrvoje mentioned about a buried pure virtual being called from ctor generating an abort, i recreated an example for this.
Here when d is to be constructed, it first calls its base class A ctor,
and passes inside pointer to itself.
the A ctor calls pure virtual method before table was filled with valid pointer, 
because d is not constructed yet.

<pre><code>#include&lt;iostream&gt;
using namespace std;
class A {
public:
 A(A *pa){pa-&gt;f();}
 virtual void f()=0;
};
class D : public A {
public:
 D():A(this){}
 virtual void f() {cout&lt;&lt;"D::f\n";}
};
int main(){
 D d;
 A *pa = &amp;d;
 pa-&gt;f();
 return 0;
}
</code></pre>

compile: g++ -o aa aa.cpp

ulimit -c unlimited

run: ./aa

<pre><code>pure virtual method called
terminate called without an active exception
Aborted (core dumped)
</code></pre>

now lets quickly see the core file, and validate that SIGABRT was indeed called:

<pre><code>gdb aa core
</code></pre>

see regs:

<pre><code>i r
rdx 0x6 6
rsi 0x69a 1690
rdi 0x69a 1690
rip 0x7feae3170c37
</code></pre>

check code:

disas 0x7feae3170c37

<pre><code>mov $0xea,%eax = 234 &lt;- this is the kill syscall, sends signal to process
syscall &lt;-----
</code></pre>

<a href="http://blog.rchapman.org/posts/Linux_System_Call_Table_for_x86_64/" rel="noreferrer">http://blog.rchapman.org/posts/Linux_System_Call_Table_for_x86_64/</a>

234 sys_tgkill pid_t tgid pid_t pid int sig = 6 = SIGABRT

:)

blocks|key|1179747|text|在我的例子中，这是由于数组中索引等于数组长度的输入造成的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1179748|string+x[5];

for(int+i=1;+i<=5;+i%2B%2B){

++++cin>>x[i];

}|code-block|syntax|javascript|1179749|正在访问的x5不存在。|1179750|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|L|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|M|8|@]|9|@]|A|$]]|$1|I|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|J|$]]

In my case, it was due to an input in an array at an index equal to the length of the array.

<pre><code>string x[5];

for(int i=1; i&lt;=5; i++){

 cin&gt;&gt;x[i];

}
</code></pre>

x[5] is being accessed which is not present.

blocks|key|1179919|text|正如"@sarnold“恰如其分地指出的那样，任何进程都可以向任何其他进程发送信号，因此，一个进程可以向其他进程发送SIGABORT+&在这种情况下，接收进程无法区分它的到来是因为它自身的内存调整等原因，还是其他进程”单机“地向它发送信号。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1179920|在我工作的其中一个系统中，有一个死锁检测器，它实际上是通过心跳来检测进程是否正在退出某个任务。如果不是，则声明进程处于死锁状态，并向其发送SIGABORT。|1179921|我只是想通过提问来分享这一观点。|1179922|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

As "@sarnold", aptly pointed out, any process can send signal to any other process, hence, one process can send SIGABORT to other process &amp; 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.

What are the scenarios where a process gets a SIGABRT in C++? Does this signal always come from within the process or can this signal be sent from one process to another?

Is there a way to identify which process is sending this signal?

When does a process get SIGABRT (signal 6)?

进程在C++中获得SIGABRT的场景是什么？该信号是否总是来自进程内部，或者该信号是否可以从一个进程发送到另一个进程？有没有办法确定是哪个进程发送了这个信号？

问进程何时获得SIGABRT (信号6)？
EN

回答 9

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问进程何时获得SIGABRT (信号6)？EN

回答 9

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问进程何时获得SIGABRT (信号6)？
EN