Re: Debugging techniques inside kernel

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Jul 8, 2013 at 11:19 AM,  <Valdis.Kletnieks@xxxxxx> 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

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@xxxxxxxxxxxxxxxxx
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies




[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux