在gdb中使用coredump时,我如何确切知道哪个线程导致了SIGSEGV?

编程入门 行业动态 更新时间:2024-10-12 01:28:46
本文介绍了在gdb中使用coredump时,我如何确切知道哪个线程导致了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?

本文发布于:2023-07-14 10:39:15,感谢您对本站的认可!
本文链接:https://www.elefans.com/category/jswz/34/1104133.html
版权声明:本站内容均来自互联网,仅供演示用,请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系,我们将在24小时内删除。
本文标签:线程   确切   gdb   coredump   SIGSEGV

发布评论

评论列表 (有 0 条评论)
草根站长

>www.elefans.com

编程频道|电子爱好者 - 技术资讯及电子产品介绍!