Debugging techniques inside kernel

[Joel Fernandes]

On Mon, Jul 8, 2013 at 11:19 AM,  <Valdis.Kletnieks at vt.edu> wrote:
> On Mon, 08 Jul 2013 08:18:02 -0700, Anand Arumugam said:
>
>> Try using strace and see if all of the different crashes have the same or similar looking call stack.
>
> strace is userspace, and *highly* unlikely to track down random memory
> corruption inside the kernel.  Random kernel corruption usually means that something
> *else* stomped on the memory - which in turn means that the syscall that
> finally trips over the corrupt memory is probably not the one that did it.
>
> Not saying it can't possibly do so, but it's not where I'd start.
>
> Might want to run memtest86+ or similar, help rule out dodgy memory.

Yes, that's a good idea. I'll also add that just turning on SLAB DEBUG
is a great test too. I've able to catch dodgy memory, that didn't get
caught using memtest, but would fail after turning on slab debugging.
That bit of code really hammers the memory. Not even the hardware
diagnostics or memtester could catch that one ;-)

Regards,
- Joel Fernandes