Messages in this thread | | | From | Johnny Stenback <> | Subject | Reproducible Oops in 2.0.24... | Date | Thu, 7 Nov 1996 14:22:09 +0200 (EET) |
| |
Hi
I just discovered a reproducible Oops in 2.0.24, it has to do with mmap. I just tried for the first time in my life to write a program that uses mmap and I screwed up (of course), I got it working when I tried to "read" from a file but then I wanted to "write" to the mmapped pointer and it didn't work right away (probably some stupid mistake, or?). OK, I played around some more and ended up with the following C code:
#include <stdio.h> #include <unistd.h> #include <sys/mman.h> #include <sys/types.h> #include <sys/stat.h> #include <fcntl.h> #include <string.h> #include <errno.h>
void main () { int fd; void *p; char buf[1024];
fd = open("test", O_RDONLY);
p = mmap(NULL, 200, PROT_WRITE, MAP_PRIVATE, fd, 0);
strncpy (buf, p, 100);
printf ("%s\n", buf);
munmap (p, 200);
exit (0); }
As you can see, this is wrong, I mmap with PROT_WRITE and try to read from the pointer. When I compile this and run it I get an Oops the first time I run it, the second time it just hangs (and can't be killed), if I reboot and try again I get the same result. I tried this on 2.0.23 and got the same result and I also tried with 2.0.7 and there it just said something like "Exeption xxxxxxx at xxxxxxx" (sorry don't remember exactly, can check tonight though if it's important). Here's the Oops I get with 2.0.24:
Unable to handle kernel paging request at virtual address 40007000 current->tss.cr3 = 003ea000, Lr3 = 003ea000 *pde = 011d3067 *pte = 00000000 Oops: 0000 CPU: 0 EIP: 0010:[__generic_memcpy_fromfs+56/232] EFLAGS: 00010212 eax: 00f15bf4 ebx: 00000004 ecx: 00000400 edx: 00000400 esi: 40007000 edi: 010ac800 ebp: 00000000 esp: 0094db80 ds: 0018 es: 0018 fs: 002b gs: 002b ss: 0018 Process a.out (pid: 3316, process nr: 32, stackpage=0094d000) Stack: 40007000 00009000 00000000 00000018 00000024 017d16c8 00000002 00efd460 0014c808 017d16c8 01d07d48 00000018 00000001 00000400 00000024 0094dc40 017d16c8 0000000c 00000001 00000024 0094dc40 00000024 00009000 00000000 Call Trace: [ext2_getblk+260/556] [ext2_file_write+377/1092] [ext2_file_write+568/1092] [do_truncate+70/120] [do_truncate+90/120] [permission+32/208] [dump_write+28/44] [writenote+167/200] [dump_write+28/44] [elf_core_dump+2360/2508] [<02985800>] [do_no_page+259/736] [do_page_fault+283/724] [do_no_page+0/736] [do_page_fault+0/724] [do_signal+495/636] [signal_return+18/64] Code: 64 8b 06 26 8b 07 9b dd 74 24 0c b8 04 00 00 00 64 df 6e 00
Code: 00000000 <_EIP> movl %fs:(%esi),%eax Code: 00000003 <_EIP+3> movl %es:(%edi),%eax Code: 00000006 <_EIP+6> fsave 0xc(%esp,1) Code: 0000000b <_EIP+b> movl $0x4,%eax Code: 00000010 <_EIP+10> fildll %fs:0x0(%esi) Code: 00000014 <_EIP+14>
I tried to find out where the bug (?) is myself but I failed to find it and I don't have the knowledge nor time to dig any deeper...
-- Johnny Stenback, programmer / University of Vaasa, Computer Centre E-Mail jst@uwasa.fi, Phone +358 50 5575 094
| |