Commit 43019a56aa99dbf67f32fb7bd04851b1ba63fa58
Committed by
Adrian Bunk
1 parent
a609164f7c
Exists in
master
and in
7 other branches
Documentation: Update to BUG-HUNTING
Signed-off-by: Ian McDonald <imcdnzl@gmail.com> Signed-off-by: Adrian Bunk <bunk@stusta.de>
Showing 1 changed file with 113 additions and 0 deletions Side-by-side Diff
Documentation/BUG-HUNTING
1 | +Table of contents | |
2 | +================= | |
3 | + | |
4 | +Last updated: 20 December 2005 | |
5 | + | |
6 | +Contents | |
7 | +======== | |
8 | + | |
9 | +- Introduction | |
10 | +- Devices not appearing | |
11 | +- Finding patch that caused a bug | |
12 | +-- Finding using git-bisect | |
13 | +-- Finding it the old way | |
14 | +- Fixing the bug | |
15 | + | |
16 | +Introduction | |
17 | +============ | |
18 | + | |
19 | +Always try the latest kernel from kernel.org and build from source. If you are | |
20 | +not confident in doing that please report the bug to your distribution vendor | |
21 | +instead of to a kernel developer. | |
22 | + | |
23 | +Finding bugs is not always easy. Have a go though. If you can't find it don't | |
24 | +give up. Report as much as you have found to the relevant maintainer. See | |
25 | +MAINTAINERS for who that is for the subsystem you have worked on. | |
26 | + | |
27 | +Before you submit a bug report read REPORTING-BUGS. | |
28 | + | |
29 | +Devices not appearing | |
30 | +===================== | |
31 | + | |
32 | +Often this is caused by udev. Check that first before blaming it on the | |
33 | +kernel. | |
34 | + | |
35 | +Finding patch that caused a bug | |
36 | +=============================== | |
37 | + | |
38 | + | |
39 | + | |
40 | +Finding using git-bisect | |
41 | +------------------------ | |
42 | + | |
43 | +Using the provided tools with git makes finding bugs easy provided the bug is | |
44 | +reproducible. | |
45 | + | |
46 | +Steps to do it: | |
47 | +- start using git for the kernel source | |
48 | +- read the man page for git-bisect | |
49 | +- have fun | |
50 | + | |
51 | +Finding it the old way | |
52 | +---------------------- | |
53 | + | |
1 | 54 | [Sat Mar 2 10:32:33 PST 1996 KERNEL_BUG-HOWTO lm@sgi.com (Larry McVoy)] |
2 | 55 | |
3 | 56 | This is how to track down a bug if you know nothing about kernel hacking. |
... | ... | @@ -89,4 +142,65 @@ |
89 | 142 | it does work and it lets non-hackers help fix bugs. And it is cool |
90 | 143 | because Linux snapshots will let you do this - something that you can't |
91 | 144 | do with vendor supplied releases. |
145 | + | |
146 | +Fixing the bug | |
147 | +============== | |
148 | + | |
149 | +Nobody is going to tell you how to fix bugs. Seriously. You need to work it | |
150 | +out. But below are some hints on how to use the tools. | |
151 | + | |
152 | +To debug a kernel, use objdump and look for the hex offset from the crash | |
153 | +output to find the valid line of code/assembler. Without debug symbols, you | |
154 | +will see the assembler code for the routine shown, but if your kernel has | |
155 | +debug symbols the C code will also be available. (Debug symbols can be enabled | |
156 | +in the kernel hacking menu of the menu configuration.) For example: | |
157 | + | |
158 | + objdump -r -S -l --disassemble net/dccp/ipv4.o | |
159 | + | |
160 | +NB.: you need to be at the top level of the kernel tree for this to pick up | |
161 | +your C files. | |
162 | + | |
163 | +If you don't have access to the code you can also debug on some crash dumps | |
164 | +e.g. crash dump output as shown by Dave Miller. | |
165 | + | |
166 | +> EIP is at ip_queue_xmit+0x14/0x4c0 | |
167 | +> ... | |
168 | +> Code: 44 24 04 e8 6f 05 00 00 e9 e8 fe ff ff 8d 76 00 8d bc 27 00 00 | |
169 | +> 00 00 55 57 56 53 81 ec bc 00 00 00 8b ac 24 d0 00 00 00 8b 5d 08 | |
170 | +> <8b> 83 3c 01 00 00 89 44 24 14 8b 45 28 85 c0 89 44 24 18 0f 85 | |
171 | +> | |
172 | +> Put the bytes into a "foo.s" file like this: | |
173 | +> | |
174 | +> .text | |
175 | +> .globl foo | |
176 | +> foo: | |
177 | +> .byte .... /* bytes from Code: part of OOPS dump */ | |
178 | +> | |
179 | +> Compile it with "gcc -c -o foo.o foo.s" then look at the output of | |
180 | +> "objdump --disassemble foo.o". | |
181 | +> | |
182 | +> Output: | |
183 | +> | |
184 | +> ip_queue_xmit: | |
185 | +> push %ebp | |
186 | +> push %edi | |
187 | +> push %esi | |
188 | +> push %ebx | |
189 | +> sub $0xbc, %esp | |
190 | +> mov 0xd0(%esp), %ebp ! %ebp = arg0 (skb) | |
191 | +> mov 0x8(%ebp), %ebx ! %ebx = skb->sk | |
192 | +> mov 0x13c(%ebx), %eax ! %eax = inet_sk(sk)->opt | |
193 | + | |
194 | +Another very useful option of the Kernel Hacking section in menuconfig is | |
195 | +Debug memory allocations. This will help you see whether data has been | |
196 | +initialised and not set before use etc. To see the values that get assigned | |
197 | +with this look at mm/slab.c and search for POISON_INUSE. When using this an | |
198 | +Oops will often show the poisoned data instead of zero which is the default. | |
199 | + | |
200 | +Once you have worked out a fix please submit it upstream. After all open | |
201 | +source is about sharing what you do and don't you want to be recognised for | |
202 | +your genius? | |
203 | + | |
204 | +Please do read Documentation/SubmittingPatches though to help your code get | |
205 | +accepted. |