debugging令人讨厌的SIGILL崩溃：文本段损坏

我们是一个运行Linux的基于PowerPC的embedded式系统。 我们遇到了一个随机的SIGILL崩溃，可以看到各种各样的应用程序。 崩溃的根本原因是将要执行的指令清零。 这表示驻留在内存中的文本段的损坏。 由于文本段是只读的，应用程序不能破坏它。 所以我怀疑一些共同的子系统（DMA？）造成这种腐败。 由于问题需要数天的时间来重现（由于SIGILL引起的崩溃），因此调查变得越来越困难。 所以，首先我想能够知道任何应用程序的文本段是否以及何时被损坏。 我已经看了堆栈跟踪和所有的指针，寄存器是适当的。

你们有什么build议我可以去做吗？

一些信息：

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：另一个主angular是腐败总是发生在物理帧号0x00a4d。 我想用4096的PAGE_SIZE这个转换为物理地址0x00A4DDC0。 我们怀疑我们的内核驱动程序，并进一步调查。 有没有更好的主意（比如放硬件观察点）更有效率？ 如下所示，KASAN如何？

任何帮助表示赞赏。 谢谢。

1.）文本段是RO，但可以通过mprotect更改权限，如果您认为这是可能的，可以检查

2.）如果是内核问题：

用KASAN和Kubsan（未定义行为）消毒剂运行内核

关注不包括在主线中的驱动程序代码

这里的提示是一个字节的腐败。 也许我错了，但这意味着DMA不是怪罪。 它看起来像某种无效的商店。

3）硬件。 我认为，你的问题看起来像一个硬件问题（内存问题）。

您可以尝试降低引导加载程序中的RAM系统频率

检查这个问题是否在稳定的主线软件上复制，这就是你如何证明这一点