Linux QT coredump

10 篇文章 0 订阅

ulimit -c   查看限制

ulimit -c unlimited 解除限制

运行可执行程序,若奔溃则产生core文件。

 通过指令:gdb gdbcdtest core  来打开core文件

如果存在core找不到的情况,可能是没配置core生成的默认路径。

---------------------------------------------------------------------------------------------------------------------------------

常用的gdb命令:

l(list) ,        显示源代码,并且可以看到对应的行号;

b(break)x,    x是行号,表示在对应的行号位置设置断点;

p(print)x,      x是变量名,表示打印变量x的值

r(run),          表示继续执行到断点的位置

n(next),        表示执行下一步

c(continue), 表示继续执行

q(quit),      表示退出gdb
 

常用signal的含义

SIGABRT:调用abort函数时产生此信号。进程异常终止。

SIGBUS:  指示一个实现定义的硬件故障。

SIGEMT:  指示一个实现定义的硬件故障。EMT这一名字来自PDP-11的emulator trap 指令。

SIGFPE:  此信号表示一个算术运算异常,例如除以0,浮点溢出等。

SIGILL:    此信号指示进程已执行一条非法硬件指令。4.3BSD由abort函数产生此信号。SIGABRT现在被用于此。

SIGIOT:   这指示一个实现定义的硬件故障。IOT这个名字来自于PDP-11对于输入/输出TRAP(input/outputTRAP)指令的缩写。系统V的早期版本,由abort函数产生此信号。SIGABRT现在被用于此。

SIGQUIT:当用户在终端上按退出键(一般采用Ctrl-/)时,产生此信号,并送至前台进

程组中的所有进程。此信号不仅终止前台进程组(如SIGINT所做的那样),同时产生一个core文件。

SIGSEGV:指示进程进行了一次无效的存储访问。名字SEGV表示“段违例(segmentationviolation)”。

SIGSYS:   指示一个无效的系统调用。由于某种未知原因,进程执行了一条系统调用指令,但其指示系统调用类型的参数却是无效的。

SIGTRAP:指示一个实现定义的硬件故障。此信号名来自于PDP-11的TRAP指令。

SIGXCPUSVR4和4.3+BSD支持资源限制的概念。如果进程超过了其软C P U时间限制,则产生此信号。

SIGXFSZ:如果进程超过了其软文件长度限制,则SVR4和4.3+BSD产生此信号。

---------------------------------------------------------------------------------------------------------------------------------

如果程序是通过shell脚本打开,不能再用gdb ./xxx.sh core来进行调试,不然定位不到问题。只能使用程序名称进行调试。

目前用的Qt6.2.试了再代码中加:

#QMAKE_CC += -g
#QMAKE_CXX += -g
#QMAKE_LINK += -g

没发现产生的core有啥区别。没有这个代码依然能通过core找到源码。

---------------------------------------------------------------------------------------------------------------------------------

关于coredump存储位置问题

echo 是向窗口输出脚本。

echo "$dirname/coredump.%e.%p" > /proc/sys/kernel/core_pattern

产生的core文件需要可执行程序一起。不然也定位不到错误位置。

这里记录一个矢量图设计软件www.inkscape.org

目前各个平台都行。

参考文章:详解coredump_tenfyguo的技术专栏-CSDN博客_core文件一,什么是coredump        我们经常听到大家说到程序core掉了,需要定位解决,这里说的大部分是指对应程序由于各种异常或者bug导致在运行过程中异常退出或者中止,并且在满足一定条件下(这里为什么说需要满足一定的条件呢?下面会分析)会产生一个叫做core的文件。        通常情况下,core文件会包含了程序运行时的内存,寄存器状态,堆栈指针,内存管理信息还有各种函数调用堆https://blog.csdn.net/tenfyguo/article/details/8159176

### 回答1: Linux中的core dump是指当程序由于意外错误或异常而崩溃时,系统将程序的内存内容转储到一个文件中,以便后续进行分析。下面是关于如何分析Linux core dump的步骤: 1. 确定core dump文件的位置:默认情况下,core dump文件保存在程序的当前工作目录。你可以使用`ulimit -c`命令来检查核心转储文件的大小限制,或者使用`sysctl kernel.core_pattern`命令查看核心转储文件的位置和名称模式。 2. 确保系统已经安装了相应的调试工具:在分析core dump之前,你需要安装GDB(GNU调试器),它是一个常用的用于调试程序和分析core dump的工具。使用`gdb`命令可以启动GDB。 3. 使用GDB加载core dump文件:在GDB命令行中,使用`gdb <程序名称> core`命令来加载core dump文件。这将打开GDB并加载core dump文件供分析。 4. 分析core dump文件:一旦core dump文件被加载到GDB中,你就可以进行分析了。你可以使用`bt`命令查看程序崩溃时的堆栈跟踪信息,这将有助于定位程序中的错误。你还可以使用其他GDB命令来检查变量的值,查找内存泄漏等。 5. 修复错误并重新编译程序(可选):根据core dump的分析结果,你可以找到程序中的错误并进行修复。之后,你可以重新编译程序并进行测试,以确保问题已解决。 总结起来,通过分析Linux core dump,我们可以确定程序崩溃的原因,并找到解决问题的方法。使用GDB等调试工具可以帮助我们更深入地了解程序内部的情况,从而提高代码的质量和稳定性。 ### 回答2: 在Linux系统中,coredump是指在程序发生异常导致崩溃时生成的包含程序内存和寄存器状态等信息的文件。通过分析coredump,我们可以了解程序崩溃的原因,从而进行故障排查和问题修复。 首先,我们需要使用gdb工具来分析coredump文件。可以通过以下命令来加载coredump文件: gdb 可执行文件路径 core文件路径 然后,我们可以使用gdb提供的一系列命令进行分析,如下: 1. bt:打印出崩溃时的函数调用栈,可以查看崩溃发生的位置和函数调用关系; 2. info registers:显示程序崩溃时寄存器的状态,包括程序计数器、堆栈指针等,可以帮助我们了解程序崩溃时寄存器的值; 3. print 变量名:打印出指定变量的值,可以了解程序崩溃时变量的取值情况; 4. x/地址:打印出指定地址的内存内容; 5. info sharedlibrary:显示程序崩溃时加载的动态链接库信息; 6. source 源代码路径:加载源代码文件,可以查找对应的源代码以进行分析。 通过以上命令,我们可以逐步了解coredump文件中的信息,找出程序崩溃的原因。常见的导致程序崩溃的原因包括空指针引用、数组越界、内存泄漏等。根据不同情况,我们可以调试代码并修复问题。 总而言之,分析coredump是一种定位和解决程序崩溃问题的重要方法,通过分析coredump文件,我们可以了解程序崩溃的原因,并根据相应的信息进行修复。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值