调试令人讨厌的SIGILL崩溃：文本段损坏
我们是一个运行Linux的基于PowerPC的嵌入式系统。 我们遇到了随机SIGILL崩溃，这种崩溃在各种应用程序中都可见。 崩溃的根本原因是将要执行的指令置零。 这表示驻留在内存中的文本段的损坏。 由于文本段是只读的，因此应用程序无法对其进行破坏。 所以我怀疑一些共同的子系统（DMA？）造成这种腐败。 由于问题需要数天才能重现（由于SIGILL而导致崩溃），因此调查变得越来越困难。 因此，首先我想知道是否以及何时应用程序的文本段已损坏。 我已经看过堆栈跟踪和所有的指针，寄存器是正确的。
你们有什么建议我可以去做吗？
一些信息：
Linux 3.12.19-rt30＃1 SMP Fri Mar 11 01:31:24 IST 2016 ppc64 GNU / Linux
（gdb）bt
xxx中的0 0x10457dc0
拆卸输出：
=> 0x10457dc0 <+80>：mr r1，r11
0x10457dc4 <+84>：blr
指令地址为0x10457dc0： 0x7d615b78
捕获SIGILL 0x10457dc0后发现指令： 0x00000000
（gdb）维护信息部分
0x10006c60-> 0x106cecac at 0x00006c60：.text ALLOC LOAD READONLY CODE HAS_CONTENTS
预期（来自应用程序二进制文件）：
（gdb）x / 32 0x10457da0
0x10457da0：0x913e0000 0x4bff4f5d 0x397f0020 0x800b0004
0x10457db0：0x83abfff4 0x83cbfff8 0x7c0803a6 0x83ebfffc
0x10457dc0： 0x7d615b78 0x4e800020 0x7c7d1b78 0x7fc3f378
0x10457dd0：0x4bcd8be5 0x7fa3eb78 0x4857e109 0x9421fff0
实际（在处理SIGILL并转储附近的内存位置之后）：
错误指令地址：0x10457dc0
0x10457da0：0x913E0000
0x10457db0：0x83ABFFF4
=> 0x10457dc0： 0x00000000
0x10457dd0：0x4BCD8BE5
0x10457de0：0x93E1000C
编辑：
我们所拥有的一个领导是腐败始终发生在以0xdc0结尾的偏移处。
例如
捕获SIGILL后，由我们的应用程序打印的错误指令地址： 0x10653dc0 <<
捕捉SIGILL后由我们的应用程序打印的错误指令地址： 0x1000ddc0 <<
flash_erase [8557]：未处理的信号4在0fed6dc0 nip 0fed6dc0 lr 0fed6dac编码30001
nandwrite [8561]：未处理的信号4在0fed6dc0 nip 0fed6dc0 lr 0fed6dac编码30001
awk [4448]：未处理的信号4在0fe09dc0 nip 0fe09dc0 lr 0fe09dbc code 30001
awk [16002]：未处理的信号4在0fe09dc0 nip 0fe09dc0 lr 0fe09dbc code 30001
getStats [20670]：未处理的信号4在0fecfdc0 nip 0fecfdc0 lr 0fecfdbc code 30001
expr [27923]：未处理的信号4在0fe74dc0 nip 0fe74dc0 lr 0fe74dc0 code 30001
编辑2：另一个主角是腐败总是发生在物理帧号0x00a4d。 我想用4096的PAGE_SIZE可以转换为0x00A4DDC0的物理地址。 我们怀疑我们的内核驱动程序，并进一步调查。 是否有更好的主意（比如放置硬件观察点）更有效率？ 如下所示，KASAN如何？
任何帮助表示赞赏。 谢谢。
1.）文本段是RO，但可以通过mprotect更改权限，如果您认为这是可能的，可以检查
2.）如果是内核问题：
3.）硬件。 我认为，你的问题看起来像一个硬件问题（内存问题）。
上一篇: Debugging a nasty SIGILL crash: Text Segment corruption