如何根据core文件中错误地址定位程序
发布网友
发布时间：2022-04-21 02:10
共2个回答
懂视网
时间：2022-04-30 13:00
更多：
http://blog.chinaunix.net/uid-22816738-id-4074928.html
Linux环境下经常遇到某个进程挂掉而找不到原因，我们可以通过生成core file文件加上gdb来定位。
如何产生core file?
我们可以使用ulimit这条命令对core file文件的大小进行设定。 一般默认情况下，core file的大小被设置为了0，这样系统就不dump出core file了。 这时用如下命令进行设置：ulimit -c unlimited
这样便把core file的大小设置为了无限大，同时也可以使用数字来替代unlimited，对core file的上限值做更精确的设定。
生成的core file在哪里?
core file生成的地方是在/proc/sys/kernel/core_pattern文件定义的。 改动到生成到自己定义的目录的方法是：echo "pattern" > /proc/sys/kernel/core_pattern
并且只有超级用户可以修改这两个文件。 "pattern"类似我们C语言打印字符串的格式，相关标识如下： %%: 相当于%
%p: 相当于<pid>
%u: 相当于<uid>
%g: 相当于<gid>
%s: 相当于导致dump的信号的数字
%t: 相当于dump的时间
%h: 相当于hostname
%e: 相当于执行文件的名称 这时用如下命令设置生成的core file到系统/tmp目录下，并记录pid以及执行文件名 echo "/tmp/core-%e-%p" > /proc/sys/kernel/core_pattern 测试如下代码
#include <stdio.h>
int func(int *p)
{
*p = 0;
}
int main()
{
func(NULL);
return 0;
}
生成可执行文件并运行
gcc -o main a.c
root@ubuntu:~# ./mainSegmentation fault (core dumped) <-----这里出现段错误并生成core文件了。 在/tmp目录下发现文件core-main-10815
如何查看进程挂在哪里了?
我们可以用 gdb main /tmp/core-main-10815 查看信息，发现能定位到函数了 Program terminated with signal 11, Segmentation fault.#0 0x080483ba in func ()
如何定位到行?
在编译的时候开启-g调试开关就可以了 gcc -o main -g a.c gdb main /tmp/core-main-10815 最终看到的结果如下，好棒。 Program terminated with signal 11, Segmentation fault.#0 0x080483ba in func (p=0x0) at a.c:5
5 *p = 0; 总结一下，需要定位进程挂在哪一行我们只需要4个操作， ulimit -c unlimited echo "/tmp/core-%e-%p" > /proc/sys/kernel/core_pattern gcc -o main -g a.c gdb main /tmp/core-main-10815 就可以啦。 补充说明：
相关常用gdb命令
1,(gdb) backtrace /* 查看当前线程函数栈回溯 */ 以上面的例子为例 Program terminated with signal 11, Segmentation fault. #0 0x080483ba in func (p=0x0) at main.c:5 5 *p = 0; (gdb) backtrace #0 0x080483ba in func (p=0x0) at main.c:5 #1 0x080483d4 in main () at main.c:10 如果是多线程环境下(gdb) thread apply all backtrace /* 显示所有线程栈回溯 */ 2,(gdb) print [var] /* 查看变量值 */ (gdb) print p $1 = (int *) 0x0 (gdb) print &p $2 = (int **) 0xbf96d4d4 3,(gdb) x/FMT [Address] /* 根据格式查看地址指向的值 */ 其中 FMT is a repeat count followed by a format letter and a size letter. Format letters are o(octal), x(hex), d(decimal), u(unsigned decimal), t(binary), f(float), a(address), i(instruction), c(char) and s(string). Size letters are b(byte), h(halfword), w(word), g(giant, 8 bytes). The specified number of objects of the specified size are printed according to the format. (gdb) x/d 0xbf96d4d4 0xbf96d4d4: 0 (gdb) x/c 0xbf96d4d4 0xbf96d4d4: 0 ‘ 00‘另外能导致产生core file文件的信号有以下10种
SIGQUIT：终端退出符
SIGILL：非法硬件指令
SIGTRAP：平台相关的硬件错误，现在多用在实现调试时的断点
SIGBUS：与平台相关的硬件错误，一般是内存错误
SIGABRT：调用abort函数时产生此信号，进程异常终止
SIGFPE：算术异常
SIGSEGV：segment violation，无效内存引用
SIGXCPU：超过了cpu使用资源（setrlimit）
SIGXFSZ：超过了文件长度（setrlimit）
SIGSYS：无效的系统调用
gdb结合coredump定位崩溃进程
标签：
热心网友
时间：2022-04-30 10:08
The problem that no `core' file is created on a segmentation fault; Locate errors in the source with GDB and `core' files
Linux 程序在遇到段错误(常见的是由非法访问内存引起)的时候会产生 core 文件，如果这个程序包含调试信息(编译的时候加 -g 选项)，那么使用 gdb 读取这个 core 文件可以快速定位出错的源代码。原来在某软件公司实习的时候(用 RedHat Enterprise Linux)觉得这样非常方便查错，但我自己用的 Debian GNU/Linux 却默认不生成这个文件。
检查以后发现原因是 core 文件最大尺寸(用 ulimit -c 查看)是 0，把它设置成非 0 值就可以了，如:
ulimit -c 2048(设置 core 文件最大尺寸为 2048 blocks，1block=512bytes，因此这里设置的其实是 1MiB)
ulimit -c unlimited(不限 core 文件尺寸)
附:用 gdb 根据 core mp 文件定位错误的办法。
用这个程序作一个测试:
int foo (int *p)
{
return *p;
}
main()
{
foo (0);
}
derek@dli: /tmp $ gcc -g a.c
derek@dli: /tmp $ ./a.out
段错误 (core mped)
derek@dli: /tmp $ gdb ./a.out -c core
(这里略去约十行其他信息)
Core was generated by `./a.out'.
Program terminated with signal 11, Segmentation fault.
#0 0x0804834a in foo (p=0x0) at a.c:3
3 return *p;
如果再输入一条命令 bt，就可以看得清清楚楚错误是在什么时机产生的:
(gdb) bt
#0 0x0804834a in foo (p=0x0) at a.c:3
#1 0x0804836b in main () at a.c:8
不能有比这更清楚的错误信息了!如果是在 Windows 下，就老老实实 Trace and Step 吧。
