您的位置：首页 > 运维架构 > Linux

Linux内核调试之使用BUG_ON 和dump_stack

2014-08-19 09:29 351 查看

Asserting Bugs and Dumping Information

A number of kernel routines make it easy to flag bugs, provide assertions, and dump information. Two of the most common are BUG() and BUG_ON(). When called, they cause
an oops, which results in a stack trace and an error message dumped to the kernel. Why these statements cause an oops is architecture-dependent. Most architectures define BUG() and BUG_ON() as
illegal instructions, which result in the desired oops. You normally use these routines as assertions, to flag situations that should not happen:

if (bad_thing)
BUG();

Or, even better,

BUG_ON(bad_thing);

Most kernel developers believe that BUG_ON() is easier to read and more self-documenting compared to BUG(). Also, BUG_ON() wraps
its assertion in an unlikely() statement. Do note that some developers have discussed the idea of having an option to compile BUG_ON() statements away, saving space in embedded kernels.
This means that your assertion inside a BUG_ON() should not have any side effects.
A more critical error is signaled via panic(). A call to panic() prints an error message and then halts the kernel. Obviously, you want to use it only in the worst
of situations:

if (terrible_thing)
panic("foo is %ld!\n", foo);

Sometimes, you just want a simple stack trace issued on the console to help you in debugging. In those cases, dump_stack() is used. It simply dumps the contents of the registers and a function back trace
to the console:

if (!debug_check) {
printk(KERN_DEBUG "provide some information...\n");
dump_stack();
}

内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理

标签：

相关文章推荐

新的分享

章节导航