Messages in this thread | | | Date | Sat, 12 Jun 1999 16:03:59 -0400 | From | Andrew Clausen <> | Subject | weird d_entry->d_inode pointer |
| |
Hi all,
Note: this bug isn't reproducable - but I have a generally unstable system. Can someone give me hints on this? (more further down)
linux 2.2.9
I got a whole lot of Oops's when running chat (for initializing a ppp connection):
Unable to handle kernel NULL pointer dereference at virtual address 000000cb current->tss.cr3 = 00c43000, %cr3 = 00c43000 *pde = 00000000 Oops: 0000 CPU: 0 EIP: 0010:[sys_read+92/240] EFLAGS: 00010202 eax: c0c65a7d ebx: c372a9e0 ecx: bffff56b edx: 00000063 esi: 00000046 edi: 00000077 ebp: c0d30000 esp: c0d31fb8 ds: 0018 es: 0018 ss: 0018 Process chat (pid: 749, process nr: 40, stackpage=c0d31000) Stack: 0804d5f0 bffff56c c0108a9c 00000000 bffff56b 00000001 bffff5bd 0804d5f0 bffff56c 00000003 0000002b 0000002b 00000003 400bc534 00000023 00000282 bffff550 0000002b
I looked inside sys_read ():
asmlinkage ssize_t sys_read(unsigned int fd, char * buf, size_t count) { ssize_t ret; struct file * file; ssize_t (*read)(struct file *, char *, size_t, loff_t *);
lock_kernel();
ret = -EBADF; file = fget(fd); if (!file) goto bad_file; if (!(file->f_mode & FMODE_READ)) goto out; ret = locks_verify_area(FLOCK_VERIFY_READ, file->f_dentry->d_inode, file, file->f_pos, count); <snip>
locks_verify_area dereferences file->f_dentry->d_inode. But d_inode is a weird number (0x0000063) - I determined this by disassembling the code (file->f_dentry->d_inode is %edx).
So something's clobbering the f_dentry struct? I can't reproduce the bug (I'm on the net now ;-)
In general, I've had a very unstable system in the since 2.2.x (from 2.2.1, 2.2.2, 2.2.5, 2.2.9)
One reproducable bug I need to investigate is I've written a program that always crashes ALSA's OSS emulation...could be related (esound is running at the same time as internet connection, so perhaps ALSA's clobbering lots of things ???)
Any ideas? What's a good way to hunt for this kind of bug? I'm assuming that ALSA has write access to all of kernel-space (is this correct?)
Andrew Clausen
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |