深入Linux Crash分析，解决故障问题 (linux crash 分析)
随着互联网的普及和计算机技术的发展，Linux系统越来越受到广泛的关注和应用。然而，随着系统的复杂度不断提升，Linux系统出现故障的情况也越来越普遍，这不仅影响到系统运行的稳定性，还影响到工作效率和用户体验。为了更好地解决Linux系统故障问题，本文将深入分析Linux Crash的原因，并提出解决方案。
一、Linux Crash常见原因
1.硬件故障：可能是内存、硬盘、网卡等硬件设备失效，导致系统无法正常工作。例如，硬盘损坏可能导致Linux系统无法启动，网卡故障可能导致网络连接失败。
2.软件相关的错误：可能是内核漏洞、驱动程序错误、进程崩溃等。例如，进程崩溃可能是由于内存泄漏或错误的代码实现导致，内核漏洞可能导致系统死机或崩溃。
3.配置错误：可能是由于错误的配置导致系统无法正常工作。例如，错误的配置IP地址、DNS服务器等，可能导致网络连接失败。
二、如何分析Linux Crash
对于Linux系统的Crash，我们需要进行详细的分析，以找到问题的原因，并采取相应的解决方法。
1.收集系统日志
包括系统日志、内核日志和应用程序日志。通过查看日志，可以得到系统的运行情况，从而找到系统在何时出现Crash。
2.查看内存信息
可以使用系统自带的工具来查看内存使用情况，如top和ps等工具。通过查看内存使用情况，可以找到是否存在内存泄漏等问题，从而排除内存问题引起的Crash。
3.使用Crash工具分析
Crash工具是一款开源的命令行调试工具，它可以帮助用户分析系统Crash时的内核转储文件。通过Crash工具的使用，可以找到内核中出现问题的位置，并查看相关的堆栈信息，从而找到问题的原因。
三、如何解决Linux Crash问题
一旦发现了Crash的原因，我们需要采取相应的解决方法以恢复系统的正常运行。以下是常见的Linux Crash解决方法。
1.检查硬件设备
如果是硬件故障引起的Crash，我们需要检查相应的硬件设备，如内存、硬盘、网卡等，找到问题并进行修复或更换。
2.升级或修复软件
如果是软件相关的问题引起的Crash，我们需要找到具体的软件问题，并进行升级或修复。例如，更新内核或者更新应用程序。
3.正确设置系统配置
如果是配置问题引起的Crash，我们需要找到问题，并进行正确的设置。例如，设置正确的IP地址、DNS服务器等配置信息。
结论
Linux Crash是Linux系统中常见的问题之一，它可能来自硬件故障、软件错误或者配置错误等多种因素。通过深入的分析、收集日志信息、查看内存信息以及使用Crash工具进行分析，我们可以找到问题的根本原因。一旦找到问题，我们就可以采取相应的措施，如升级软件、更换硬件设备或者设置正确的系统配置，以解决Linux Crash问题，保证系统的稳定运行。
相关问题拓展阅读：
怎样解决crash dump error
Memory错误
在内核中，内存是以cache的形式组织的，每个对象类型对应一个cache，如（inod_cache,dentry_cache, buffer_head,vm_area_strutct等）；每个cache包含多个slab(slab由一个或多个页组成，这些页物理上是连续的)；每个slab包含多烂氏个初始化的对象。
Cache可以分为两类【kmalloc使用的和其他】，当然他们是用同一个函数创建的。
1.Crash> Kmem -s
CACHE NAME OBIZE ALLOCATED TOTAL SLABS SSIZE
ee2bb0c0 scsi_sense_cachek
ee2bbac0 scsi_cmd_cachek
ee000c60 sizek
ee000bc0 sizek
ee000b20 sizek
ee000a80 sizek
ee0009e0 sizek
eesizek
ee0008a0 sizek
eesizek
eesizek
ee0006c0 sizek
eesizek
eesizek
ee0004e0 sizek
eesizek
ee0003a0 size 6 4k
eesizek
eesizek
ee0001c0 sizek
eesizek
eesizek
调用唯正函数kmalloc()得到的memory都来名字为size-xx的cache.
2.CONFIG_DEBUG_SLAB
为便于调试，在每个对象可以添加SLAB_RED_ZONE，添加这块内存的最后使用者SLAB_STORE_USER，且用SLAB_POISON初始化对象。
这些特殊的元素是什么？
Include/linux/poison.h
/*
*Magic nums for obj red zoning.
*Placed in the first word before and the first word after an obj.
*/
#define RED_INACTIVE 0x09F911029D74E35BULL /*when obj is inactive */
#define RED_ACTIVE 0xD84156CC0ULL /*when obj is active */
/*…and for poisoning */
#define POISON_INUSE 0x5a /*for use-uninitialised poisoning */
#definePOISON_FREE 0x6b /* foruse-after-free poisoning */
#define POISON_END 0xa5 /*end-byte of poisoning */
3.log | tail
当slab出错时，会把cachename/ objecet的开始地址(没有考虑redzone)
redzone的内容/lastuser和指历悔object的内容都会打印出来，另外还包含该对象前后对象的信息。
Slab corruption (Not tainted): size-64 start=e74b3398,len=64
Redzone: 0x9f911029d74e35b/0x9f911029d74e35b.
Last user: (__DWC_FREE+0x1c/0x20)
010: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b d8 b0 54 e8 kkkkkkkkkkkk..T.
Prev obj: start=e74b3340, len=64
Redzone: 0xd84156cc0/0xd84156cc0.
Last user:(binder_get_ref_for_node+0x6c/0x204)
000:c 8b e5 eG4..,………..
010: f1 31 4b ee5 ee.1K.P….Fa…..
Next obj: start=e74b33f0, len=64
Redzone: 0xd84156cc0/0xd84156cc0.
Last user: (copy_creds+0x108/0x1e4)
000:a 5a 5a 5aa 5a 5a 5a ….ZZZZ….ZZZZ
010: ad 4e ad de ff ff ff ff ff ff ff ff.N…………..
kernel BUG atmm/slab.c:2023!
Internal error: Oops – BUG: 0 PREEMPT P ARM
Modules linked in:
CPU: 0 Not tainted (3.4.0-gc37fe8c-dirty #657)
PC is at check_poison_obj+0x194/0x1b4
LR is at console_unlock+0x1c0/0x1d4
pc : lr : psr:
sp : e58e1c68 ip : e58e1a40 fp : e58e1c9c
r10: e74b3398 r9 :r8 : e74b3338
r7 :r6 : e74b3000 r5 : e74b33e8 r4 :ee000080
r3 :r2 :r1 :r0 :e74b33f0
Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel
Control: 10c53c7d Table: af4e404a DAC:
kmem-S size-64
从打印的信息siize-64start=e74b3398, 得知出问题的是cache:size-64,地址为
e74b3390.
4.Crash> kmem -S cache name
crash>kmem -S size-64 | grep e74b3390
crash>rd e74b3390 0x64
e74b3390: 9d74e35b 09fb6b6b6b6b6b6b6b
e74b33a0: 6b6b6b6b 6b6b6b6b 6b6b6b6b 6b6b6b6b kkkkkkkkkkkkkkkk
e74b33b0: 6b6b6b6b e854b0d8 6b6b6b6b6b6b6b6b kkkk..T.kkkkkkkk
e74b33c0: 6b6b6b6b 6b6b6b6b 6b6b6b6b 6b6b6b6b kkkkkkkkkkkkkkkk
e74b33d0: 6b6b6b6b a56b6b6b 9d74e35b09f91102 kkkkkkk.
e74b33e0: ffc03446e8
从出问题的这个object的用于debug的信息可知：
redzone: 9d74e35b 09f91102 :RED_INACTIVE
poisondata: 6b : POISON_FREE
usercall : c03446e8
5.last caller
最后操作这块内存的函数为：
crash>dis -r c03446e8
0xc03446cc: mov r12, sp
0xc03446d0: push {r11, r12, lr, pc}
0xc03446d4: sub r11, r12, #4
0xc03446d8: stmfd sp!, {lr}
0xc03446dc: ldmfd sp!, {lr}
0xc03446e0: mov r0, r1
0xc03446e4: bl 0xc00d51fc
0xc03446e8: ldm sp, {r11, sp, pc}
结合如下的backtrace，可知问题就是从slab申请的一个对象，但发现其中的元素不对(不是0x6b,却出现了e854b0d8，所以crash)
kernel BUG at mm/slab.c:2023!
Backtrace:
(check_poison_obj+0x0/0x1b4) from (cache_alloc_debugcheck_after+0x3c/0x1a0)
(cache_alloc_debugcheck_after+0x0/0x1a0) from (__kmalloc+0x140/0x234)
r7:r6:r5:ar4:ee000080
(__kmalloc+0x0/0x234) from (__DWC_ALLOC_ATOMIC+0x20/0x24)
(__DWC_ALLOC_ATOMIC+0x0/0x24) from (dwc_otg_hcd_urb_alloc+0x30/0x40)
(dwc_otg_hcd_urb_alloc+0x0/0x40)from (urb_enqueue+0xf0/0x258)
r4:db95faa8 r3:
(urb_enqueue+0x0/0x258) from (u_hcd_submit_urb+0x5c4/0x6a4)
(u_hcd_submit_urb+0x0/0x6a4) from (u_submit_urb+0x2a0/0x2bc)
(u_submit_urb+0x0/0x2bc) from (u_sg_wait+0x4c/0x138)
6.解决问题
从上面的分析可知，问题是memoryfree后，代码又操作了这块内存。
现在问题是__DWC_FREE最后操作了这块内存，__DWC_FREE只是封装了kfree,
如果直接使用kfree,通过SLAB_STORE_USER就可以知道那个函数调用了kfree,
进而知道申请的对象类型，看那个该对象类型的那个成员被赋值，就可以在代码中搜索。
如该例知道了类型为dwc_otg_qtd_t，且成员qh在内存释放后被赋值，就可以在代码中详细查找，分析。
crash>dwc_otg_qtd_t e74b3398
structdwc_otg_qtd_t {
data_toggle= 0x6b,
control_phase= (DWC_OTG_CONTROL_DATA | DWC_OTG_CONTROL_STATUS | unknown:),
complete_split= 0x6b,
ssplit_out_xfer_count= 0x6b6b6b6b,
error_count= 0x6b,
isoc_frame_index= 0x6b6b,
isoc_split_pos= 0x6b,
isoc_split_offset= 0x6b6b,
urb= 0x6b6b6b6b,
qh= 0xe854b0d8,
qtd_list_entry= {
cqe_next= 0x6b6b6b6b,
cqe_prev= 0x6b6b6b6b
},
in_process= 0x6b,
n_desc= 0x6b,
isoc_frame_index_last= 0x6b6b
}
在相关的代码中搜索哪里操作了
数据结构
dwc_otg_qtd_t的qh成员。
出现CrashDump：
重启电脑-按F8键，出现开机庆丛或菜单时，选择，最后一次正确设置，回车试试。郑源
或进入安全模式进入后杀毒、重启。
关于linux crash 分析的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。
