|Deletions are marked like this.||Additions are marked like this.|
|Line 3:||Line 3:|
|1. Version of "bugged" kernel.||1. Version of "buged" kernel.|
|Line 34:||Line 34:|
|Line 76:||Line 76:|
|Note: use''' Additional compiling options '''to make gdb more functional.'''
|Line 94:||Line 97:|
|None likes buggs. So when you spend hours/days on bug fixing, you may write short and describing as much as possible bug mail. And send it to LKML. ''Good luck with Bugg Hunting.''||None likes bugs. So when you spend hours/days on bug fixing, you may write short and describing as much as possible bug mail. And send it to LKML. ''Good luck with Bug Hunting.''|
What should I have to fix a bug?
- Bug. Well knowed, particular bug.
- Version of "buged" kernel.
- Bit of luck.
Note: Repeated bug is more then 50% of success.
printk is very useful function similar to printf(). This function work evrywhere and at any time(apart from early stage of booting kernel when video isn't initialized).It use loglevels to tell console how important is message.
Full list of levels:
KERN_EMERG <-- the most important
KERN_DEBUG <-- the less important
Console will print messages olny with level higher than console_loglevel. And default printk use DEFAULT_MESSAGE_LOGLEVEL == KERN_WARNING (but it mey changed in the future).
printk() use cyclic buffer to manage with messages. Next klogd read messages (by /proc/kmsg) from buffer and give it to syslogd with write them to /var/log/messages. (You can configure syslogd by /etc/syslog.conf).
oops is error caused by uncorrectly worked kernel. Kernel write on console what registers contain and "back trace". Only when kernel is in user space oops kill program and system can work all the time. In other spaces kernel do panic error and stop running.By default back trace contain adresses of functions with were called. But you can use ksymoops file_with_oops.txt to see names of this functions or you can compile your kernel with CONFIG_KALLSYMS that give you this same effect.
Additional compiling options.
These options are very useful when debugging kernel:
Causing errors and printing extra informations.
- Sometimes you will want to see oops informations about some bug. Use BUG() BUG_ON():
- Sometimes you will want to see oops informations and then stop system. Use panic(): if(terrible_error)
- panic("var = %ld \n", var);
- Sometimes you will want to see stack. Use dump_stack():
Magic SysRq Key.
If you set CONFIG_MAGIC_SYSRQ=y or typed 'echo 1 > /proc/sys/kernel/sysrq', you can use SysRq Key (on PPC or i386) 'Alt+PrintScreen'.
SysRq+b Restart computer
SysRq+e Send SIGTERM to all tasks (with out init !!!)
SysRq+i Send SIGKILL to all tasks (with out init !!!)
SysRq+k Kill all tasks ran from this console
SysRq+l Send SIGTKILL to all tasks (with init !!!)
SysRq+m Dump core and show it on console
SysRq+o Halt system and shutdown it
SysRq+p Print CPU registers on console
SysRq+r Change keyboard from RAW to XLATE
SysRq+s Save dirty buffers on HDD
SysRq+t Show current task info on console
SysRq+u Unmount all filesystems
But note that every user can use SysRq's keys. And it can work unproperly on unstable system.
How to use non-exist debugger?
Linus don't want a debugger for kernel because it can cause wrong diffs. And he have right!
But there are some non-official debuggers. But programmers have done some patches for debuggers.
Note: use Additional compiling options to make gdb more functional.
gdb (it is not a patch it is GNU debugger)
+ simple to use
- gdb vmlinuz /proc/kcore call gdb with vmlinuz(not compressed image of kernel) and optional /proc/kcore - memory of kernel(you must be root)
- p varaible - show what variable contain
- disassemble name_of_function - disassemble function
- - you can not change variables or other data
kgdb (connect 2 computers, one with kdb and secound with gdb)
- +you can change datas +all functions of basic gdb are implemented
-you mast configure connection
+only one computer needed +all functions of gdb implemented +simple in use
- type "break" in console
start when on oops
When everything fail.
None likes bugs. So when you spend hours/days on bug fixing, you may write short and describing as much as possible bug mail. And send it to LKML. Good luck with Bug Hunting.