Re: Understanding NULL pointer dereference

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Jun 18, 2010 at 5:09 PM, Prasad Joshi <prasadjoshi124@xxxxxxxxx> wrote:
>
>
> On Fri, Jun 18, 2010 at 1:19 PM, Manish Katiyar <mkatiyar@xxxxxxxxx> wrote:
>>
>> On Fri, Jun 18, 2010 at 10:11 AM, Prasad Joshi <prasadjoshi124@xxxxxxxxx>
>> 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.
>>
>> As ppl have already mentioned, this is some offset into a structure.
>> Next thing you can try is to do a disas do_sys_open and find out which
>> member/structure is being accessed which has this offset. You can also
>> try to get the assembly instructions from the "code" dumped. if you
>> already have the source code for your running kernel you can also try
>> "l *do_sys_open+0x7a".
>>
>
> Thanks Manish for your reply. The problem was with the return value in FS
> create() call. The create() call was returning the +ve error code. I looked
> into some of the other file systems, they use PTR_ERR to return the error
> code. Basically the -ve error code is assigned to unsigned long causing,
> thus converting it in a big number.
>
>
>             struct file *f = do_filp_open(dfd, tmp, flags, mode, 0);
>             if (IS_ERR(f)) {
>                 put_unused_fd(fd);
>                 fd = PTR_ERR(f);
>             } else {
>                 fsnotify_open(f->f_path.dentry); <=== OOPs
>                 fd_install(fd, f);
>             }
>
> So IS_ERR() was returning false and causing panic in else path.

Cool.... so looks like you crashed while dereferencing d_parent of a
negative dentry.

(gdb) p (int)(&((struct dentry *)0)->d_parent)
$5 = 52

(gdb) p/x (int)(&((struct dentry *)0)->d_parent)
$6 = 0x34

Thanks -
Manish
>
> Thanks a lot for your help.
>
> Regards,
> Prasad
>
>>
>> >
>> > Thanks and Regards,
>> > Prasad
>> >
>>
>>
>>
>> --
>> Thanks -
>> Manish
>> ==================================
>> [$\*.^ -- I miss being one of them
>> ==================================
>
>



-- 
Thanks -
Manish
==================================
[$\*.^ -- I miss being one of them
==================================

--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ




[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux