Documentation: Update to BUG-HUNTING
Signed-off-by: Ian McDonald <imcdnzl@gmail.com> Signed-off-by: Adrian Bunk <bunk@stusta.de>
This commit is contained in:
Ian McDonald
Adrian Bunk
parent
a609164f7c
commit
43019a56aa
1 changed files with 113 additions and 0 deletions
|
|
@ -1,3 +1,56 @@
|
||||||
|
Table of contents
|
||||||
|
=================
|
||||||
|
|
||||||
|
Last updated: 20 December 2005
|
||||||
|
|
||||||
|
Contents
|
||||||
|
========
|
||||||
|
|
||||||
|
- Introduction
|
||||||
|
- Devices not appearing
|
||||||
|
- Finding patch that caused a bug
|
||||||
|
-- Finding using git-bisect
|
||||||
|
-- Finding it the old way
|
||||||
|
- Fixing the bug
|
||||||
|
|
||||||
|
Introduction
|
||||||
|
============
|
||||||
|
|
||||||
|
Always try the latest kernel from kernel.org and build from source. If you are
|
||||||
|
not confident in doing that please report the bug to your distribution vendor
|
||||||
|
instead of to a kernel developer.
|
||||||
|
|
||||||
|
Finding bugs is not always easy. Have a go though. If you can't find it don't
|
||||||
|
give up. Report as much as you have found to the relevant maintainer. See
|
||||||
|
MAINTAINERS for who that is for the subsystem you have worked on.
|
||||||
|
|
||||||
|
Before you submit a bug report read REPORTING-BUGS.
|
||||||
|
|
||||||
|
Devices not appearing
|
||||||
|
=====================
|
||||||
|
|
||||||
|
Often this is caused by udev. Check that first before blaming it on the
|
||||||
|
kernel.
|
||||||
|
|
||||||
|
Finding patch that caused a bug
|
||||||
|
===============================
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Finding using git-bisect
|
||||||
|
------------------------
|
||||||
|
|
||||||
|
Using the provided tools with git makes finding bugs easy provided the bug is
|
||||||
|
reproducible.
|
||||||
|
|
||||||
|
Steps to do it:
|
||||||
|
- start using git for the kernel source
|
||||||
|
- read the man page for git-bisect
|
||||||
|
- have fun
|
||||||
|
|
||||||
|
Finding it the old way
|
||||||
|
----------------------
|
||||||
|
|
||||||
[Sat Mar 2 10:32:33 PST 1996 KERNEL_BUG-HOWTO lm@sgi.com (Larry McVoy)]
|
[Sat Mar 2 10:32:33 PST 1996 KERNEL_BUG-HOWTO lm@sgi.com (Larry McVoy)]
|
||||||
|
|
||||||
This is how to track down a bug if you know nothing about kernel hacking.
|
This is how to track down a bug if you know nothing about kernel hacking.
|
||||||
|
|
@ -90,3 +143,63 @@ it does work and it lets non-hackers help fix bugs. And it is cool
|
||||||
because Linux snapshots will let you do this - something that you can't
|
because Linux snapshots will let you do this - something that you can't
|
||||||
do with vendor supplied releases.
|
do with vendor supplied releases.
|
||||||
|
|
||||||
|
Fixing the bug
|
||||||
|
==============
|
||||||
|
|
||||||
|
Nobody is going to tell you how to fix bugs. Seriously. You need to work it
|
||||||
|
out. But below are some hints on how to use the tools.
|
||||||
|
|
||||||
|
To debug a kernel, use objdump and look for the hex offset from the crash
|
||||||
|
output to find the valid line of code/assembler. Without debug symbols, you
|
||||||
|
will see the assembler code for the routine shown, but if your kernel has
|
||||||
|
debug symbols the C code will also be available. (Debug symbols can be enabled
|
||||||
|
in the kernel hacking menu of the menu configuration.) For example:
|
||||||
|
|
||||||
|
objdump -r -S -l --disassemble net/dccp/ipv4.o
|
||||||
|
|
||||||
|
NB.: you need to be at the top level of the kernel tree for this to pick up
|
||||||
|
your C files.
|
||||||
|
|
||||||
|
If you don't have access to the code you can also debug on some crash dumps
|
||||||
|
e.g. crash dump output as shown by Dave Miller.
|
||||||
|
|
||||||
|
> EIP is at ip_queue_xmit+0x14/0x4c0
|
||||||
|
> ...
|
||||||
|
> Code: 44 24 04 e8 6f 05 00 00 e9 e8 fe ff ff 8d 76 00 8d bc 27 00 00
|
||||||
|
> 00 00 55 57 56 53 81 ec bc 00 00 00 8b ac 24 d0 00 00 00 8b 5d 08
|
||||||
|
> <8b> 83 3c 01 00 00 89 44 24 14 8b 45 28 85 c0 89 44 24 18 0f 85
|
||||||
|
>
|
||||||
|
> Put the bytes into a "foo.s" file like this:
|
||||||
|
>
|
||||||
|
> .text
|
||||||
|
> .globl foo
|
||||||
|
> foo:
|
||||||
|
> .byte .... /* bytes from Code: part of OOPS dump */
|
||||||
|
>
|
||||||
|
> Compile it with "gcc -c -o foo.o foo.s" then look at the output of
|
||||||
|
> "objdump --disassemble foo.o".
|
||||||
|
>
|
||||||
|
> Output:
|
||||||
|
>
|
||||||
|
> ip_queue_xmit:
|
||||||
|
> push %ebp
|
||||||
|
> push %edi
|
||||||
|
> push %esi
|
||||||
|
> push %ebx
|
||||||
|
> sub $0xbc, %esp
|
||||||
|
> mov 0xd0(%esp), %ebp ! %ebp = arg0 (skb)
|
||||||
|
> mov 0x8(%ebp), %ebx ! %ebx = skb->sk
|
||||||
|
> mov 0x13c(%ebx), %eax ! %eax = inet_sk(sk)->opt
|
||||||
|
|
||||||
|
Another very useful option of the Kernel Hacking section in menuconfig is
|
||||||
|
Debug memory allocations. This will help you see whether data has been
|
||||||
|
initialised and not set before use etc. To see the values that get assigned
|
||||||
|
with this look at mm/slab.c and search for POISON_INUSE. When using this an
|
||||||
|
Oops will often show the poisoned data instead of zero which is the default.
|
||||||
|
|
||||||
|
Once you have worked out a fix please submit it upstream. After all open
|
||||||
|
source is about sharing what you do and don't you want to be recognised for
|
||||||
|
your genius?
|
||||||
|
|
||||||
|
Please do read Documentation/SubmittingPatches though to help your code get
|
||||||
|
accepted.
|
||||||
|
|
|
||||||
Loading…
Add table
Reference in a new issue