From: Jan Harkes <jaharkes@cs.cmu.edu>
To: Yours Lovingly <ylovingly@yahoo.co.in>
Cc: Bryan Henderson <hbryan@us.ibm.com>, linux-kernel@vger.kernel.org
Subject: Re: Qn: Queer "Unable to handle kernel NULL pointer dereference at ..." error in kernel
Date: Wed, 23 Apr 2003 14:15:30 -0400 [thread overview]
Message-ID: <20030423181530.GA8584@delft.aura.cs.cmu.edu> (raw)
In-Reply-To: <20030423175333.7272.qmail@web8005.mail.in.yahoo.com>
On Wed, Apr 23, 2003 at 06:53:33PM +0100, Yours Lovingly wrote:
> i am sorry for that useless information. i am
> attaching a ksymoops output of that problem (focus on
> the register operation (that ksymoops identifies as
> the fault triggering instruction) in the "code"
> section at the end of the ksymoops output)
...
> inode_parent = parent->d_inode;
> inode = d->d_inode;
> p = (void *)inode_parent;
> me = (void *)inode;
> // Till here things work just fine. I am DEAD SURE of that as i put printk()
> // followed by return here and there and checked.
>
> if( p - me != 0 ) {
> //nfs_print_path(parent);
> printk("return 3\n");
> return;
> }
What I typically do in these cases is,
- remove the object file where the oops occurs
- rerun make
- copy the gcc line that is responsible for compiling the object
- run the same gcc line again, but add a '-g' flag
Now we have an object with debugging symbols, and can use 'objdump
--source <file>.o | less' and get something that has both the source
lines and the related assembly code. In this case the faulting
instruction is about 0x2e bytes past the beginning of nfs_print_path.
But I can get pretty far just from reading the oops and it is probably
the test you added. Ok, it looks like -O2 is actually optimizing away
some of those intermediate variables for you.
> Code; c88b6956 <[nfs]nfs_print_path+2e/58> <=====
> 0: 39 42 08 cmp %eax,0x8(%edx) <=====
> 3: 74 0d je 12 <_EIP+0x12>
Ok, so we're comparing the contents of %eax to something that is 8 bytes
offset from the address stored in %edx. and then jump out if they are
equal.
So this is something like and if (eax != edx->bar) { } construct. And in
fact the test you added was
if ( p - me != 0 )
if ( p != me )
if ( inode_parent != inode )
if ( parent->d_inode != d->d_inode )
So the contents of either parent->d_inode or d->d_inode was stored in
register eax, and we're dereferencing the other pointer during the test
operation.
Why does it crash, because the pointer we are dereferencing is 0x7, not
really a valid address, in fact it already looks like an inode number.
> eax: 00000006 ebx: c6675024 ecx: 00000001 edx: 00000007
And eax looks pretty suspicious as well. These are not pointers to inode
structures, but possibly the i_ino numbers.
Jan
prev parent reply other threads:[~2003-04-23 18:03 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <OFAFB946CE.4BD085AE-ON87256D10.006801CE-88256D10.00683E0D@us.ibm.com>
2003-04-23 17:53 ` Qn: Queer "Unable to handle kernel NULL pointer dereference at ..." error in kernel Yours Lovingly
2003-04-23 18:15 ` Jan Harkes [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20030423181530.GA8584@delft.aura.cs.cmu.edu \
--to=jaharkes@cs.cmu.edu \
--cc=hbryan@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=ylovingly@yahoo.co.in \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).