文章目录
1.背景
在使用Qt时，假如在windows，当软件崩溃时，可以利用生成dmp文件来查找软件崩溃的原因及原因出现的位置（在源码的哪一行）。具体可以看看我这篇博客：【Qt下生成pdb文件，并在exe崩溃时生成dmp文件，且由dmp查询崩溃原因】；
但是在linux下，要生成dmp文件貌似很麻烦，要用到google的BreakPad【Qt Linux系统使用QBreakpad实战】。
有没有方便一点的方法呢？
其实有的，linux下原生支持一种定位软件崩溃的方式：core dump。
2.Qt编译生成程序
建立一个简单的程序，并写一段空指针导致崩溃的程序
选择profile模式进行编译：
2.1.profile模式的本质
选择profile模式进行编译时，除了生成一个以项目名字命名的可执行程序外，还会生成一个以项目名字+.debug命名的文件。
这个文件不是可执行文件，而是一个调试信息文件，里面的信息会辅助程序在崩溃时保存当时的堆栈、变量值等。
关于这个*.debug文件的生成，我们还可以从Qt的编译输出窗口了解到一些信息：
首先，g++在编译时是加了-g选项，表示在编译时把调试信息编译进去（相当于debug模式？）
然后再看这一行：
objcopy --only-keep-debug untitled1 untitled1.debug && objcopy --strip-debug untitled1 && objcopy --add-gnu-debuglink=untitled1.debug untitled1 && chmod -x untitled1.debug
这里用到一个关键命令：objcopy，关于这个工具的用法，可以查看【GNU objcopy命令的探索:（转换二进制文件）】
可以看到上面这个语句分为四部分，依次执行：
- objcopy --only-keep-debug untitled1 untitled1.debug
使用objcopy工具来创建一个调试信息副本。–only-keep-debug选项告诉objcopy只保留调试信息而不进行其他任何操作。untitled1是原始的目标文件，而untitled1.debug是生成的只包含调试信息的文件。 - objcopy --strip-debug untitled1
这一行再次使用objcopy，但这次是去除目标文件untitled1中的调试信息。–strip-debug选项会移除所有的调试信息，使得目标文件更小，运行速度可能更快，但这样会使得调试变得更加困难。 - objcopy --add-gnu-debuglink=untitled1.debug untitled1
这一行又用objcopy来重新添加一个GNU风格的调试链接到untitled1可执行文件中。–add-gnu-debuglink=后面跟着的untitled1.debug是之前保留的调试信息文件。这样，即使调试信息被剥离，执行文件中仍然有一个指向原始调试信息的链接，可以在调试时恢复调试信息。 - chmod -x untitled1.debug
最后一行使用chmod命令改变untitled1.debug文件的权限，使得这个文件不可执行。-x选项表示移除执行权限。
总的来说，这四段命令的目的是对原可执行文件优化（去除调试信息）后，仍然能够恢复和执行原始的调试信息，以便于后续的调试工作。
3.执行程序，得到core文件
将编译出来的两个文件拷贝到一个单独的文件夹（目的是避嫌，测试在空白环境能不能运行）
然后在此文件夹打开控制台（或者打开控制台后cd到这个文件夹）
执行两个语句（这两个语句的作用可以查看这里【Linux生成core文件相关配置，core文件调试示例】）
ulimit -c 4096
sudo sysctl kernel.core_pattern=%e.core
然后执行程序
./untitled1
可以看到，生成了core文件（不知道为啥.code后面还加了个数字）
4.代码定位
在得到core文件后，假如想要知道到底是哪一行代码导致了程序崩溃，有两种方式：
4.1.直接使用gdb
gdb untitled1 untitled1.core.9305
可以看到，崩溃的地方被显示出来了。
还可以把这个ptr运行时的值打印出来
print ptr
4.2.使用QtCreator
选择Debug–》Start Debugging–》Load Core File
在弹窗中选择刚才的core文件，选好后，可执行文件会自动填充。然后点击ok。
然后就可以调试了：
同样定位到了正确的代码处，并且还把当时的各个变量的值直接显示出来。
所以这种方式应该是比较适合咱们这种一般人。
5.总结
Linux下程序的崩溃文件生成相对于Windows下还方便一点（Windows下还得自己保存dmp文件），可能各有千秋吧。
暂时还没试过在A电脑编译程序，然后放到B电脑运行产生core文件，然后再拿回A电脑进行代码定位。有空的话得测试一下。
6.题外话
6.1.profile模式和debug模式的区别
我们直接把这两种的编译语句拿出来对比一下
这是debug的： g++ -c -pipe -g -std=gnu++1z -Wall -Wextra -D_REENTRANT -fPIC -DQT_QML_DEBUG -DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_CORE_LIB -I../untitled1 -I. -I/opt/Qt/5.15.2/gcc_64/include -I/opt/Qt/5.15.2/gcc_64/include/QtWidgets -I/opt/Qt/5.15.2/gcc_64/include/QtGui -I/opt/Qt/5.15.2/gcc_64/include/QtCore -I. -I/usr/include/libdrm -I. -I/opt/Qt/5.15.2/gcc_64/mkspecs/linux-g++ -o main.o ../untitled1/main.cpp
这shiprofile的： g++ -c -pipe -O2 -g -std=gnu++1z -Wall -Wextra -D_REENTRANT -fPIC -DQT_QML_DEBUG -DQT_NO_DEBUG -DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_CORE_LIB -I../untitled1 -I. -I/opt/Qt/5.15.2/gcc_64/include -I/opt/Qt/5.15.2/gcc_64/include/QtWidgets -I/opt/Qt/5.15.2/gcc_64/include/QtGui -I/opt/Qt/5.15.2/gcc_64/include/QtCore -I. -I/usr/include/libdrm -I. -I/opt/Qt/5.15.2/gcc_64/mkspecs/linux-g++ -o main.o ../untitled1/main.cpp
对比一下可以看到，主要是在profile下，多了 -O2 -DQT_NO_DEBUG这两个选项。
-O2：进行代码优化、优化等级为2；具体请查阅相关资料。
-DQT_NO_DEBUG：这个应该是个编译定义、编译选项？当出现这个定义时，一部分Qt代码将不会被编译到可执行文件中？假如这个定义是在链接库时生效的，还可以在编译时对库里面的代码进行选择？库里面的代码不是在编程这个库时就已经决定了吗，宏定义不是预编的一种吗？既然是预编译，那么对于一个库来收，在正式编译前，代码已经通过预编译进行了选择吧，为何再加-DQT_NO_DEBUG还有用？
-DQT_NO_DEBUG：这表示在编译时添加一个宏定义，和在代码中增加 #define QT_NO_DEBUG的效果一样。之所以加这个，是因为在Qt的头文件中，有很多地方都利用到了这个宏定义。加了这个定义后，Qt会相应地做了一些优化。
参考：
【Linux生成core文件相关配置，core文件调试示例】
【【问题记录】Ubuntu 22.04 环境下，程序报：段错误（核心已转储）怎么使用 core 文件和GDB调试器 解决？】
