如何查看core文件

Posted 2023-04-06

参考技术A 在Unix系统下，应用程序崩溃，一般会产生core文件，如何根据core文件查找问题的所在，并做相应的分析和调试，是非常重要的，本文对此做简单介绍。

例如，一个程序cmm_test_tool在运行的时候发生了错误，并生成了一个core文件，如下：

-rw-r–r– 1 root cmm_test_tool.c
-rw-r–r– 1 root
cmm_test_tool.o
-rwxr-xr-x 1 root cmm_test_tool
-rw——- 1 root
core.19344
-rw——- 1 root core.19351
-rw-r–r– 1 root
cmm_test_tool.cfg
-rw-r–r– 1 root cmm_test_tool.res
-rw-r–r– 1 root
cmm_test_tool.log
[root@AUTOTEST_SIM2 mam2cm]#

就可以利用命令gdb进行查找，参数一是应用程序的名称，参数二是core文件，运行
gdb
cmm_test_tool core.19344结果如下：

[root@AUTOTEST_SIM2 mam2cm]# gdb cmm_test_tool core.19344
GNU gdb Red Hat
Linux (5.2.1-4)
Copyright 2002 Free Software Foundation, Inc.
GDB is free
software, covered by the GNU General Public License, and you are
welcome to
change it and/or distribute copies of it under certain conditions.
Type “show
copying” to see the conditions.
There is absolutely no warranty for GDB. Type
“show warranty” for details.
This GDB was configured as
“i386-redhat-linux”…
Core was generated by `./cmm_test_tool’.
Program
terminated with signal 11, Segmentation fault.
Reading symbols from
/lib/i686/libpthread.so.0…done.
Loaded symbols for
/lib/i686/libpthread.so.0
Reading symbols from
/lib/i686/libm.so.6…done.
Loaded symbols for /lib/i686/libm.so.6
Reading
symbols from /usr/lib/libz.so.1…done.
Loaded symbols for
/usr/lib/libz.so.1
Reading symbols from
/usr/lib/libstdc++.so.5…done.
Loaded symbols for
/usr/lib/libstdc++.so.5
Reading symbols from
/lib/i686/libc.so.6…done.
Loaded symbols for /lib/i686/libc.so.6
Reading
symbols from /lib/libgcc_s.so.1…done.
Loaded symbols for
/lib/libgcc_s.so.1
Reading symbols from /lib/ld-linux.so.2…done.
Loaded
symbols for /lib/ld-linux.so.2
Reading symbols from
/lib/libnss_files.so.2…done.
Loaded symbols for /lib/libnss_files.so.2
#0
0×4202cec1 in __strtoul_internal () from
/lib/i686/libc.so.6
(gdb)

进入gdb提示符，输入where，找到错误发生的位置和堆栈，如下：

(gdb) where
#0 0×4202cec1 in __strtoul_internal () from
/lib/i686/libc.so.6
#1 0×4202d4e7 in strtoul () from
/lib/i686/libc.so.6
#2 0×0804b4da in GetMaxIDFromDB (get_type=2,
max_id=0×806fd20) at cmm_test_tool.c:788
#3 0×0804b9d7 in ConstrctVODProgram
(vod_program=0×40345bdc) at cmm_test_tool.c:946
#4 0×0804a2f4 in
TVRequestThread (arg=0×0) at cmm_test_tool.c:372
#5 0×40021941 in
pthread_start_thread () from /lib/i686/libpthread.so.0
(gdb)

至此，可以看出文件出错的位置是函数 GetMaxIDFromDB
，两个参数分别是2和0×806fd20，这个函数位于源代码的788行，基于此，我们就可以有针对性的找到问题的根源，并加以解决。本回答被提问者和网友采纳

ubuntu20.04 如何生成core文件

目录

• • 1. 查看是否打开了coredump
  • 2.设置core文件存储路径

在网上找到一些答案，总结如下：

1. 查看是否打开了coredump

ulimit -c   //未设置之前
0

可以使用下面命令修改

ulimit -c 1024
ulimit -c unlimited    //大小不受限

但是这个只是针对当前这个连接，如果想要永久修改可以修改配置文件：
vim /etc/profile，然后添加上面的命令ulimit - c unlimited.然后执行source /etc/profile或者重启使刚刚的配置可以生效。

Ubuntu20.4 坑1：
这样修改并不能永久改变，因为在终端执行ulimit -c查看，并不是我们设置的结果。

2.设置core文件存储路径

打开文件 /etc/sysctl.conf ，添加以下内容：

kernel.core_pattern = /var/core/core_%e_%p   
kernel.core_uses_pid = 0   //是否加上pid

然后reboot。
这样看似完成了，但是被ubuntu server 20.04的core生成机制给坑了一把。所以还是生成不了。

cat /proc/sys/kernel/core_pattern
|/usr/share/apport/apport %p %s %c %d %P %E

ubuntu的服务apport.service。自动生成崩溃报告，官方为了自动收集错误的。这个玩意会导致core_pattern的设置不能一直有效，只要这个服务存在，系统重新启动后就会把core_pattern改为一个特定的值，直接导致coredump无法生成。

这个服务对我们来说，基本没用。修改/etc/default/apport文件，enabled 设置为0。这个时候再看一下：

cat /proc/sys/kernel/core_pattern
/var/core/core_%e_%p

# ./test
段错误 (核心已转储)
# cd /var/core
root@jqw-virtual-machine:/var/core# ls
core_test_2422

参考：
https://blog.csdn.net/qq_16019185/article/details/82620803
https://blog.csdn.net/qq_15328161/article/details/109085705