On Fri, Jun 18, 2010 at 10:39 AM, Frederic Weisbecker <fweis...@gmail.com>wrote:
> On Fri, Jun 18, 2010 at 10:11:13AM +0530, Prasad Joshi wrote: > > Hi All, > > > > I am trying to understand a a kernel oops report. Here are some of the > > fields from the report > > > > BUG: unable to handle kernel NULL pointer dereference at 0000000000000034 > > Oops: 0000 [#1] SMP > > Pid: 6478, comm: cp Tainted: P 2.6.31.5-127.fc12.x86_64 #1 Inspiron 1525 > > RIP: 0010:[<ffffffff810faac1>] [<ffffffff810faac1>] > do_sys_open+0x7a/0x10f > > CR2: 0000000000000034 > > > > As I know, when a page fault occurs, the address the program attempted to > > access is stored in the CR2 register. So probably the pointer is pointing > to > > address 0034 and is being access. > > > > The BUG string is bit confusing, it says NULL pointer dereference at > 0034, I > > know the address 00034 is not valid but why is it interpreted as NULL > > pointer? The NULL pointer as I know should point to address 0. > > > Because the origin of your bug is likely a NULL pointer. > Such address dereferenced are often the case of accessing a > member of a structure, or an index of an array, which base > address is 0. > > So Linux assumes that such very low addresses are an offset > from a NULL pointer. The max threshold to determine this is a > page size (typically 4096). > > > arch/x86/mm/fault.c: > > printk(KERN_ALERT "BUG: unable to handle kernel "); > if (address < PAGE_SIZE) > printk(KERN_CONT "NULL pointer dereference"); > else > printk(KERN_CONT "paging request"); > > Oh I see, thanks Fredric for you reply. Thanks and Regards, Prasad