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/