在gdb中使用coredump时，我如何确切知道哪个线程导致了SIGSEGV? [英] When using a coredump in gdb how do I know exactly which thread caused SIGSEGV?

问题描述

我的应用程序使用8个以上的线程.当我在gdb中运行info threads时，我看到了线程以及它们正在执行的最后一个函数.在我看来，确切是哪个线程引起了SIGSEGV似乎并不明显.有可能说出来吗?是线程1吗?线程如何编号?

My application uses more than 8 threads. When I run info threads in gdb I see the threads and the last function they were executing. It does not seem obvious to me exactly which thread caused the SIGSEGV. Is it possible to tell it? Is it thread 1? How are the threads numbered?

推荐答案

当您使用gdb分析核心转储文件时，gdb将在导致程序核心转储的函数处停止.当前的话题将是谋杀.以以下程序为例:

When you use gdb to analyze the core dump file, the gdb will stop at the function which causes program core dump. And the current thread will be the murder. Take the following program as an example:

#include <stdio.h>
#include <pthread.h>
void *thread_func(void *p_arg)
{
        while (1)
        {
                printf("%s\n", (char*)p_arg);
                sleep(10);
        }
}
int main(void)
{
        pthread_t t1, t2;

        pthread_create(&t1, NULL, thread_func, "Thread 1");
        pthread_create(&t2, NULL, thread_func, NULL);

        sleep(1000);
        return;
}

t2线程将导致程序关闭，因为它引用了NULL指针.程序关闭后，使用gdb分析核心转储文件:

The t2 thread will cause program down because it refers a NULL pointer. After the program down, use gdb to analyze the core dump file:

[root@localhost nan]# gdb -q a core.32794
Reading symbols from a...done.
[New LWP 32796]
[New LWP 32795]
[New LWP 32794]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `./a'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00000034e4281451 in __strlen_sse2 () from /lib64/libc.so.6
(gdb)

gdb在__strlen_sse2功能处停止，这意味着该功能导致程序关闭.然后使用bt命令查看它是由哪个线程调用的:

The gdb stops at __strlen_sse2 function, this means this function causes the program down. Then use bt command to see it is called by which thread:

(gdb) bt
#0  0x00000034e4281451 in __strlen_sse2 () from /lib64/libc.so.6
#1  0x00000034e4268cdb in puts () from /lib64/libc.so.6
#2  0x00000000004005cc in thread_func (p_arg=0x0) at a.c:7
#3  0x00000034e4a079d1 in start_thread () from /lib64/libpthread.so.0
#4  0x00000034e42e8b6d in clone () from /lib64/libc.so.6
(gdb) i threads
  Id   Target Id         Frame
  3    Thread 0x7ff6104c1700 (LWP 32794) 0x00000034e42accdd in nanosleep () from /lib64/libc.so.6
  2    Thread 0x7ff6104bf700 (LWP 32795) 0x00000034e42accdd in nanosleep () from /lib64/libc.so.6
* 1    Thread 0x7ff60fabe700 (LWP 32796) 0x00000034e4281451 in __strlen_sse2 () from /lib64/libc.so.6

bt命令显示当前线程的堆栈帧(这是谋杀). "i threads"命令显示所有线程，以*开头的线程号是当前线程.

The bt command shows the stack frame of the current thread(which is the murder). "i threads" commands shows all the threads, the thread number which begins with * is the current thread.

至于"How are the threads numbered?"，取决于操作系统.您可以参考 gdb手册以获取更多信息.

As for "How are the threads numbered?", it depends on the OS. you can refer the gdb manual for more information.

这篇关于在gdb中使用coredump时，我如何确切知道哪个线程导致了SIGSEGV?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！