Messages in this thread | | | Date | Tue, 5 Jan 1999 15:00:55 +0000 (GMT) | From | Chris Mazuc <> | Subject | OOPS with 2.0.37-pre3 |
| |
Hello,
While running a program that I wrote to fetch a page from the internet (and so I could learn tcp socket programming), I ran into this:
-- begin stuff -- general protection: 000 CPU: 0 EIP: 0010:[<0010cdc4>] EFLAGS: 00010002 eax: 682f7365 ebx: 0009e7d8 ecx: c7ca00b1 edx: 00000018 esi: 696c6173 edi: 00000003 ebp: 3ffd7db4 esp: 03395fb8 ds: 0018 es: 0018 fs: 0026 gs: 002b ss(?): 0018 Process getpage pid: 5072, process nr: 23, Stackpage: 03395000 Stack: 00000003 726f6220 00000000 c7bff780 ffffffff c7be70e0 0010bd6b 00000003 c7ca0061 000000ff c7ca0201 0000002b 429cb7b5 00000023 00000282 c7bc7098 00000026 Call trace: [<0010bd6b>] Code: ff d0 8b 5b 14 83 64 0c 85 db 75 e8 f7 c6 00 00 00 10 74 09 Aiee, killing interrupt handler -- end stuff --
This might not be entirely correct because I can't always read my own handwriting. Oh well.
Using `nm vmlinux | sort | less` as reccomended by the README file, I found the closest kernel address to 0010cdc4, here is the block of addresses around it (at least I think) -- begin stuff -- 0010cc4c t no_action 0010cc50 t math_error_irq 0010cc6c T get_irq_list 0010cd14 T do_IRQ 0010cd9c T do_fast_IRQ <-- this one? 0010cde8 T setup_x86_irq 0010cf1c T request_irq -- end stuff --
Here is the dissassembly of the "Code:" part using the method in oops-tracing.txt (I doubt this will help)
-- begin stuff -- 0x804947c <str>: call *%eax 0x804947e <str+2>: xchgb %bl,0x14(%ebx) 0x8049481 <str+5>: addl $0xc,%esp 0x8049484 <str+8>: testl %ebx,%ebx 0x8049486 <str+10>: jne 0x8049470 <_fini+4096> 0x8049488 <str+12>: testl $0x10000000,%esi 0x804948e <str+18>: je 0x8049499 <__CTOR_END__+1> 0x8049490 <str+20>: addb %al,(%eax) 0x8049492 <str+22>: addb %al,(%eax) -- end stuff --
My system is a pentium 200 with 128mb of ram running kernel 2.0.37-pre3.
Anything that you would need to find the problem I would supply, as I would like to know why this happened. I'm sure that the program I was running did something it shouldn't have, but crashing the kernel when a program misbehaves is definitely new to me (at least under Linux). With -g enabled on the kernel, the system locks up without any output. I have run the same program a few more times, and the results are extremely unpredictable. If anyone would like a copy, just ask.
Thanks, Chris Mazuc
- 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/
| |