linux环境下程序崩溃段错误之core文件查看

在Linux中,core文件是程序崩溃时产生的一个特殊文件,它包含了程序崩溃时的内存内容。要查看core文件,你需要使用一个调试器,如gdb

以下是查看core文件的步骤:

1.使用ulimit命令设置允许core文件生成。运行ulimit -c可以查看core文件的大小限制,如果是0,则不会生成core文件,可以使用"ulimit -c 单位数量"设置最大的 core 文件的大小, 以 blocks 为单位,也可以使用ulimit -c unlimited来设置core文件可以无限大。

ulimit -c unlimited

2.运行程序。如果程序崩溃,则会生成core文件。通常,core文件命名为core.pid,其中pid是导致生成core文件的进程ID。

3.使用gdb调试器查看core文件。假设你的程序名为your_program,则可以使用以下命令:

gdb your_program core.pid

gdb中,你可以使用各种命令来查看崩溃时的调用栈、变量值等信息,例如:

  • bt 或 backtrace:查看调用栈。
  • info locals:查看当前函数中的局部变量。
  • info registers:查看寄存器的值。
  • up 或 down:在调用栈帧之间移动。

使用模板

$ ulimit -c unlimited  # 设置core文件大小无限制
$ ./your_program        # 运行你的程序,导致崩溃并生成core文件
$ gdb your_program core.12345  # 假设进程ID是12345
(gdb) bt                        # 查看调用栈信息
(gdb) up                        # 查看上一层函数的信息
(gdb) info locals              # 查看局部变量
(gdb) quit                      # 退出gdb

使用示例

[root@localhost run]# gdb trade_demo_real core.245441
GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-114.el7
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /root/yhzq_atp_trade_real/demo/simple_demo/run/trade_demo_real...(no debugging symbols found)...done.
[New LWP 245449]
[New LWP 245441]
[New LWP 245444]
[New LWP 245443]
[New LWP 245445]
[New LWP 245447]
[New LWP 245448]
[New LWP 245446]
[New LWP 245442]
Dwarf Error: wrong version in compilation unit header (is 5, should be 2, 3, or 4) [in module /lib64/libstdc++.so.6]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `./trade_demo_real'.
Program terminated with signal 11, Segmentation fault.
#0  0x00007fac310f33fd in std::string::assign(std::string const&) () from /lib64/libstdc++.so.6
Missing separate debuginfos, use: debuginfo-install glibc-2.17-260.el7.x86_64 libgcc-4.8.5-36.el7.x86_64
(gdb) bt
#0  0x00007fac310f33fd in std::string::assign(std::string const&) () from /lib64/libstdc++.so.6
#1  0x000000000040cc89 in query_position() ()
#2  0x000000000040d1a5 in query_all() ()
#3  0x000000000040f6bc in Strategy() ()
#4  0x0000000000423d39 in void std::_Bind_simple<void (*())()>::_M_invoke<>(std::_Index_tuple<>) ()
#5  0x0000000000423c93 in std::_Bind_simple<void (*())()>::operator()() ()
#6  0x0000000000423c2c in std::thread::_Impl<std::_Bind_simple<void (*())()> >::_M_run() ()
#7  0x00007fac310db68e in execute_native_thread_routine_compat () from /lib64/libstdc++.so.6
#8  0x00007fac30308dd5 in start_thread () from /lib64/libpthread.so.0
#9  0x00007fac30822ead in clone () from /lib64/libc.so.6
(gdb) info locals
No symbol table info available.
(gdb) up
#1  0x000000000040cc89 in query_position() ()
(gdb) bt
#0  0x00007fac310f33fd in std::string::assign(std::string const&) () from /lib64/libstdc++.so.6
#1  0x000000000040cc89 in query_position() ()
#2  0x000000000040d1a5 in query_all() ()
#3  0x000000000040f6bc in Strategy() ()
#4  0x0000000000423d39 in void std::_Bind_simple<void (*())()>::_M_invoke<>(std::_Index_tuple<>) ()
#5  0x0000000000423c93 in std::_Bind_simple<void (*())()>::operator()() ()
#6  0x0000000000423c2c in std::thread::_Impl<std::_Bind_simple<void (*())()> >::_M_run() ()
#7  0x00007fac310db68e in execute_native_thread_routine_compat () from /lib64/libstdc++.so.6
#8  0x00007fac30308dd5 in start_thread () from /lib64/libpthread.so.0
#9  0x00007fac30822ead in clone () from /lib64/libc.so.6
(gdb) up
#2  0x000000000040d1a5 in query_all() ()
(gdb) next
The program is not being run.
(gdb) info locals
No symbol table info available.
(gdb) down
#1  0x000000000040cc89 in query_position() ()
(gdb) down
#0  0x00007fac310f33fd in std::string::assign(std::string const&) () from /lib64/libstdc++.so.6
(gdb) down
Bottom (innermost) frame selected; you cannot go down.
(gdb) up
#1  0x000000000040cc89 in query_position() ()
(gdb) quit
[root@localhost run]#

在上面例子中,通过bt查看调用栈信息,#0可以看到产生错误的原因,#1可以知道在函数query_position() 内部发生了内存错误,#2可以知道query_position() 的调用是在query_all()函数内部调用的,因此接下来只需要在query_position()函数内部进行排查分析即可。


end

程序段错误崩溃时,使用gdb结合core文件是一种有效的故障定位方法。首先,确保程序崩溃时能够生成core文件。可以通过`ulimit -c unlimited`设置core文件大小为无限制。此外,编译程序时需要使用`-g`选项以包含调试信息。程序崩溃后,使用gdb与core文件进行交互,以下是详细步骤: 参考资源链接:[利用gdb深入分析core文件:故障排查指南](https://wenku.csdn.net/doc/6412b5fdbe7fbd1778d451e9?spm=1055.2569.3001.10343) 1. 启动gdb,并加载程序的可执行文件和生成的core文件,命令如下: ``` gdb /path/to/program /path/to/corefile ``` 其中`/path/to/program`是程序的可执行文件路径,`/path/to/corefile`是core文件的路径。 2. 在gdb提示符下,首先查看程序崩溃时的回溯信息,使用命令: ``` (gdb) bt ``` 这会列出函数调用的堆栈信息,从而显示出在哪个函数或文件中的哪一行代码崩溃。 3. 如果堆栈信息不清晰或需要查看变量值或内存内容,可以使用`frame`命令切换到特定的堆栈帧,然后使用`list`命令查看源代码或使用`print`命令打印变量值。例如: ``` (gdb) frame 3 (gdb) list (gdb) print variable_name ``` 其中`frame 3`是指定的堆栈帧编号,`list`命令会显示当前堆栈帧的源代码,`print variable_name`用于打印特定变量的值。 4. 通过查看回溯信息和相关代码,结合源代码和程序逻辑,尝试分析为什么会发生段错误。常见的原因包括访问了未初始化的指针、访问了不属于进程的内存区域、数组越界、内存泄漏等。 5. 分析完成后,可以使用`quit`命令退出gdb。 为了更好地掌握如何使用gdb和core文件定位段错误,建议参考《利用gdb深入分析core文件:故障排查指南》。这份资料详细介绍了gdb的基本使用、如何分析core文件、以及遇到各种异常信号时的处理策略和实例,能够帮助你更系统地学习和解决问题。 参考资源链接:[利用gdb深入分析core文件:故障排查指南](https://wenku.csdn.net/doc/6412b5fdbe7fbd1778d451e9?spm=1055.2569.3001.10343)
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值