Re: Oops

Linus Torvalds (Linus.Torvalds@cs.helsinki.fi)
Mon, 26 Feb 1996 08:25:27 +0200

Richard Waltham: "Oops" (Feb 25, 18:18):
> Haven't had one of these for ages. This is with kernel 1.3.68.
>
> System was sitting idle at the time, I was asleep. Last thing in the
> /var/adm/messages was sendmail was sending me a message from news.
>
> Changed vc then tried mc /var/adm to look at messages and it gave a GPF and
> segmentation fault, changed to another vc and tried less /var/adm/messages
> and gave another GPF and segmentation fault. I have then written down if
> anyones interested.
>
> Couldn't diassemble Code: as ksymoops says binutils too old :(
>
> System is 486dx2/66, basically Slackware 2.1, gcc 2.5.8 - time I upgraded
> eh?

Hmm.. The symbols you have in your dump do not seem to be valid. Not
only does the Code: part match anything in "maybe_shrink_lav_buffers",
but the call trace doesn't really make sense either.

It looks like you used a System.map for another kernel rather than the
one that dumped?

> Unable to handle kernel NULL pointer dereference at virtual address c0000040
> current->tss.cr3 = 00668000, %cr3 = 00668000
> *pde = 00102067
> *pte = 00000027
> Oops: 0000
> CPU: 0
> EIP: 0010:[<0012c3f8>]
> EFLAGS: 00010202
> eax: 00000040 ebx: 0008c00c ecx: 0000ff0e edx: 0000073c
> esi: 00000801 edi: 0000f70f ebp: 00000801 esp: 00669f04
> ds: 0018 es: 0018 fs: 002b gs: 002b ss: 0018
> Process syslogd (pid: 42, process nr: 9, stackpage=00669000)
> Stack: 0008c00c 0000ff0e 00000000 00000000 0016be4b 00000801 0000ff0e 00000400
> 00000003 00000000 006283c0 00000000 0016c04e 006283c0 0008c00c 00000000
> 0000000c 00000000 006283c0 00000000 00695540 0016c0ee 006283c0 00726c30
> Call Trace: [<0016be4b>] [<0016c04e>] [<0016c0ee>] [<0016c237>] [<0012c1cf>] [<0010b11d>]
> Code: 39 08 75 2c 66 39 70 04 75 26 8b 4c 24 1c 39 48 1c 74 3d 55

Disassembles to

cmpl %ecx,(%eax)
jne x
cmpw %si,0x4(%eax)
jne x
movl 0x1c(%esp),%ecx
cmpl %ecx,0x1c(%eax)
je y
pushl %ebp

..
x: ..
..
y:

This actually looks like it's from "find_buffer()", but this is just a
guess: the code fragment isn't long enough to make really sure.

(Ugh. It's scary when you start to recognize assembly sequences and
likely places they are from. I need to get a life).

> Using `System.map' to map addresses to symbols.
>
> >>EIP: 12c3f8 <_maybe_shrink_lav_buffers+20/d0>
> Trace: 16be4b <_ext2_getcluster+17/1d0>
> Trace: 16c04e <_ext2_bread+4a/140>
> Trace: 16c0ee <_ext2_bread+ea/140>
> Trace: 16c237 <_ext2_read_inode+f3/330>
> Trace: 12c1cf <_try_to_free_buffer+f7/300>
> Trace: 10b11d <_system_call+69/a0>

Linus