linux主机利用crash分析_var_crash_下的vmcore 的dump分析

合集下载

linu 主机利用crash分析 var crash 下的vmcore 的dump分析

当主机crash后，会在这个目录下生成vmcore，也就是dump，如何分析这个dump来定位宕机的原因呢?可以执行crash vmlinux /var/crash/127.0.0.1-2014-06-22-16:08:36 来进入分析模式（vnlinux这里要指定的）他会报错，原因应该是缺乏kernel-debuginfo包，我们安装下后再尝试：要想crash可以分析core-dump，必须要安装这三个包：安装完后，我们可以利用find / -name vmlinux上面的crash爆出了：报错，这是由于kernel-debuginfo-common-x86_64包的版本和本机内核版本不一致照成的。

（说下：要想使用crash，只要保证debuginfo的版本和你要分析的core的内核版本本机的kernel版本三者的版本必须一样，任意一个不一致都会导致不能分析dump）##选择包和版本#再选择show debug package找到debug包下载就可以了----------------------------------------然后安装一下：#安装包开始++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++至于我们怎么知道coredump的内核版本，可以cd /var/crash/127.0.0.1---------/然后执行strings vmcore |grep 'OSRELEASE'可以显示出vmcore的内核版本顺便附一下内核版本和系统版本的对应关系CentOS 6.0/RHEL6 Update 0 -------------------> 2.6.32-71CentOS 6.1/RHEL6 Update 1 -------------------> 2.6.32-131CentOS 6.2/RHEL6 Update 2 -------------------> 2.6.32-220CentOS 6.3/RHEL6 Update 3 -------------------> 2.6.32-279CentOS 6.4/RHEL6 Update 4 -------------------> 2.6.32-358CentOS 6.5/RHEL6 Update 5 -------------------> 2.6.32-431CentOS 6.6/RHEL6 Update 6 -------------------> 2.6.32-504++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ #后再分析下dump可以进crash模式了。

linuxcrash用法

linuxcrash用法Linux Crash 是一个用于分析和调试Linux 操作系统崩溃的工具。

它提供了强大的功能和命令，帮助系统管理员和开发人员快速诊断和解决系统崩溃问题。

本文将一步一步回答关于Linux Crash 的使用方法和常见问题。

第一步：安装Linux Crash使用Linux Crash 之前，首先需要安装该工具。

大多数Linux 发行版都有一个软件仓库，可以从中安装Linux Crash。

不过，你也可以从源代码进行安装。

在终端中运行以下命令来安装Crash ：sudo apt-get install crash或者，从源代码安装：git clone git:github/crash-utility/crash.gitcd crashmakesudo make install安装完成后，你可以在终端中输入crash 命令来启动Linux Crash 。

第二步：收集崩溃转储文件在使用Linux Crash 之前，你需要一个崩溃的转储文件。

转储文件包含了崩溃时系统的内存状态和调试信息，以便于Crash 进行分析。

通常情况下，转储文件位于/var/crash 目录下。

你可以使用以下命令来查找转储文件：ls /var/crash如果没有找到转储文件，你可以尝试使用以下命令来生成一个崩溃：echo c > /proc/sysrq-trigger这会触发一个崩溃，并生成一个转储文件。

第三步：分析崩溃转储文件当你有了一个崩溃的转储文件后，你可以使用Crash 工具来分析它。

在终端中输入以下命令：crash /path/to/dumpfile其中，/path/to/dumpfile 是你的转储文件的路径。

Crash 会启动并加载转储文件。

第四步：使用Crash 命令来分析崩溃一旦Crash 启动并加载了转储文件，你可以使用各种Crash 命令来分析崩溃。

以下是一些常用的Crash 命令：1. bt：显示当前调用栈的回溯。

在linux下利用程序崩溃后的core文件分析bug(转载)

当我们的程序崩溃时，内核有可能把该程序当前内存映射到core文件里，方便程序员找到程序出现问题的地方。

最常出现的，几乎所有C程序员都出现过的错误就是“段错误”了。

也是最难查出问题原因的一个错误。

下面我们就针对“段错误”来分析core文件的产生、以及我们如何利用core文件找到出现崩溃的地方。

何谓core文件当一个程序崩溃时，在进程当前工作目录的core文件中复制了该进程的存储图像。

core文件仅仅是一个内存映象(同时加上调试信息)，主要是用来调试的。

当程序接收到以下UNIX信号会产生core文件：在系统默认动作列，“终止w/core”表示在进程当前工作目录的core文件中复制了该进程的存储图像（该文件名为core，由此可以看出这种功能很久之前就是UNIX功能的一部分）。

大多数UNIX 调试程序都使用core文件以检查进程在终止时的状态。

core文件的产生不是POSIX.1所属部分,而是很多UNIX版本的实现特征。

UNIX第6版没有检查条件(a)和(b)，并且其源代码中包含如下说明：“如果你正在找寻保护信号，那么当设置-用户-ID命令执行时，将可能产生大量的这种信号”。

4.3 + BSD产生名为core.prog的文件，其中prog是被执行的程序名的前1 6个字符。

它对core文件给予了某种标识，所以是一种改进特征。

表中“硬件故障”对应于实现定义的硬件故障。

这些名字中有很多取自UNIX早先在DP-11上的实现。

请查看你所使用的系统的手册，以确切地确定这些信号对应于哪些错误类型。

下面比较详细地说明这些信号。

? SIGABRT 调用abort函数时产生此信号。

进程异常终止。

? SIGBUS 指示一个实现定义的硬件故障。

? SIGEMT 指示一个实现定义的硬件故障。

EMT这一名字来自PDP-11的emulator trap 指令。

? SIGFPE 此信号表示一个算术运算异常，例如除以0，浮点溢出等。

? SIGILL 此信号指示进程已执行一条非法硬件指令。

Linux crash工具

什么是 crash如前文所述，当 linux 系统内核发生崩溃的时候，可以通过 kdump 等方式收集内核崩溃之前的内存，生成一个转储文件 vmcore。

内核开发者通过分析该 vmcore 文件就可以诊断出内核崩溃的原因，从而进行操作系统的代码改进。

那么 crash 就是一个被广泛使用的内核崩溃转储文件分析工具，掌握 crash 的使用技巧，对于定位问题有着十分重要的作用。

回页首使用 crash 的先决条件由于 crash 用于调试内核崩溃的转储文件，因此使用 crash 需要依赖如下条件：1. kernel 映像文件 vmlinux 在编译的时候必须指定了 -g 参数，即带有调试信息。

2. 需要有一个内存崩溃转储文件（例如 vmcore），或者可以通过 /dev/mem 或/dev/crash 访问的实时系统内存。

如果 crash 命令行没有指定转储文件，则 crash 默认使用实时系统内存，这时需要 root 权限。

3. crash 支持的平台处理器包括：x86, x86_64, ia64, ppc64, arm, s390, s390x ( 也有部分 crash 版本支持 Alpha 和 32-bit PowerPC，但是对于这两种平台的支持不保证长期维护 )。

4. crash 支持 2.2.5-15（含）以后的 Linux 内核版本。

随着 Linux 内核的更新，crash 也在不断升级以适应新的内核。

回页首crash 安装指南要想使用 crash 调试内核转储文件，需要安装 crash 工具和内核调试信息包。

不同的发行版安装包名称略有差异，这里仅列出 RHEL 和 SLES 发行版对应的安装包名称如下：表 1. crash 工具和内核调试包系统版本crash 工具名称内核调试信息包RHEL6.2 crash kernel-debuginfo-commonkernel-debuginfoSLES11SP2 crash kernel-default-debuginfokernel-ppc64-debuginfo以 RHEL 为例，安装 crash 及内核调试信息包的步骤如下：rpm -ivh crash-5.1.8-1.el6.ppc64.rpmrpm -ivh kernel-debuginfo-common-ppc64-2.6.32-220.el6.ppc64.rpmrpm -ivh kernel-debuginfo-2.6.32-220.el6.ppc64.rpm回页首启动 crash启动参数说明使用 crash 调试转储文件，需要在命令行输入两个参数：debug kernel 和 dump file，其中 dump file 是内核转储文件的名称，debug kernel 是由内核调试信息包安装的，不同的发行版名称略有不同，以 RHEL 和 SLES 为例：RHEL6.2：/usr/lib/debug/lib/modules/2.6.32-220.el6.ppc64/vmlinuxSLES11SP2：/usr/lib/debug/boot/vmlinux-3.0.13-0.27-ppc64.debug使用 crash -h 或 man crash 可以查看 crash 支持的一系列选项，这里仅以常用的选项为例说明如下：-h：打印帮助信息-d：设置调试级别-S：使用 /boot/System.map 作为默认的映射文件-s：不显示版本、初始调试信息等，直接进入命令行-i file：启动之后自动运行 file 中的命令，再接受用户输入crash 报告分析crash 命令启动后，会产生一个转储文件的分析报告摘要，如下图所示。

JDK6u18在64 bit Linux服务器高负荷下JVM crash分析

JDK6u18在64 bit Linux服务器高负荷下JVM crash分析# SIGSEGV (0xb) at pc=0x00002b77f64d663c, pid=9132, tid=1099491648## JRE version: 6.0_18-b07# Java VM: Java HotSpot(TM) 64-Bit Server VM (16.0-b13 mixed mode linux-amd64 )# Problematic frame:# V [libjvm.so+0x62263c]......--------------- T H R E A D ---------------Current thread (0x0000000044a40000): GCTaskThread [stack:0x000000004178e000,0x000000004188f000] [id=9135]siginfo:si_signo=SIGSEGV: si_errno=0, si_code=1 (SEGV_MAPERR),si_addr=0x000000000000001d......Stack: [0x000000004178e000,0x000000004188f000], sp=0x000000004188dcf0, freespace=3ff0000000000000018kNative frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)V [libjvm.so+0x62263c]V [libjvm.so+0x6230b0]V [libjvm.so+0x625672]V [libjvm.so+0x365dda]V [libjvm.so+0x5da2af]......Other Threads:0x0000000044a90800 VMThread [stack: 0x0000000040d30000,0x0000000040e31000][id=9143]0x00002aabb802a000 WatcherThread [stack: 0x00000000425eb000,0x00000000426ec000] [id=9150]=>0x0000000044a40000 (exited) GCTaskThread [stack:0x000000004178e000,0x000000004188f000] [id=9135]......HeapPSYoungGen total 1397056K, used 1396960K [0x00002aab5e0e0000, 0x00002aabb3630000, 0x00002aabb3630000)eden space 1396032K, 100% used[0x00002aab5e0e0000,0x00002aabb3430000,0x00002aabb3430000)from space 1024K, 90% used[0x00002aabb3530000,0x00002aabb3618000,0x00002aabb3630000)to space 1024K, 90% used[0x00002aabb3430000,0x00002aabb3518000,0x00002aabb3530000)PSOldGen total 2796224K, used 767465K [0x00002aaab3630000, 0x00002aab5e0e0000,0x00002aab5e0e0000)object space 2796224K, 27% used[0x00002aaab3630000,0x00002aaae23aa6d8,0x00002aab5e0e0000)PSPermGen total 21248K, used 21128K [0x00002aaaae230000, 0x00002aaaaf6f0000,0x00002aaab3630000)object space 21248K, 99% used[0x00002aaaae230000,0x00002aaaaf6d2100,0x00002aaaaf6f0000)表面原因为：JVM做JNI调用时错误退出，退出的线程是垃圾回收线程GCTaskThread，且当时程序使用的新生代堆内存和VM自己使用的永久内存使用率很大，负荷比较高。

故障排除 Linux操作系统死机处理方法总结

故障排除Linux操作系统死机处理方法总结通常在出现系统崩溃后，大家会担心再次出现故障，但是发现系统各日志中并没有记录到任何死机前后的信息，无法分析故障原因，认为已经无药可救。

但是，实际上，Linux 有多种机制来保证发生系统崩溃后，可以获取有价值的信息用以分析问题。

确定是硬件故障，还是应用程序bug 导致的。

Linux 中，有如下几种方法来获取各种崩溃时产生的信息。

1.Core dumpCore dump 通常用来调试应用程序错误，当某些应用程序运行出现异常崩溃时，可以开启系统的core dump 功能，来得到一个程序崩溃时的内存信息，用来分析崩溃原因：在/etc/profile里加上(或者修改)一条：ulimit -c 0运行命令：sysctl -w "kernel.core_name_format=/coredump/%n.core"该命令意思是指core文件放在/coredump目录下，文件名是进程名+.core2.Diskdumpdiskdump工具提供了在单机上创建和采集vmcore(kernel dump)的能力，而无须使用网络。

当内核本身出现崩溃的时候，当前的内存和CPU状态以及相关的信息都会被保存到一个支持diskdump的磁盘上的保留分区上。

在下一次重新启动的时候，当系统重新启动，diskdump的初始化脚本会从保留分区中读取保存的信息并创建一个vcore文件,然后这个文件被再次存放到/var/crash/目录下，文件名为127.0.0.1-如下是一个配置HP SCSI 设备上启用diskdump 的过程，如果不是HP SCSI 设备(即设备名为/dev/sdX的形式)，则无须执行第三、四两个步骤。

但需要在第一步前先执行命令：modprobediskdump第一步：编辑/etc/sysconfig/diskdump文件，将一个空白分区的设备名填入后保存退出，例如：DEVICE=/dev/cciss/c0d0p2第二步：初使化dump 设备#service diskdump initialformat警告：该分区的所以数据会丢失。

Crash使用参考

Crash使⽤参考整理⾃man 8 crash1、简介Crash⼯具可以⽤来分析⼀个正在运⾏的内核，也可以⽤来分析⼀个内核的crash dump⽂件，这⾥说的是内核代码异常产⽣的crash dump⽂件，不是应⽤层程序运⾏异常产⽣的core dump⽂件，它⽀持分析由netdump, diskdump, LKCD, kdump, xen‐dump 或者 kvmdump ⼯具产⽣的crash dump⽂件。

它整合了SVR4 UNIX crash的⼯具和GDB调试器，因⽽具有源码级别调试能⼒。

Crash⼯具可以⽤来分析内核的调⽤堆栈，内核源码的反汇编，内核数据结构和变量的格式化展⽰等等，另外Crash也可以传递⼀些GDB命令来执⾏。

在初始化的过程中，$HOME/.crashrc ⽂件中的命令和当前⽬录下的./.crashrc⽂件中的命令将会被执⾏。

Crash⼯具后向兼容，当内核版本变化导致Crash⼯具更新后后仍然会兼容以前的内核版本。

2、启动命令⾏crash [OPTION]... NAMELIST MEMORY-IMAGE[@ADDRESS] (⽤来分析dumpfile⽂件)crash [OPTION]... [NAMELIST] (⽤来分析正在运⾏的系统)NAMELIST：这个是未压缩的内核镜像⽂件(vmlinux)的路径，在⽤来分析dumpfile⽂件的时候也可以使⽤gzip或者bzip2压缩后的vmlinux⽂件。

MEMORY-IMAGE[@ADDRESS]：由netdump, diskdump, LKCD, kdump, xen‐dump 或者 kvmdump ⼯具产⽣的crash dump⽂件的路径，如果运⾏Crash⼯具没有输⼊这个参数的话，那么Crash⼯具将会⽤来分析正在运⾏的linux内核，分析正在运⾏的内核需要访问系统的RAM，⼀般是需要root权限的。

分析live system的时候，默认情况下/dev/crash将会被使⽤，如果这个⽂件不存在，然后会使⽤/dev/mem，但是如果kernel被配置为CONFIG_STRICT_DEVMEM，那么/proc/kcore将会被使⽤，也可以显式的指定/dev/crash、/dev/mem 、 /proc/kcore。

linux进程状态D和Z的处理

linux进程状态D和Z的处理长期生活在 Linux 环境里，渐渐地就有一种环保意识油然而生。

比如，我们会在登录提示里写上“悟空，我跟你说过叫你不要乱扔东西，乱扔东西是不对的。

哎呀我话没说完你怎么把棍子扔掉了？月光宝盒是宝物，乱扔它会污染环境，要是砸到小朋友怎么办？就算砸不到小朋友，砸到了花花草草也不好嘛...”；在用户缺省目录里放一个题为“自觉保护环境请勿堆放垃圾”的空文件，并用 chattr +i 设为不可修改；看到垃圾文件就立即扫入 /tmp 目录，然后发广播通知垃圾制造者自己去 /tmp 认领，且警告其下不为例...我们深知，系统环境的整洁有利于系统管理员保持良好的心情、清晰的思路和稳定的工作状态。

有一类垃圾却并非这么容易打扫，那就是我们常见的状态为 D (Uninterruptible sleep) ，以及状态为 Z (Zombie) 的垃圾进程。

这些垃圾进程要么是求而不得，像怨妇一般等待资源(D)，要么是僵而不死，像冤魂一样等待超度(Z)，它们在 CPU run_queue 里滞留不去，把 Load Average 弄的老高老高，没看过我前一篇blog的国际友人还以为这儿民怨沸腾又出了什么大事呢。

怎么办？开枪！kill -9！看你们走是不走。

但这两种垃圾进程偏偏是刀枪不入的，不管换哪种枪法都杀不掉它们。

无奈，只好reboot，像剿灭禽流感那样不分青红皂白地一律扑杀！悟空，我们所运维的可是24*7全天候对外部客户服务的系统，怎么能动不动就 reboot ？我们的考核指标可是4个9(99.99%，全年计划外当机时间不得超过52分钟34秒)，又不是4个8，你稍微遇到点事就reboot，还要不要可用性了？再说，现在社会都开始奔和谐去了，我们对于 D 和 Z 这两种垃圾进程，也该尽可能采取慈悲手段，能解决其困难的，就创造条件，解决其实际困难，能消除其冤结的，就诵经烧纸，消除其前世冤结，具体问题应具体分析具体解决，滥杀无辜只会导致冤冤相报因果循环...$^#$%#%^@#贫僧还是回来说正题。

linux主机利用crash分析_var_crash_下的vmcore 的dump分析

Linux系统崩溃别慌这里有救援方法

Linux系统崩溃别慌这里有救援方法Linux系统崩溃别慌，这里有救援方法Linux是一种开源的操作系统，广泛应用于服务器、个人电脑以及嵌入式系统中。

虽然Linux系统稳定可靠，但是在使用过程中难免会出现系统崩溃的情况。

当系统崩溃时，很多人会感到惶恐不安，不知道如何处理。

本文将为大家介绍几种常见的Linux系统崩溃救援方法，帮助大家快速恢复系统正常运行。

一、查找并修复文件系统错误1. 进入恢复模式（Recovery Mode）当Linux系统启动失败时，可以通过进入恢复模式来修复文件系统错误。

启动电脑时，在grub引导界面选择进入恢复模式，然后按照提示选择“修复文件系统”选项。

2. 运行fsck命令进入恢复模式后，系统会自动以只读模式挂载文件系统。

在命令行中输入“fsck -y /dev/sdXY”命令，其中sdXY是你要修复的分区的设备文件名。

该命令会自动修复文件系统中的错误。

3. 重启系统修复完成后，输入“reboot”命令重启系统。

如果修复成功，系统将能够正常启动。

二、使用Live CD或USB1. 准备Live CD或USB准备一张Linux发行版的Live CD或制作一个Live USB。

这样可以利用Live环境登录系统并修复问题。

2. 启动电脑插入准备好的Live CD或USB，重启电脑。

在BIOS设置中将引导选项设置为从CD或USB启动。

3. 进入Live环境待系统启动完成后，选择“试用Live系统”选项进入Live环境。

4. 挂载系统分区在命令行中输入“sudo fdisk -l”命令查看挂载点，然后使用“sudo mount /dev/sdXY /mnt”命令将系统分区挂载到/mnt目录中。

5. 修复文件系统运行“sudo fsck -y /dev/sdXY”命令对文件系统进行修复。

6. 重新安装引导程序如果系统崩溃是由于引导程序错误导致的，可以通过重新安装引导程序解决。

在命令行中输入“sudo grub-install /dev/sdX”命令（注意将sdX替换为合适的设备文件名），然后运行“sudo update-grub”命令进行更新。

Linux内核Crash分析

Linux内核Crash分析在工作中经常会遇到一些内核crash的情况，本文就是根据内核出现crash后的打印信息，对其进行了分析，使用的内核版本为：Linux2.6.32。

每一个进程的生命周期内，其生命周期的范围为几毫秒到几个月。

一般都是和内核有交互，例如用户空间程序使用系统调用进入内核空间。

这时使用的不再是用户空间的栈空间，使用对应的内核栈空间。

对每一个进程来说，Linux内核都会把两个不同的数据结构紧凑的存放在一个单独为进程分配的存储空间中：一个是内核态的进程堆栈，另一个是紧挨进程描述符的数据结构thread_info,叫线程描述符。

内核的堆栈大小一般为8KB，也就是8192个字节，占用两个页。

在Linux-2.6.32内核中thread_info.h文件中有对内核堆栈的定义：1.#define THREAD_SIZE 8192在Linux内核中使用下面的联合结构体表示一个进程的线程描述符和内核栈，在内核中文件include/linux/sched.h。

1.union thread_union {2.struct thread_info thread_info;3.unsigned long stack[THREAD_SIZE/sizeof(long)];4.};该结构是一个联合体，我们在C语言书上看到过关于union的解释，在在C Programming Language 一书中对于联合体是这么描述的：1) 联合体是一个结构；2) 它的所有成员相对于基地址的偏移量都为0；3) 此结构空间要大到足够容纳最"宽"的成员；4) 其对齐方式要适合其中所有的成员；通过上面的描述可知，thread_union结构体的大小为8192个字节。

也就是stack数组的大小，类型是unsigned long类型。

由于联合体中的成员变量都是占用同一块内存区域，所以，在平时写代码时总有一个概念，对一个联合体的实例只能使用其中一个成员变量，否则会把原先变量给覆盖掉，这句话如果正确的话，必须要有一个前提假设，成员占用的字节数相同，当成员所占的字节数不同时，只会覆盖相应的字节。

linux kdump 实现原理

linux kdump 实现原理kdump是一种在Linux系统中实现内核转储（crash dump）的机制。

通过kdump，当系统发生严重错误导致宕机时，可以将当前内核的内存转储到硬盘中，以便开发人员对宕机时的内核状态进行分析和调试。

本文将介绍kdump的实现原理，包括其工作原理、内存镜像的生成和转储、以及kdump的配置和使用。

1. kdump的工作原理：kdump是通过利用Linux内核的kexec功能实现的。

kexec是一种Linux内核中的系统调用，可以直接启动一个新的内核镜像而无需重新引导硬件。

kdump利用kexec功能，在系统内核崩溃时，通过加载一个特殊的内核映像，再次启动一个小型的第二内核，这个第二内核称为crash内核。

2.内存镜像的生成和转储：在宕机之前，首先需要生成一个内存映像文件。

kdump通过使用原始内核的/proc/vmcore文件实现此目的。

当系统崩溃时，原始内核暂停所有正在运行的任务，然后通过kexec工具加载crash内核，并将crash内核的入口点和参数传递给它。

然后crash内核启动，将原始内核的物理内存转储到磁盘上的/proc/vmcore文件中。

这个过程叫做转储（crash dumping）。

3. kdump的配置和使用：在Linux系统中配置和使用kdump需要以下步骤：a.安装kexec-tools软件包：kexec-tools是一组用户空间工具，用于加载第二内核映像。

b.确保系统有足够的空闲内存：kdump需要一定数量的内存用于存储crash内核。

c.配置kdump内核参数：需要编辑/etc/default/kdump文件，设置crash内核的路径、内存大小、转储方式等参数。

d.配置grub文件并重启：需要编辑boot loader（如GRUB）的配置文件，启用kdump并设置重启后启动crash内核。

e.测试kdump：重启系统后，可以通过执行`sysctl -wkernel.panic_on_oops=1`命令来模拟系统崩溃并测试kdump的效果。

linux内核分析工具Dtrace、SystemTap、火焰图、crash等

linux内核分析⼯具Dtrace、SystemTap、⽕焰图、crash等<< System语⾔详解 >> 关于 SystemTap 的书。

我们在分析各种系统异常和故障的时候，通常会⽤到 pstack(jstack) /pldd/ lsof/ tcpdump/ gdb(jdb)/ netstat/vmstat/mpstat/truss(strace)/iostat/sar/nmon(top)等系列⼯具，这些⼯具从某个⽅⾯为我们提供了诊断信息。

但这些⼯具常常带有各类“副作⽤”，⽐如truss(见于 AIX/Solaris) 或者 strace(见于 Linux) 能够让我们检测我们应⽤的系统调⽤情况，包括调⽤参数和返回值，但是却会导致应⽤程序的性能下降；这对于诊断毫秒级响应的计费⽣产系统来说，影响巨⼤。

有没有⼀个⼯具，能够兼得上述所有⼯具的优点，⼜没有副作⽤呢？答案是有！对于 Solaris/BSD/OS X 系统来说，那就是 DTrace ⼯具（后来，Linux 也终于有了⾃⼰类似的⼯具，stap）。

DTrace 的优势是什么呢？可以这么讲，如果你对于 OS 和应⽤熟悉，利⽤ DTrace 可以诊断所有问题；没错，是“所有”，“所有”，“所有”，重要的事情说三遍！书籍：DTrace-Dynamic-Tracing-in-Oracle-Solaris-Mac-OS-X-and-FreeBSD.pdf书籍：Solaris Dynamic Tracing Guide.pdf脚本⼯具集合：DTraceToolkit-0.99动态追踪技术（中） - Dtrace、SystemTap、⽕焰图说到动态追踪就不能不提到。

DTrace 算是现代动态追踪技术的⿐祖了，它于 21 世纪初诞⽣于 Solaris 操作系统，是由原来的 Sun Microsystems 公司的⼯程师编写的。

可能很多同学都听说过 Solaris 系统和 Sun 公司的⼤名。

Linux系统进程崩溃日志分析脚本

Linux系统进程崩溃日志分析脚本尽管Linux系统一直以来都被认为是稳定可靠的操作系统，但是在某些情况下，进程崩溃仍然会发生。

当进程崩溃时，系统会生成相应的日志文件，这些日志文件包含了进程崩溃的详细信息。

为了更好地理解崩溃的原因以及采取相应的措施，我们可以编写一个Linux系统进程崩溃日志分析脚本。

脚本的主要目标是自动化分析日志文件，提取有用的信息，并将其呈现给管理员。

下面，我将介绍脚本的主要功能和使用步骤。

## 功能介绍1. 日志文件路径设置：脚本允许管理员通过指定日志文件的路径来进行分析。

这样的设置将在脚本的开头进行，在此之后，脚本将基于指定的路径来读取日志文件。

2. 进程崩溃信息提取：脚本将从日志文件中提取关键信息，包括崩溃原因、崩溃的时间和进程的相关信息。

脚本将使用字符串匹配和正则表达式来查找和提取这些信息。

3. 崩溃原因分类：脚本将根据崩溃原因对日志进行分类。

这将有助于管理员更好地理解崩溃的原因，并采取相应的措施。

4. 分析报告生成：脚本将生成分析报告，其中包括进程崩溃的统计信息和分类结果。

报告将以易读的方式呈现，并提供相应的建议和解决方案。

## 使用步骤1. 设置日志文件路径：在脚本的开头，管理员可以设置要分析的日志文件的路径。

确保指定的路径是正确的，以便脚本能够找到并读取日志文件。

2. 运行脚本：运行脚本时，它将读取指定路径下的日志文件，并自动进行分析。

脚本将显示进程崩溃的统计信息和分类结果。

3. 查看分析报告：脚本将生成一个分析报告文件，其中包含了进程崩溃的详细信息和建议。

管理员可以查看报告并根据需要采取相应的措施。

## 示例代码以下是一个简单的示例代码，展示了如何实现Linux系统进程崩溃日志分析脚本：```bash#!/bin/bash# 设置日志文件路径log_path="/var/log/syslog"# 提取崩溃信息crash_logs=$(grep -i "crash" $log_path)# 崩溃原因分类memory_crash=$(grep -i "out of memory" <<< $crash_logs)disk_crash=$(grep -i "disk I/O error" <<< $crash_logs)network_crash=$(grep -i "network failure" <<< $crash_logs)# 生成分析报告report_path="/tmp/crash_analysis_report.txt"echo "进程崩溃日志分析报告" > $report_pathecho "===================" >> $report_pathecho "崩溃统计信息：" >> $report_pathecho "---------------" >> $report_pathecho "总崩溃次数：$(wc -l <<< $crash_logs)" >> $report_path echo "内存崩溃次数：$(wc -l <<< $memory_crash)" >> $report_path echo "硬盘崩溃次数：$(wc -l <<< $disk_crash)" >> $report_path echo "网络崩溃次数：$(wc -l <<< $network_crash)" >> $report_path echo "" >> $report_pathecho "崩溃分类结果：" >> $report_pathecho "---------------" >> $report_pathecho "内存崩溃：$memory_crash" >> $report_pathecho "硬盘崩溃：$disk_crash" >> $report_pathecho "网络崩溃：$network_crash" >> $report_pathecho "分析报告已生成：$report_path"```以上示例代码只是一个简单的实现，实际的脚本可以根据需求进行更多的定制和改进。

crash rd命令的用法

crash rd命令的用法Crashrd命令是Linux系统中的一个非常有用的调试工具，它可以用来生成内核崩溃转储文件，并且可以在系统崩溃时自动执行。

在本文中，我们将介绍如何使用Crash rd命令来进行Linux系统的调试。

首先，我们需要安装Crash工具包，可以通过执行以下命令来进行安装：sudo apt-get install crash安装完成后，我们可以使用以下命令来生成内核崩溃转储文件： sudo crash /usr/lib/debug/boot/vmlinux-$(uname -r)/var/crash/$(uname -n)-$(date +%Y%m%d-%H%M).dump在上面的命令中，/usr/lib/debug/boot/vmlinux-$(uname -r)表示内核映像文件的路径，/var/crash/$(uname -n)-$(date+%Y%m%d-%H%M).dump表示崩溃转储文件的路径和文件名。

执行该命令后，我们可以在指定的路径中找到生成的崩溃转储文件。

接下来，我们使用以下命令来打开Crash rd命令行界面：sudo crash /usr/lib/debug/boot/vmlinux-$(uname -r)/var/crash/$(uname -n)-$(date +%Y%m%d-%H%M).dump在Crash rd命令行界面中，我们可以使用以下命令来进行调试： - bt：显示当前进程的函数调用栈。

- ps：显示当前系统中的所有进程。

- lsmod：显示当前系统中加载的所有模块。

- vm：显示当前系统中的虚拟内存布局。

- log：显示内核日志。

除了上述命令之外，还有许多其他的命令可以使用。

通过使用Crash rd命令，我们可以更加方便地进行Linux系统的调试和分析。

Linux宕机故障分析案例

Linux宕机故障分析案例Linux宕机故障分析案例马化辉背景在Linux系统环境下，服务器宕机发⽣的频率⽐较⼩，但是不少⼯程师或多或少都会遇到这种情况，有时候会⼿⾜⽆措，不知从何⼊⼿。

笔者将借助⼀次案例分析，展⽰下Linux宕机故障事件的处理⽅法和思路。

宕机发⽣的原因不⼀，或者是硬件原因，或者是性能原因，或者是服务器触发了Linux的bug，导致内核崩溃等等。

案例分析1、案情还原；⽣产系统服务器dcspodsaa1在4⽉25⽇凌晨00：49分发⽣服务器宕机故障，当时系统管理员对硬件报错进⾏了截图（保留现场很重要），看字⾯意思应该是服务器的swap设备发⽣损坏：2、分析⽅法⼀：使⽤sosreport收集系统⽇志，检查/var/log/messages⽇志，查找系统重启前是否存在错误⽇志，图中kernel***/proc/kmsg started代表系统启动的第⼀条⽇志，在此之前没有发现异常⽇志，3、分析⽅法⼆：检查服务器开启了kdump服务，并在/var/crash⽬录找到了当天⽣成的vmcore⽂件,使⽤crash⼯具分析vmcore⽂件，如下：服务器发⽣了严重的系统崩溃panic错误对kdmp⽂件的错误⽇志进⾏分析，发现了⼤量的swap 设备读写错误：5、分析⽅法三：检查系统历史性能记录，/var/log/sa/路径下记录了每天由sysstat服务收集的sar（system activity report）⽂件，默认每10分钟记录⼀次系统资源使⽤情况的信息，包括CPU、内存等。

通过sar命令查看系统宕机时负载情况，没有发现资源使⽤异常，基本可以排除不是系统因性能不⾜从⽽导致宕机4.25号性能记录⽂件使⽤命令sar –A –F sa25 | more检查CPU性能信息和内存性能信息，没有发现异常情况。

其他配置1. 开启kdump：安装依赖包启动服务设置开启启动修改默认crashkernel参数为256M, 注意需重启系统才⽣效2. 使⽤crash⼯具分析vmcore⽂件：1) 安装crash包，可使⽤yum安装2) 安装kernel-debug内核版本，该rpm包必需和故障系统的内核版本⼀致先使⽤unamre –r查看故障机版本安装相应包3) 启动crash检查⼩结因此，在处理故障时，⼀般的思路是：1. ⾸先应查找故障前的错误⽇志线索，可以通过检查系统messages⽇志中的错误⽇志；2. 如果没有，进⽽排查系统是否触发kdump服务（在系统由于内核崩溃⽽导致宕机时，可以捕获故障时内存中的故障信息）；3. 另外也需要分析系统资源（CPU、内存等）使⽤上出现异常。

Linux内核崩溃原因分析及错误跟踪技术

Linux内核崩溃原因分析及错误跟踪技术随着嵌入式Linux系统的广泛应用，对系统的可靠性提出了更高的要求，尤其是涉及到生命财产等重要领域，要求系统达到安全完整性等级3级以上[1]，故障率（每小时出现危险故障的可能性）为10-7以下，相当于系统的平均故障间隔时间（MTBF）至少要达到1141年以上，因此提高系统可靠性已成为一项艰巨的任务。

对某公司在工业领域14 878个控制器系统的应用调查表明，从2004年初到2007年9月底，随着硬软件的不断改进，根据错误报告统计的故障率已降低到2004年的五分之一以下，但查找错误的时间却增加到原来的3倍以上。

这种解决问题所需时间呈上升的趋势固然有软件问题，但缺乏必要的手段以辅助解决问题才是主要的原因。

通过对故障的统计跟踪发现，难以解决的软件错误和从发现到解决耗时较长的软件错误都集中在操作系统的核心部分，这其中又有很大比例集中在驱动程序部分[2]。

因此，错误跟踪技术被看成是提高系统安全完整性等级的一个重要措施[1]，大多数现代操作系统均为发展提供了操作系统内核“崩溃转储”机制，即在软件系统宕机时，将内存内容保存到磁盘[3]，或者通过网络发送到故障服务器[3]，或者直接启动内核调试器[4]等，以供事后分析改进。

基于Linux操作系统内核的崩溃转储机制近年来有以下几种：(1) LKCD（Linux Kernel Crash Dump）机制[3];(2) KDUMP（Linux Kernel Dump）机制[4]；(3) KDB机制[5]；(4) KGDB机制[6]。

综合上述几种机制可以发现,这四种机制之间有以下三个共同点：(1) 适用于为运算资源丰富、存储空间充足的应用场合；(2) 发生系统崩溃后恢复时间无严格要求；(3) 主要针对较通用的硬件平台，如X86平台。

在嵌入式应用场合想要直接使用上列机制中的某一种，却遇到以下三个难点无法解决：(1) 存储空间不足嵌入式系统一般采用Flash作为存储器，而Flash容量有限，且可能远远小于嵌入式系统中的内存容量。

crash分析vmcore

crash分析vmcore如何使⽤crash分析vmcore - 之基础思路case1dmesg查看内核⽇志[2493382.671020] systemd-shutdown[1]: Sending SIGKILL to PID 28975 (docker-containe).[2493382.671078] systemd-shutdown[1]: Sending SIGKILL to PID 29015 (systemd).[2493420.208723] EXT4-fs (nvme0n1p1): sb orphan head is140906170[2493420.209198] sb_info orphan list:[2493420.209663] inode nvme0n1p1:140906170 at ffff88490edabfb8: mode 100666, nlink 0, next 149423507[2493420.210129] inode nvme0n1p1:149423507 at ffff8801b99391a8: mode 100666, nlink 0, next 17567381[2493420.210583] inode nvme0n1p1:17567381 at ffff8806d4a26998: mode 100744, nlink 0, next 17570510[2493420.211050] inode nvme0n1p1:17570510 at ffff886387f82ef8: mode 100644, nlink 0, next 17570503[2493420.211508] inode nvme0n1p1:17570503 at ffff886a1f15bfb8: mode 100644, nlink 0, next 241700498[2493420.211966] inode nvme0n1p1:241700498 at ffff8877481800e8: mode 100644, nlink 0, next 243138756[2493420.212431] inode nvme0n1p1:243138756 at ffff88761ad10518: mode 100644, nlink 0, next 241565954[2493420.212900] inode nvme0n1p1:241565954 at ffff8870d64bbfb8: mode 100755, nlink 0, next 241566333[2493420.213366] inode nvme0n1p1:241566333 at ffff88721ae74c48: mode 100644, nlink 0, next 241050093[2493420.213833] inode nvme0n1p1:241050093 at ffff887704958948: mode 100755, nlink 0, next 241567324[2493420.214545] ------------[ cut here ]------------[2493420.219336] kernel BUG at fs/ext4/super.c:879! <<<======这⾥指明BUG的代码位置[2493420.223948] invalid opcode: 0000 [#1] SMP[2493420.228133] Modules linked in: kpatch_D751550(OE) kpatch_D631237(OE) unix_diag(E) af_packet_diag(E) netlink_diag(E) dccp_diag(E) dccp(E) tcp_diag(E) udp_diag(E) inet_diag(E) [last unloaded: aisqos_hotfixes] [2493420.246846] CPU: 58 PID: 1 Comm: systemd-shutdow Tainted: G W OE K 4.9.79-009.ali3000.alios7.x86_64 #1[2493420.257009] Hardware name: Inventec AliServer Thor01-2U /TB800G4-G1 , BIOS A1.2003/06/2018[2493420.267339] task: ffff887e45918000 task.stack: ffffc90000014000[2493420.273425] RIP: 0010:[<ffffffffa031a8df>] [<ffffffffa031a8df>] ext4_put_super+0x36f/0x3c0 [ext4] <<<=======这⾥指明BUG的代码位置[2493420.282593] RSP: 0018:ffffc90000017de8 EFLAGS: 00010206[2493420.288079] RAX: ffff88490edabf50 RBX: ffff887e43299000 RCX: 00000001949b336d[2493420.295384] RDX: 0000000000000000 RSI: 0000000000000206 RDI: 0000000000000206[2493420.302682] RBP: ffffc90000017e18 R08: 00000000000081a4 R09: 0000000000000000[2493420.309988] R10: 0000000000000cb8 R11: 0000000000001e92 R12: ffff887e43299278[2493420.317293] R13: ffff887e43298800 R14: ffff887e43299278 R15: ffffffffa034ff88[2493420.324598] FS: 00007f3241ccf840(0000) GS:ffff887e78480000(0000) knlGS:0000000000000000[2493420.332850] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[2493420.338767] CR2: 00007f5e1372fbd0 CR3: 00000004daa52000 CR4: 00000000007606f0[2493420.346065] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[2493420.353361] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400[2493420.360660] PKRU: 55555554[2493420.363536] Stack:[2493420.365721] 9cbae75a00000000 ffff887e43298800 ffffffffa034a5e0 ffff887e3818c7b8[2493420.373365] 0000000000000000 ffff887e45918bb0 ffffc90000017e38 ffffffff81244aaf[2493420.380991] 0000000000000083 ffff887e357b8680 ffffc90000017e58 ffffffff81244e37[2493420.388617] Call Trace:[2493420.391239] [<ffffffff81244aaf>] generic_shutdown_super+0x6f/0x100[2493420.397676] [<ffffffff81244e37>] kill_block_super+0x27/0x70[2493420.403508] [<ffffffff81244f73>] deactivate_locked_super+0x43/0x70[2493420.409945] [<ffffffff8124547a>] deactivate_super+0x5a/0x60[2493420.415770] [<ffffffff81264b2f>] cleanup_mnt+0x3f/0x90[2493420.421169] [<ffffffff81264bc2>] __cleanup_mnt+0x12/0x20[2493420.426733] [<ffffffff810a7b50>] task_work_run+0x80/0xa0[2493420.432306] [<ffffffff810032ba>] exit_to_usermode_loop+0xaa/0xb0[2493420.438572] [<ffffffff81003baa>] syscall_return_slowpath+0xaa/0xb0[2493420.445011] [<ffffffff8171a783>] entry_SYSCALL_64_fastpath+0xc3/0xc5[2493420.451623] Code: 6004000048 8b 80 e0 0000 <0f> 0b 49 c7 c7 88 ff 34 a0 49 8b[2493420.459829] RIP [<ffffffffa031a8df>] ext4_put_super+0x36f/0x3c0 [ext4][2493420.466633] RSP <ffffc90000017de8>crash>通过dmesg⽇志，我们可以通过两个⽅法判断 bug的代码位置：1. [2493420.219336] kernel BUG at fs/ext4/super.c:879!2. [2493420.273425] RIP: 0010:[<ffffffffa031a8df>] [<ffffffffa031a8df>] ext4_put_super+0x36f/0x3c0 [ext4]其中（0x36f代表和ext4_put_super函数⼊⼝的偏移量，0x3c0是基准地址）从2找到代码crash的具体位置：(gdb) p 0x36f$11 = 879反汇编函数，找到位置crash> dis -l ext4_put_super在crash中查看代码crash本⾝是可以查看代码的，前提是你需要加载模块，⽐如：加载模块ext4：crash> mod -s ext4crash> mod <<----列出所有的模块crash> l *ext4_put_super+0x36f0xffffffffa031a8df is in ext4_put_super (fs/ext4/super.c:879).874 * isn't empty. The on-disk one can be non-empty if we've875 * detected an error and taken the fs readonly, but the876 * in-memory list had better be clean by this point. */877if (!list_empty(&sbi->s_orphan))878 dump_orphan_list(sb, sbi);879 J_ASSERT(list_empty(&sbi->s_orphan));880881 sync_blockdev(sb->s_bdev);882 invalidate_bdev(sb->s_bdev);883if (sbi->journal_bdev && sbi->journal_bdev != sb->s_bdev) {只有当我们找到具体的代码，才能进⼀步分析代码，究竟为什么会crash，⽐如，这个函数的参数（可能是某个struct）的值到底是什么？bt打印栈bt栈[exception RIP: ext4_put_super+879]有可以看到是在函数ext4_put_super的第879⾏crash> btPID: 1 TASK: ffff887e45918000 CPU: 58 COMMAND: "systemd-shutdow"#0 [ffffc90000017a58] machine_kexec at ffffffff810603e8#1 [ffffc90000017ab8] __crash_kexec at ffffffff811211cd#2 [ffffc90000017b80] __crash_kexec at ffffffff811212a5#3 [ffffc90000017b98] crash_kexec at ffffffff811212eb#4 [ffffc90000017bb8] oops_end at ffffffff81030905#5 [ffffc90000017be0] die at ffffffff81030ddb#6 [ffffc90000017c10] do_trap at ffffffff8102df02#7 [ffffc90000017c60] do_error_trap at ffffffff8102e2d9#8 [ffffc90000017d20] do_invalid_op at ffffffff8102e830#9 [ffffc90000017d30] invalid_op at ffffffff8171b63e[exception RIP: ext4_put_super+879]RIP: ffffffffa031a8df RSP: ffffc90000017de8 RFLAGS: 00010206RAX: ffff88490edabf50 RBX: ffff887e43299000 RCX: 00000001949b336dRDX: 0000000000000000 RSI: 0000000000000206 RDI: 0000000000000206RBP: ffffc90000017e18 R8: 00000000000081a4 R9: 0000000000000000R10: 0000000000000cb8 R11: 0000000000001e92 R12: ffff887e43299278R13: ffff887e43298800 R14: ffff887e43299278 R15: ffffffffa034ff88ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018#10 [ffffc90000017de0] ext4_put_super at ffffffffa031a91c [ext4]#11 [ffffc90000017e20] generic_shutdown_super at ffffffff81244aaf#12 [ffffc90000017e40] kill_block_super at ffffffff81244e37#13 [ffffc90000017e60] deactivate_locked_super at ffffffff81244f73#14 [ffffc90000017e80] deactivate_super at ffffffff8124547a#15 [ffffc90000017e98] cleanup_mnt at ffffffff81264b2f#16 [ffffc90000017eb0] __cleanup_mnt at ffffffff81264bc2#17 [ffffc90000017ec0] task_work_run at ffffffff810a7b50#18 [ffffc90000017f00] exit_to_usermode_loop at ffffffff810032ba#19 [ffffc90000017f30] syscall_return_slowpath at ffffffff81003baa#20 [ffffc90000017f50] entry_SYSCALL_64_fastpath at ffffffff8171a783RIP: 00007f3241195c47 RSP: 00007fffb3db5438 RFLAGS: 00000246RAX: 0000000000000000 RBX: 0000560b87fbd920 RCX: 00007f3241195c47RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000560b87fbdd10RBP: 0000560b87fbda00 R8: 0000000000000000 R9: 00007f32410e416dR10: 0000000000000021 R11: 0000000000000246 R12: 0000560b87fbdd10R13: 00007fffb3db5538 R14: 00007fffb3db5523 R15: 0000000000000000ORIG_RAX: 00000000000000a6 CS: 0033 SS: 002bcrash>反汇编上下函数当我们，分析到了出错的具体的代码⾏，下⼀步需要分析，传⼊的参数和struct⾸先，我们需要看下函数ext4_put_super的原型，发现是static void ext4_put_super(struct super_block *sb),只有⼀个参数，⽽且是⼀个结构体struct super_block, 现在我们需要知道*sb指针的地址是多少呢？那这个地址肯定是上个函数generic_shutdown_super传递给它的.现在分析的关键是，我们需要知道,当generic_shutdown_super在ffffffff81244aaf处，调⽤到ext4_put_super的时候，传给ext4_put_super的指针地址是多少？⾸先，需要反汇编函数generic_shutdown_super找到地址ffffffff81244aafcrash> dis -l generic_shutdown_super/usr/src/debug/kernel-4.9.79-009.ali3000/linux-4.9.79-009.ali3000.alios7.x86_64/fs/super.c: 4360xffffffff81244aa0 <generic_shutdown_super+96>: mov 0x30(%r12),%rax0xffffffff81244aa5 <generic_shutdown_super+101>: test %rax,%rax0xffffffff81244aa8 <generic_shutdown_super+104>: je 0xffffffff81244aaf <generic_shutdown_super+111>/usr/src/debug/kernel-4.9.79-009.ali3000/linux-4.9.79-009.ali3000.alios7.x86_64/fs/super.c: 4370xffffffff81244aaa <generic_shutdown_super+106>: mov %rbx,%rdi <===rbx 和 rdi 数据⼀致0xffffffff81244aad <generic_shutdown_super+109>: callq *%rax <===在这⾥调⽤下个函数/usr/src/debug/kernel-4.9.79-009.ali3000/linux-4.9.79-009.ali3000.alios7.x86_64/include/linux/compiler.h: 2430xffffffff81244aaf <generic_shutdown_super+111>: mov 0x608(%rbx),%rax/usr/src/debug/kernel-4.9.79-009.ali3000/linux-4.9.79-009.ali3000.alios7.x86_64/fs/super.c: 4390xffffffff81244ab6 <generic_shutdown_super+118>: lea 0x608(%rbx),%rdx0xffffffff81244abd <generic_shutdown_super+125>: cmp %rax,%rdx0xffffffff81244ac0 <generic_shutdown_super+128>: jne 0xffffffff81244b1f <generic_shutdown_super+223>接着，反汇编ext4_put_super, 你会发现push了很多的寄存器的值到stackcrash> dis -l ext4_put_super/usr/src/debug/kernel-4.9.79-009.ali3000/linux-4.9.79-009.ali3000.alios7.x86_64/fs/ext4/super.c: 8240xffffffffa031a570 <ext4_put_super>: nopl 0x0(%rax,%rax,1) [FTRACE NOP]0xffffffffa031a575 <ext4_put_super+5>: push %rbp0xffffffffa031a576 <ext4_put_super+6>: mov %rsp,%rbp0xffffffffa031a579 <ext4_put_super+9>: push %r15 <===第1个寄存器⼊栈0xffffffffa031a57b <ext4_put_super+11>: push %r14 <===第2个寄存器⼊栈0xffffffffa031a57d <ext4_put_super+13>: push %r13 <===第3个寄存器⼊栈0xffffffffa031a57f <ext4_put_super+15>: push %r12 <===第4个寄存器⼊栈0xffffffffa031a581 <ext4_put_super+17>: mov %rdi,%r130xffffffffa031a584 <ext4_put_super+20>: push %rbx <===第5个寄存器⼊栈（rbx是在上个函数的时候，就有值的，所以，ext4_put_super函数的第⼀个参数的指针的地址就是这个寄存器的值）0xffffffffa031a585 <ext4_put_super+21>: sub $0x8,%rsp0xffffffffa031a589 <ext4_put_super+25>: mov 0x460(%rdi),%rbx/usr/src/debug/kernel-4.9.79-009.ali3000/linux-4.9.79-009.ali3000.alios7.x86_64/fs/ext4/super.c: 8260xffffffffa031a590 <ext4_put_super+32>: mov 0xe0(%rbx),%r14/usr/src/debug/kernel-4.9.79-009.ali3000/linux-4.9.79-009.ali3000.alios7.x86_64/fs/ext4/super.c: 8300xffffffffa031a597 <ext4_put_super+39>: callq 0xffffffffa03133f0 <ext4_unregister_li_request>crash> bt -f#10 [ffffc90000017de0] ext4_put_super at ffffffffa031a91c [ext4]ffffc90000017de8: 9cbae75a00000000( ) ffff887e43298800(第5个寄存器的值)ffffc90000017df8: ffffffffa034a5e0(第4个寄存器的值) ffff887e3818c7b8(第3个寄存器的值)ffffc90000017e08: 0000000000000000(第2个寄存器的值) ffff887e45918bb0(第1个寄存器的值)ffffc90000017e18: ffffc90000017e38 ffffffff81244aaf(这两个是不代表寄存器的)#11 [ffffc90000017e20] generic_shutdown_super at ffffffff81244aafffffc90000017e28: 0000000000000083 ffff887e357b8680ffffc90000017e38: ffffc90000017e58 ffffffff81244e37crash> struct super_block ffff887e43298800struct super_block {s_list = {next = 0xffffffff81cb3db0 <super_blocks>, <=======这⾥也验证了，就是地址ffff887e43298800表⽰的就是struct super_block prev = 0xffff887e43968800},s_dev = 271581185,s_blocksize_bits = 12'\f',s_blocksize = 4096,s_maxbytes = 17592186040320,s_type = 0xffffffffa03589c0 <ext4_fs_type>,s_op = 0xffffffffa034a5e0 <ext4_sops>,dq_op = 0xffffffffa034a720 <ext4_quota_operations>,s_qcop = 0xffffffff81843f60 <dquot_quotactl_sysfile_ops>,s_export_op = 0xffffffffa034a580 <ext4_export_ops>,s_flags = 805371904,s_iflags = 1,s_magic = 61267,s_root = 0x0,s_umount = {count = {counter = -4294967295},wait_list = {next = 0xffff887e43298878,prev = 0xffff887e43298878},wait_lock = {raw_lock = {val = {counter = 0}}。

linux crash的用法

linux crash的用法"Linux Crash"的用法引言：Linux是一种开源操作系统，它的稳定性和可靠性广受赞誉。

然而，就像任何其他操作系统一样，Linux也可能会出现崩溃的情况。

本文将详细探讨"Linux Crash"的用法，包括可能导致崩溃的因素以及如何应对和解决这些问题。

第一部分：Linux系统崩溃的原因1. 硬件故障：硬件故障是导致Linux系统崩溃的常见原因之一。

例如，内存故障、硬盘故障、电源问题等都可能导致系统无法正常运行。

2. 软件错误：软件错误也是Linux系统崩溃的常见原因之一。

例如，操作系统内核或其他关键软件的错误可能导致系统崩溃。

3. 驱动程序问题：Linux系统通常需要使用特定的驱动程序来与硬件设备进行交互。

不正确的驱动程序或驱动程序的冲突可能导致系统崩溃。

4. 内存管理问题：Linux系统使用虚拟内存管理机制来管理系统内存。

如果出现内存管理问题，例如内存泄漏或内存访问错误，系统可能会崩溃。

第二部分：应对Linux系统崩溃的步骤1. 重新启动系统：在系统崩溃后，第一步是尝试重新启动系统。

这可能是因为崩溃只是一个偶然事件，重新启动系统后问题可能会得到解决。

2. 分析错误日志：Linux系统通常会生成错误日志，记录系统崩溃时的相关信息。

通过分析错误日志，我们可以获得有关崩溃原因的线索，以便采取适当的措施。

- 使用命令"cat /var/log/syslog"来查看系统日志。

- 使用命令"dmesg"来查看内核日志。

3. 更新和修复软件：如果崩溃是由软件错误引起的，更新和修复软件可能是解决问题的方法之一。

通过使用包管理器来更新软件包，可以获得最新的错误修复和安全补丁。

- 在Debian或Ubuntu系统中，使用命令"apt-get update"和"apt-get upgrade"来更新软件包。