一个不幸的事实是，所有的软件都有 bug，一些 bug 会导致系统崩溃。当它出现的时候，它经常会在磁盘上留下一个被称为“核心转储”的数据文件。该文件包含有关系统崩溃时的相关数据，可能有助于确定发生崩溃的原因。通常开发者要求提供 “回溯” 形式的数据，以显示导致崩溃的指令流。开发人员可以使用它来修复 bug 以改进系统。如果系统发生了崩溃，以下是如何轻松生成回溯的方法。
大多数 Fedora 系统使用自动错误报告工具（ABRT）[1]来自动捕获崩溃文件并记录 bug。但是，如果你禁用了此服务或删除了该软件包，则此方法可能会有所帮助。
如果你遇到系统崩溃，请首先确保你运行的是最新的软件。更新通常包含修复程序，这些更新通常含有已经发现的会导致严重错误和崩溃的错误的修复。当你更新后，请尝试重现导致错误的情况。
如果崩溃仍然发生，或者你已经在运行最新的软件，那么可以使用有用的 Coredumpctl 工具。此程序可帮助查找和处理崩溃。要查看系统上所有核心转储列表，请运行以下命令：
coredumpctllist如果你看到比预期长的列表，请不要感到惊讶。有时系统组件在后台默默地崩溃，并自行恢复。快速查找今天的转储的简单方法是使用 -since 选项：
coredumpctllist--since=today“PID” 列包含用于标识转储的进程 ID。请注意这个数字，因为你会之后再用到它。或者，如果你不想记住它，使用下面的命令将它赋值给一个变量：
要查看关于核心转储的信息，请使用此命令（使用 $MYPID 变量或替换 PID 编号）：
coredumpctlinfo在核心转储中的数据以及原始代码中的指令之间调试符号转义。这个符号数据可能相当大。与大多数用户运行在 Fedora 系统上的软件包不同，符号以 “debuginfo” 软件包的形式安装。要确定你必须安装哪些 debuginfo 包，请先运行以下命令：
coredumpctlgdb这可能会在屏幕上显示大量信息。最后一行可能会告诉你使用 dnf 安装更多的 debuginfo 软件包。用 sudo [2]运行该命令以安装：
sudodnfdebuginfo-install然后再次尝试 coredumpctl gdb $MYPID 命令。 你可能需要重复执行此操作 ，因为其他符号会在回溯中展开。
在调试器中运行以下命令以记录信息：
loggingfilemybacktrace.txtloggingon你可能会发现关闭分页有帮助。对于长的回溯，这可以节省时间。
paginationoff现在运行回溯：
threadapplyallbtfull现在你可以输入 quit 来退出调试器。mybacktrace.txt 包含可附加到 bug 或问题的追踪信息。或者，如果你正在与某人实时合作，则可以将文本上传到 pastebin。无论哪种方式，你现在可以向开发人员提供更多的帮助来解决问题。
select和epoll的区别
下面是select的函数接口： int select (int n, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timeval *timeout); select 函数监视的文件描述符分3类，分别是writefds、readfds、和exceptfds。调用后select函数会阻塞，直到有
为什么没有产生core 文件
在Linux上只要打开core dump文件开关，当程序crash时系统生成相应的core文件。 下面是简单的一些步骤： 1.查看当前是否已经打开了此开关 通过命令：uLIMIT -c 如果输出为 0 ，则代表没有打开。 如果为unlimited则已经打开了,就没必要在做打开。
LINUX下报仅有的JAVA错误，能判断是什么原因引起的吗
因为没有贴上报错信息，问题有4个方向：1. Linux 的java运行环境，jdk/jre/容器/数据库，版本/配置文件安装是否成功2. 项目本身有bug，看项目日志，去IDE调试3. linux下是否有相关项目的依赖服务，输入命令查看是否已开启4. 数据库连接是否正常，防火墙状态是否配置
发表评论