出现segment错误 之后没有core的排查

本文介绍如何检查和开启core dump功能,解决因目录不存在导致的core文件无法生成问题,并强调了在编译时加入-ggdb选项的重要性。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

检查是否打开core

没有打开的例子:
[root@senbo088]# ulimit -c
0
[root@senbo088]# ./test
Segmentation fault

打开之后的例子:

[root@senbo088]# ulimit -c unlimited
0
[root@senbo088]# ulimit -c
unlimited
[root@senbo088]# ./test
Segmentation fault (core dumped)

检查core 的路径

一种典型而又及其隐蔽的core不dump的错误是 修改了core dump的默认路径,但是目录不存在。

如下这种情况:
[root@senbo088]# ulimit -c
unlimited
[root@senbo088]# ./test
Segmentation fault

[root@senbo088]# sysctl -p
排查过程如下:
net.ipv4.ip_forward = 0
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.default.accept_source_route = 0
kernel.sysrq = 0
kernel.core_uses_pid = 1
net.ipv4.tcp_syncookies = 1
error: "net.bridge.bridge-nf-call-ip6tables" is an unknown key
error: "net.bridge.bridge-nf-call-iptables" is an unknown key
error: "net.bridge.bridge-nf-call-arptables" is an unknown key
kernel.printk = 0
kernel.printk = 0
kernel.corepattern = /var/core/core%e_%p
kernel.core_uses_pid = 0

[root@senbo088]# ls /var/core
ls: cannot access /var/core: No such file or directory

创建 /var/core目录之后,就好了:

[root@senbo088]# mkdir -p /var/core/
[root@senbo088]# ./test
Segmentation fault (core dumped)

为了支持core 最好打开-ggdb编译选项

必需 -g / -ggdb 支持;

转载于:https://blog.51cto.com/xiamachao/2409482

### 解决 VSCode 中 C++ 程序段错误的方法 #### 使用 `launch.json` 设置断点并启动调试会话 为了有效定位和修复 C++ 程序中的 segment fault 错误,在 Visual Studio Code 的配置文件 `launch.json` 中合理设置参数至关重要[^1]。确保已安装适用于 C/C++ 的扩展插件,并创建或修改 `.vscode/launch.json` 文件来支持 GDB 或 LLDB 调试器。 对于 Linux 和 macOS 用户,默认情况下通常使用 GDB;而对于 Windows,则可能更倾向于利用 MinGW-w64 版本的 GDB 或者 LLVM 的 LLDB。以下是基于 GDB 的一个典型配置实例: ```json { "version": "0.2.0", "configurations": [ { "name": "(gdb) Launch", "type": "cppdbg", "request": "launch", "program": "${workspaceFolder}/build/main.exe", "args": [], "stopAtEntry": false, "cwd": "${workspaceFolder}", "environment": [], "externalConsole": true, "MIMode": "gdb", "setupCommands": [ { "description": "Enable pretty-printing for gdb", "text": "-enable-pretty-printing", "ignoreFailures": true } ], "preLaunchTask": "Build Program" } ] } ``` 此 JSON 对象定义了一个名为 `(gdb) Launch` 的调试配置项,指定了要执行的目标程序路径 `${workspaceFolder}/build/main.exe` ,以及一些其他必要的选项如工作目录 (`cwd`) 和环境变量等。特别值得注意的是 `"preLaunchTask"` 字段,它指向构建任务名称(例如编译命令),这将在每次开始新的调试会话之前自动触发一次完整的重新编译过程,从而保证所加载的是最新版本的可执行文件。 #### 启动调试模式下的核心转储分析 当应用程序崩溃时,如果启用了 core dump 功能,那么系统将会保存一份内存映像到磁盘上作为后续调查的基础资料。可以通过调整系统的 ulimit 参数或者特定平台上的相应机制来控制是否生成这些核心转储文件及其大小限制。一旦获得了有效的 core file,就可以将其传递给 GDB 来获取更多关于发生异常时刻的信息: ```bash ulimit -c unlimited # 允许无限大尺寸的核心转储文件 ./your_program # 执行可能导致段错误的应用程序 (gdb) core-file path/to/core_dump_file (gdb) bt # 查看调用栈跟踪信息 ``` 上述指令序列展示了如何先解除对核心转储文件大小的任何潜在约束,接着尝试重现问题场景以便触发段错误事件的发生,最后借助于 GDB 工具读取先前记录下来的核心转储数据来进行详细的故障排查工作[^2]。 #### 定位具体位置与原因 在成功捕获到了导致段错误的具体上下文之后,下一步就是仔细审查源码逻辑找出根本性的缺陷所在之处。常见的引发此类问题的原因包括但不限于越界访问数组元素、解引用非法指针地址或是释放后的对象再次被操作等情况。此时可以充分利用 IDE 内建的功能特性辅助诊断流程,比如查看局部变量的状态变化趋势图谱、单步跟进函数内部的操作细节直至发现可疑行为为止。 另外一种方法是从标准库的角度出发考虑是否存在不当使用的可能性。举例来说,当涉及到字符串处理的时候应当谨慎对待边界条件管理,因为即使是看似简单的 API 如 `std::string.size()` 函数也可能隐藏着意想不到的风险因素[^3][^4]。务必遵循最佳实践指南编写健壮可靠的代码片段,尽可能减少不必要的风险暴露面。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值