我们是一个运行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
拆卸输出：
=＆GT; 0x10457dc0＆lt; + 80＆gt;：mr r1，r11
0x10457dc4＆lt; + 84＆gt;：blr
预期地址为0x10457dc0的指令： 0x7d615b78
捕获SIGILL 0x10457dc0后发现的指令： 0x00000000
（gdb）维护信息部分
0x10006c60-＆gt; 0x106cecac位于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
=＆GT; 0x10457dc0： 0x00000000
0x10457dd0：0x4BCD8BE5
0x10457de0：0x93E1000C
编辑：
我们的一个主要原因是腐败始终发生在以0xdc0结尾的偏移处
例如
错误指令地址： 0x10653dc0 ＆lt;＆lt;在捕获SIGILL后由我们的应用程序打印
错误指令地址： 0x1000ddc0 ＆lt;＆lt;在捕获SIGILL后由我们的应用程序打印
flash_erase [8557]：未处理的信号4在 0fed6dc0 nip 0fed6dc0 lr 0fed6dac代码30001
nandwrite [8561]：未处理的信号4在 0fed6dc0 nip 0fed6dc0 lr 0fed6dac代码30001
awk [4448]：未处理信号4在 0fe09dc0 压区0fe09dc0 lr 0fe09dbc代码30001
awk [16002]：未处理的信号4在 0fe09dc0 压区0fe09dc0 lr 0fe09dbc代码30001
getStats [20670]：未处理的信号4在 0fecfdc0 nip 0fecfdc0 lr 0fecfdbc代码30001
expr [27923]：未处理的信号4在 0fe74dc0 nip 0fe74dc0 lr 0fe74dc0 code 30001
编辑2：另一个领导是腐败总是发生在物理帧号0x00a4d。我想，如果PAGE_SIZE为4096，则会转换为0x00A4DDC0的物理地址。我们怀疑我们的几个内核驱动程序并进一步调查。是否有更好的想法（比如放置硬件观察点）哪个更有效？如下所示，KASAN怎么样？
感谢任何帮助。感谢。